Соображения хранилища данных: когда и почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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