Журнал ВРМ World

Мировая история развития технологий управления эффективностью бизнеса – обзоры зарубежных публикаций

Хранилище данных: выбор оптимальной модели

Эксперты рассматривают три метода моделирования хранилищ данных, перечисляют
сильные и слабые стороны каждого подхода.

Проектирование и внедрение хранилища данных – это крайне сложная задача. Специалисты называют разные цифры - от 50 до 80 процентов проектов заканчиваются провалом.

Подходы к моделированию

При создании хранилища данных рекомендуется построение слоя центрального ядра. Его назначение – это интеграция данных из нескольких исходных систем и историзация данных. Ядро является единственным источником для витрин данных, которые используются для таких приложений бизнес-аналитики, как платформы отчётности или OLAP-инструменты.

Каждое хранилище данных уникально. Не только известные и неизвестные аналитические требования, количество, сложность и структура исходных систем влияют на архитектуру и дизайн хранилища данных. Влияние могут оказать и такие аспекты, как отрасль, корпоративная культура, используемые технологии и инструменты, объёмы данных и имеющиеся знания в области IT и бизнесе. Таким образом, нет универсального подхода проектирования для всех хранилищ данных, в результате, как правило, используются разные методы моделирования. Каждый из перечисленных ниже методов имеет свои преимущества в зависимости от требований и стратегии моделирования:

  • Многомерное моделирование ядра с измерениями и таблицами фактов
  • Реляционное моделирование ядра с версиями главных данных
  • Метод моделирования «свод данных»

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

1.      Стратегия моделирования

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

2.      Интеграция данных и ETL

Интеграция данных, как правило, выполняется во время ETL-процесса (extract, transform, load; извлечение, трансформация и загрузка данных) в области временного хранения и очистки данных, чтобы преобразовать данные в форму, которая может быть загружена в модель ядра. Трансформации для очистки и гармонизации данных могут быть очень сложными, но в основном независимы от подхода к моделированию ядра. Они в большей степени связаны с моделями данных OLTP-систем и качеством исходных данных. Однако, сложность интеграции данных из различных систем-источников в единую модель и этапы преобразования между OLTP- и целевой моделью данных в первую очередь зависят от подхода к моделированию. Это один из критериев, которые следует учитывать при сравнении различных методов моделирования.

3.      Историзация

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

4.      Управление циклом жизни

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

5.      Доставка информации к витринам данных

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

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

Методы моделирования

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

Многомерное моделирование настоятельно рекомендуется для витрин данных. Но также оно очень хорошо подходит для модели ядра хранилища данных, если аналитические потребности известны и правильно определены. Главное преимущество многомерной модели заключается в понятности для бизнес-пользователей. Процессы ETL и интеграции данных для загрузки в многомерное ядро обычно сложнее по сравнению с прочими методами моделирования, но с другой стороны, загрузка витрин данных намного легче, чем при использовании других подходов. Для многомерного ядра рекомендуется архитектурная схема, где витрина данных не является физическим слоем, а реализуется лишь как набор представлений ядра модели. Специалисты по внедрению должны быть осведомлены о том, что новые аналитические потребности обычно подразумевают адаптации ядра – со всеми вытекающими последствиями.

Реляционное моделирование полезно, если аналитические требования размыты или ещё не определены или если назначение хранилища данных заключается в передаче информации различным BI-приложениям и прочим целевым системам. В комбинации с учётом версий основных данных, реляционное ядро предлагает гибкую поддержку историзации данных и позволяет доставлять текущую и историческую информацию в витрины данных. ETL-процессы для загрузки в реляционное ядро обычно проще, чем для многомерного, однако доставка информации в витрины данных может быть сложнее – особенно если ядро строится на основании других моделей или систем-источников. Реляционное ядро рекомендовано, если исходные системы относительно стабильны и требуется высокая степень интеграции с моделью ядра.

Метод моделирования «свод данных» (Data Vault modeling) – это надёжный подход для построения хранилищ данных со множеством источников и регулярными структурными изменениями в них. Добавление данных в эту модель осуществляется быстро и просто, однако платой за это является сложность модели данных для понимания по сравнению с предыдущими двумя типами. Вместо полной интеграции, данные из разных источников привязаны к общим бизнес-ключам, но хранятся в оригинальном виде. Это обеспечивает простоту ETL-процессов для загрузки данных в ядро, но переносит интеграцию на второй план. Следовательно, доставка данных в многомерные витрины данных предельно сложна и дорога. Подобный способ моделирования рекомендуется для гибких проектов с краткими этапами.

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

Публикации

Дэни Шнайдер (Dani Schnider), Адриано Мартино (Adriano Martino), Марен Эшерманн (Maren Eschermann). Сравнение методов моделирования для хранилищ данных (Comparison of Data Modeling Methods for a Core Data Warehouse). Июнь 2014 г.

Автор: По материалам зарубежных сайтов