Рекомендации по хранилищу данных: когда и почему?

Я посмотрю, смогу ли я кратко ответить на ваши вопросы.

1. В какой момент стоит рассмотреть вариант создания хранилища данных? Другими словами, какие контрольные признаки, метрики или другие критерии мне следует искать, которые могут указывать на то, что стандартной транзакционной среды более недостаточно?

а. Если вы обнаружите, что отчеты и мониторинг ухудшают производительность вашей производственной системы и / или автономного хранилища данных.

б. Если вы обнаружите, что для получения ответов на вопросы, связанные с вашим бизнесом, необходимо каждый раз создавать множество сложных SQL-запросов.

c. Если вы обнаружите, что каждый раз, когда вы вносите изменения в схему транзакций, вам придется возвращаться и переделывать все запросы отчетов.

d. Если вы хотите собрать данные из нескольких источников.

2. Каковы альтернативы полноценному хранилищу данных? На ум приходят денормализация в транзакционной базе данных и стандартный реплицированный «сервер отчетов»; есть ли еще какие-то другие, которые мне следует изучить, прежде чем переходить к DW?

3. Почему хранилище данных лучше указанных альтернатив? Если ответ - «это зависит», то от чего это зависит?

Я отвечу на них вместе. Я бы не стал думать о хранилище данных как о предприятии «все или ничего». Это просто краткая фраза, которая означает «хранение ваших данных таким образом, чтобы вам было проще и быстрее отвечать на бизнес-вопросы».

Транзакционные базы данных предназначены для эффективного взаимодействия с приложениями. Хранилища данных, витрины данных, хранилища операционных данных и таблицы отчетности созданы для эффективного взаимодействия с людьми, если это имеет смысл.

4. Когда мне не следует пытаться построить хранилище данных? Я скептически отношусь к чему-либо, заявленному как «лучшая практика», независимо от контекста. Конечно, должны быть сценарии, в которых DW - неправильный выбор - каковы они?

Хороший вопрос. Если ваша транзакционная система дает вам достаточное представление о вашем бизнесе, вам, вероятно, не нужно складирование.

Если у вас есть только один источник данных и производительность не является проблемой, вы, вероятно, сможете получить представление о создании простых таблиц отчетов.

5. Есть ли какие-нибудь практические примеры систем, которые были улучшены за счет внедрения хранилища данных? Что-то, что объяснило бы мне, от начала до конца, для каких решений или анализа им нужен склад, как они решили, что в него поместить, и как склад в итоге вписался в более крупную среду? Мне не нужна надуманная фраза «давайте сделаем куб из базы данных AdventureWorks» - для меня реализация не имеет значения, меня интересуют спецификации, дизайн и общий мыслительный процесс, которые были задействованы.

Это большой вопрос, который займет гораздо больше места, чем мне здесь отведено.

По этому поводу я могу указать вам на несколько мест, которые могут дать вам интересную информацию.

• «Внедрение хранилища данных: методология, которая сработала» Брюса Уллри - это книга, в которой описывается путь одного человека к созданию хранилища данных. Он не очень отполирован, что придает ему больше реализма. Он читается как дневник с множеством моделей и других изображений, которые довольно хорошо иллюстрируют его усилия.
• «Дорожная карта бизнес-аналитики» Ларисы Мосс. Стандартная цена. Проводит вас через процесс построения практики бизнес-аналитики на высоком уровне.
• В статье Стива Уильямса «Влияние бизнес-аналитики на прибыль» приводится ряд примеров, демонстрирующих ценность создания хранилищ данных.

1. Основная цель DW - ускорить (упростить) отчетность и аналитику. Он позволяет разрезать данные любым способом, который может придумать бизнес-пользователь.

2. В качестве первого шага DW вы можете просто реализовать звездную схему Кимбалла и выполнить для нее SQL-запросы. Если это оказывается слишком медленным, подумайте о предварительно рассчитанных агрегатах (кубах).

3. Разделение и разделение информации на DW намного проще, чем на нормализованную базу данных. Реплицированный сервер отчетов повысит производительность, но не упростит нарезку и нарезку кубиками. Также имейте в виду, что DW принадлежит бизнес-пользователям, поэтому они должны в любое время придумывать различные идеи срезов / кубиков - ИТ-специалисты должны просто предоставить среду, в которой что-то подобное возможно.

4. Если вы просто периодически запускаете несколько отчетов в своей операционной системе и довольны производительностью, в DW нет необходимости.

5. Весь мой опыт связан с системами, где бизнес-пользователи бесконечно жалуются на медленные отчеты и неспособность писать «сложные запросы», в то время как производственные люди жалуются, что база данных зависает из-за отчетов. Во всех случаях достаточно простой звезды Кимбалла и сервера отчетов с кешем и снимками.

1. Вам следует подумать о создании хранилища данных, когда совпадают два из следующих критериев:

   • Huge amount of data
   • Множество больших сложных выборок (возможно, по сравнению с несколькими вставками, обновлениями и удалениями), выполнение которых занимает слишком много времени (и их сложно писать)
   • Данные из разных систем необходимо объединить

2. Вопрос в том, что вы считаете хранилищем данных. Во многих случаях вы можете постепенно перейти от OLTP-систем с некоторыми отчетами к полноценному хранилищу данных, если вы можете придерживаться системы управления реляционными базами данных. Во-первых, можно создать первую таблицу фактов и продолжать использовать нормализованные таблицы для измерения. Затем добавление в игру дополнительных фактов, таблиц фактов или специальных таблиц измерений. Сначала в той же базе данных (или в одной из баз данных задействованных систем), возможно, позже перейдя в отдельную базу данных.

3. Полное хранилище данных (отдельная база данных, звездообразная схема) предлагает лучшие варианты настройки операторов выбора, помимо перехода к специализированной системе. Он также полностью отделен от OLTP-систем. Подумайте о дизайне схемы, но также о ресурсах, таких как ЦП, ввод-вывод и память, и о организационных вопросах, таких как планирование новых выпусков. Конечно, это большой объем работы, который вам, возможно, не понадобится.

4. Это в ответах выше: то, что у вас есть несколько сложных запросов, не означает, что вы должны создавать DWH, то же самое относится и к другим критериям, если они идут изолированно.

5. Не могу предложить здесь многого, но совет: будьте гибкими. Требования к DWH сильно зависят от возможностей, которые видят пользователи. Там требования могут измениться. Автоматизировать тесты с базами данных - проблема, но еще хуже дурачиться в производственной системе без надлежащих тестов.

В какой момент стоит рассмотреть вариант создания хранилища данных? Другими словами, какие контрольные признаки, метрики или другие критерии мне следует искать, которые могут указывать на то, что стандартной транзакционной среды более недостаточно?

Я бы порекомендовал хранилище данных, если вы заметили, что выполнение операций по отчетности и анализу в хранилище транзакционных данных вредно для обоих.

Каковы альтернативы полноценному хранилищу данных? На ум приходят денормализация в транзакционной базе данных и стандартный реплицированный «сервер отчетов»; есть ли еще какие-то другие, которые мне следует изучить, прежде чем переходить к DW?

Мне здесь нечего предложить. Я бы сказал, что ведение транзакционной базы данных и базы данных отчетности кажется мне разумным, независимо от того, называете вы это складом или нет. Интеллектуальный анализ данных может потребовать очень интенсивной работы с ЦП.

Почему хранилище данных лучше указанных альтернатив? Если ответ - «это зависит», то от чего это зависит?

Мне здесь нечего предложить.

Когда мне не следует пытаться построить хранилище данных? Я скептически отношусь к чему-либо, заявленному как «лучшая практика», независимо от контекста. Конечно, должны быть сценарии, в которых DW - неправильный выбор - каковы они?

Я бы сказал, что если вам не нужно вести долгую историю, вы не проводите интенсивный анализ данных, а ваши потребности в отчетности время от времени ограничиваются специальным запросом, то, возможно, хранилище данных не необходимый.

Могу ли я рассмотреть какие-либо практические примеры систем, которые были улучшены за счет внедрения хранилища данных? Что-то, что объяснило бы мне, от начала до конца, для каких решений или анализа им нужен склад, как они решили, что в него поместить, и как склад в итоге вписался в более крупную среду? Мне не нужна надуманная фраза «давайте сделаем куб из базы данных AdventureWorks» - для меня реализация не имеет отношения, меня интересуют спецификации, дизайн и общий мыслительный процесс, которые были задействованы.

Все мои работодатели использовали хранилища данных в течение многих лет до моего приезда, поэтому я не могу говорить о том, как все было до моего приезда.

По моему опыту, первый признак того, что нужно задуматься о хранилищах данных, - это когда у вас есть (или вы разрабатываете) транзакционную базу данных, и пользователи начинают добавлять множество требований к отчетности и истории данных. Что почти всегда. Всегда легче иметь отдельное хранилище данных или базу данных отчетов, чем пытаться спроектировать транзакционную систему, которая удовлетворяет потребности в отчетности, которые всегда есть у конечных пользователей. Хранение истории (для бизнес-сущностей) в транзакционной системе добавляет сложности и раздувает базу данных, которая должна максимально быстро реагировать.

С другой стороны, я был в крупных компаниях, где многие группы создавали хранилища данных, потому что интересующие данные были распределены по многим системам и поэтому их было трудно запрашивать. Проблема заключалась в том, что каждая группа создавала собственное хранилище данных, потому что все существующие хранилища в компании не имели нужного подмножества информации или имели модель данных, которая считалась неоптимальной или неправильной. Это ухудшило ситуацию, создав еще более разрозненные системы данных, которые было трудно сравнивать.

DW можно было бы рассмотреть, если кто-то использует «транзакционную систему» ​​в течение длительного периода. Позже они понимают, что им необходимо выполнить некоторый анализ данных, чтобы определить различные модели данных в бизнесе. И, наконец, с помощью определенных шаблонов данных нужно помочь высшему руководству принимать дальнейшие решения в пользу компании.

Для создания хранилища данных необходимо предпринять следующие шаги:

1. Для базы данных необходимо выбрать платформу ETL и базу данных.
2. Для визуализации необходимо выбрать такой инструмент отчетности, как SSRS, Tableau и т. Д.
3. Можно выбрать язык анализа данных, такой как R, для дальнейшего использования.
4. Наконец, все это поможет в разработке хранилища данных и инструмента отчетности.

«Я думаю, что почему некоторые проекты терпят неудачу?»

Есть пять основных причин:

• отсутствие партнерства между ИТ-отделом и бизнес-пользователями;
• некорректная архитектура хранилища данных;
• недостаточно опытных людей;
• неправильное планирование, такое как отказ от использования проверенной методологии и плана, гарантирующего, что никакие детали не будут упущены;
• и в зависимости от новейших технологий.