DWH по Кимбаллу и Data Mesh

DWH проектирование архитектуры данных Data Mesh, основы больших данных, курсы для архитекторов данных, архитектура хранилищ данных, как спроектировать корпоративное хранилище данных, дизайн проектирование Data Warehouse DWH КХД, DWH и Big Data, обучение архитекторов и инженеров Big Data, Школа Больших Данных Учебный Центр Коммерсант

Все архитекторы DWH и многие дата-инженеры знакомы с идеями Ральфа Кимбалла, согласно которым хранилище данных — это сочетание множества различных витрин данных, облегчающих отчетность и анализ важных бизнес-показателей. Читайте далее, как реализовать этот подход при проектировании корпоративного хранилища данных и при чем здесь Data Mesh.

КХД по Кимбаллу: доменные витрины данных, звезды и снежинки

Напомним, подходы Ральфа Кимбалла и Билла Инмона ортогональны друг другу. Кимбалл фокусируется на на важности витрин данных, которые являются хранилищами доменно-ориентированной информации по разным бизнес-направлениям. По Кимбаллу DWH проектируется «снизу вверх». У Инмона DWH является централизованным хранилищем всех корпоративных данных, без разделения по доменам: сперва создается нормализованная модель КХД для всей компании, а затем на ее основе создаются витрины размерных данных. По Инмону, DWH проектируется «сверху вниз».

Таким образом, можно сказать, что подход Кимбалла с разделением по бизнес-направлениям поддерживает принцип доменно-ориентированного проектирования. Именно разделение по бизнес-направлениям или процессам является первым шагом в 4-этапном последовательности проектирования моделей DWH:

  • выбрать бизнес-процесс (бизнес-направление);
  • определить гранулярность;
  • определить измерения;
  • определить факты.

Гранулярность относится к содержимому строки в таблице фактов, которая содержит агрегированные данные для составления отчетов. Например, одна строка для каждого заявления о приеме на работу нового кандидата, для каждой отдельной операции с акциями или для каждого отдельного продукта, купленного в списке транзакций. Гранулярность описывает данные в терминах бизнеса. Можно также использовать даты в качестве примера. Чем более детализированы данные о дате транзакции, тем больше информации получит аналитик. В частности, может быть столбец даты и времени, чтобы видеть тенденции изменения бизнес-показателей в течение дня. Это позволит более объективно принимать решения, основанные на данных, реализуя принцип data-driven управления.

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

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

Разобравшись с бизнес-требованиями, процессами, гранулярностью данных и измерениями, можно разработать таблицу фактов. Факты должны соответствовать гранулярности и бизнес-домену, чтобы вместе с правильными описательными измерениями предоставлять пользователям ценную информацию для принятия управленческих решений. Таким образом, в основе архитектуры данных лежит понимание бизнес-проблем и возможностей, которые должно удовлетворить DWH.

Data Mesh как улучшение DWH

Хотя идеи Кимбалла были впервые высказаны почти 40 лет назад, в начале 80-хх гг. XX века, они до сих пор актуальны. В частности, оптимальной аналитической моделью данных сегодня считается многомерная модель поверх звездных схем. Она хорошо масштабируется и под нее оптимизировано большинство современных СУБД, включая базы данных с массово-параллельной обработкой (MPP), таких как Greenplum и Arenadata DB. Но современные DWH, спроектированные по Кимбаллу, сталкиваются с проблемой разделения измерений.

Факты, описывающие различные бизнес-процессы в организации, могут быть довольно хорошо изолированы друг от друга и могут быть распределены между разными доменными областями. Но таблицы измерений часто являются общими для разных доменов, таких как продукты, клиенты, сотрудники, счета, магазины и пр. Эту проблему решает новый архитектурный подход под названием «сетка данных» (Data Mesh) – децентрализованная по разным доменам архитектура данных 4-го поколения. Она имеет централизованное управление и единые стандарты, обеспечивающие интегрируемость данных, а также централизованную инфраструктуру, с возможностью использования в режиме самообслуживания.  Data Mesh использует потоковую и пакетную парадигмы обработки данных, предполагая, что различные наборы данных должны полностью управляться отдельными командами в разных бизнес-областях. При этом продукты данных каждой доменной команды должны быть обнаруживаемыми, совместимыми, безопасными, надежными и обладать самоописываемой семантикой и синтаксисом. Подробнее о Data Mesh мы рассказывали здесь и здесь.

Применительно к проблеме DWH по Кимбаллу, Data Mesh предполагает изолированные наборами данных, ориентированными на потребителя. Это можно реализовать, создавая для каждого измерения отдельный домен, что усложняет доступ к этим данным из других доменов и увеличивает общее количество поддерживаемых доменов. Альтернативой является создание измерений в каждом домене, что может привести к дублированию логики, связанной с обработкой измерений и обеспечением качества.

Таким образом, современные архитектуры данных развивают ранее существовавшие успешные подходы, увеличивая их преимущества с помощью новых технологий. В частности, используя различные облачные платформы и SaaS-решения дата-инженеры и ИТ-архитекторы могут реализовать архитектуру Ральфа Кимбалла с отдельными витринами данных для каждого бизнес-процесса в рамках одной быстрой итерации и обеспечить бизнес-ценность за пару дней вместо многолетней разработки огромного DWH. Про применение такого гибридного подхода читайте в нашей новой статье.

Узнайте больше про современные дата-архитектуры для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://medium.com/@jjghavami/data-engineer-must-kimballs-4-step-dimensional-design-process-a9cc7bdf8d4
  2. https://habr.com/ru/post/441538/
  3. https://towardsdatascience.com/data-mesh-pain-points-b4bebca37357
Поиск по сайту