Хранилища данных.
Обзор технологий
и подходов к проектированию

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

В этой статье будут рассмотрены основные подходы к проектированию архитектуры хранилищ данных (DWH), эволюция архитектур, взаимосвязь Data Lake, Data Factory, Data Lakehouse, Data Mesh c DWH, преимущества и недостатки подходов к моделированию данных. Материал будет полезен тем, кто работает с корпоративными данными: аналитики, инженеры и архитекторы данных.

Хранилище данных (Data Warehouse, DWH) — это программная система для централизованного хранения и управления большим объёмом структурированных данных, собранных из различных источников (RDBMS, Data Lakes, внешние источники данных или файлы), для использования их в аналитике и отчётности, прогнозировании и принятии бизнес-решений.

Если DWH построено на реляционной модели, где данные организованы в таблицы, состоящие из строк и колонок, то его принято называть реляционным. Хранилища могут быть и нереляционными, в случае если они включают в себя такие системы как NoSQL (например, колоночные или графовые БД). Однако реляционные DWH гораздо чаще представлены в корпоративном мире из-за многолетнего доминирования реляционного подхода в области моделирования данных. Концепция DWH появилась как следующая ступень эволюции реляционных БД, унаследовав реляционную модель. Реляционная модель хорошо подходит для структурированных данных и пользуется широко распространённым стандартным языком SQL.

Если DWH используется всей компанией, его могут называть корпоративным хранилищем данных или КХД (Enterprise Data Warehouse, EDW). EDW — это расширенная версия DWH с более широким спектром источников и типов данных для поддержки всех бизнес-юнитов организации. Таким образом, EDW действует как single version of truth (SVOT) для всей компании, что означает практику создания объединённого, согласованного представления данных. Все данные хранятся в стандартизированном структурированном виде, и все пользователи имеют доступ к одной и той же информации, что исключает любые расхождения и решает проблему «изолированных хранилищ» (data silos). Далее в статье термины DWH и EDW могут быть использованы как взаимозаменяемые.

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

Вот ещё несколько преимуществ, которые бизнес может получить, имея грамотно спроектированную систему DWH:

• Оптимизация операций чтения. Зачастую БД, являющиеся источником данных для DWH, оптимизированы для равномерной поддержки всех операций CRUD (создание, чтение, обновление, удаление), поэтому чтение данных может быть не таким быстрым. DWH в свою очередь является системой типа «write-once, read-many», что означает преимущественное использование для работы аналитиков.

• Обеспечение историчности данных. В зависимости от изначальных требований DWH может содержать всю историю данных. При этом аналитику, желающему получить отчёт с метриками за прошлые годы, не придётся беспокоиться о том, что при запуске отчёта не найдётся данных.

• Согласованные правила именования таблиц. Многие имена таблиц и полей в БД приложений (особенно в старых продуктах ERP и CRM), носят странные неочевидные названия:например, таблица может называться tbl_123, а поле — SET_321. В DWH обычно применяются согласованные стандарты и правила именования объектов, предоставляющие пользователям контекст и удобство при поиске нужных данных.

• Управление мастер-данными (MDM — Master Data Management). При сборе данных из нескольких источников часто приходится использовать MDM для удаления дублирующихся записей таких сущностей, как клиенты, продукты, поставщики и т.д. DWH выступает тем идеальным местом для создания MDM.

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

• Исключение (или минимизация) участия ИТ-специалистов в создании отчётов. Этот пункт предполагает построение правильного BI self-service в DWH, что избавит от необходимости привлекать ИТ-специалистов к созданию отчётов и оставит эту задачу в руках конечного пользователя. BI (Business Intelligence) self-service (самообслуживание в бизнес-аналитике) — это подход к организации процесса построения отчётности, позволяющий пользователям самостоятельно извлекать, анализировать и визуализировать данные без необходимости обращаться к ИТ-специалистам.

Для понимания взаимосвязи между DWH и другими популярными архитектурами данных необходимо проследить хронологию развития систем БД и моделирования данных.

1961–1970: Появление первых коммерческих СУБД (IMS от корпорации IBM и фирмы NAA и IDS от фирмы General Electric). Начало использования данных в СУБД для аналитики и принятия бизнес-решений. Появление понятия «структурированные данные». Первые СУБД поддерживались в рамках иерархических и сетевых моделей данных.

1971–1980: Разработка концепции реляционных БД (RDBMS). Язык SQL становится стандартом для работы с данными. Возникновение концепций ETL и OLTP. Действует подход «схема при записи» (schema-on-write) и реляционная модель как метод моделирования данных.

1981–1990: Дальнейшее развитие реляционной модели и применение таких техник как моделирование сущность-связь (ER-моделирование). Широкое распространение таких RDBMS как Oracle, IBM DB2 и Microsoft SQL Server. Зарождение концепции DWH. Представление первых продуктов, реализующих концепции многомерного анализа данных. Появление первых инструментов бизнес-аналитики (MicroStrategy).

1991–2000: Распространение концепций DWH, представленной Б. Инмоном. Рост популярности BI-решений и аналитических платформ. Появление технологии OLAP и введение UML. Широкое применение размерных (dimensional) и объектно-ориентированных моделей данных и технологий их реализации, например, PostgreSQL — объектно-реляционная СУБД которая поддерживает наследование.

2001–2010: Взрывной рост объёмов данных и появление термина «Big Data». Развитие технологий для распределённой обработки больших данных (Hadoop). Возникают Anchor Modeling и Data Vault.

2011–2020: Интеграция AI и машинного обучения в аналитику данных. Облачные технологии. Выход на рынок проектов Apache: Spark, Kafka, Flink, Airflow. Широкое применение в коммерческих СУБД технологий MPP (massive parallel processing) — массово-параллельной архитектуры, особенностью которой является физическое разделение памяти узлов, объединённых в кластер. В результате применения этого подхода к PostgreSQL возник Greenplum. Возникновение СУБД, оптимизированных для горизонтального масштабирования и работы с большими объёмами неструктурированных данных (Cassandra, MongoDB, Google BigQuery). Развитие концепции Data Lake и Data Fabric. Действует подход «schema-on-read» и становятся популярными модели данных NoSQL.

2021 — по настоящее время: Дальнейшее развитие и расширение возможностей благодаря облачным технологиям и Data as a Service (DaaS). Автоматизация процессов аналитики данных и MLOps. Активное использование рынком архитектур Data Lakehouse & Data Mesh.

Таким образом, хронологически концепция DWH возникла вслед за реляционными базами как устранение ограничений, с которыми столкнулись RDBMS. Основными проблемами RDBMS были неудовлетворительная производительность чтения при выполнении аналитических запросов и ограничения по объёму данных.
DWH изобретён частично для решения этих проблем. Данные из реляционной БД копируются в DWH, и пользователи могут выполнять запросы и создавать отчёты на основе данных DWH, а не реляционной БД.

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

Data Lake — это просто хранилище всевозможных типов данных (структурированных, полуструктурированных и неструктурированных) без какого-либо нативного вычислительного движка. Данные сохраняются в Data Lake из источника в том же самом формате без трансформаций. Такой подход называется «schema-on-read».

Компании, продающие Hadoop и Data Lakes, такие как Cloudera, Hortonworks и MapR, расхваливали их, словно они умеют всё: копировать и очищать данные, делать их доступными конечным пользователям. Они утверждали, что Data Lakes смогут полностью заменить реляционные DWH.

Действительно, у Data Lakes была пара преимуществ. Это недорогой способ хранения неограниченного объёма данных и действует он как онлайн-архив. Также это идеальное место для загрузки потоковых данных.

Но оказалось, что хоронить DWH было рано: читать данные и делать запросы к Data Lakes было не так просто, для этого конечным пользователям и аналитикам нужно иметь навыки инженера данных (например, уметь пользоваться Jupyter, Hive, Python). Кроме того, в Data Lakes не было некоторых функций, нужных для аналитики данных, таких как поддержка транзакций, обеспечение схемы и аудит операций.

Таким образом, Data Lakes не смогли заменить реляционные DWH, но они всё ещё предлагали преимущества для стейджинга и подготовки данных. Почему бы не воспользоваться преимуществами обоих Data Lakes & DWH? Многие компании начали строить архитектуры, в которых Data Lakes размещались бок о бок с реляционными DWH, формируя ту архитектуру данных, которая сейчас называется современным хранилищем данных (MDW).

Архитектура MDW объединяет преимущества Data Lakes & DWH: Data Lakes используется для стейджинга и подготовки данных, а также для построения моделей машинного обучения, а DWH предназначено для запросов и отчётности.

С 2016 года начали появляться архитектуры данных, известные как Data Fabric. Можно представить эту архитектуру как эволюцию архитектуры MDW с добавлением большего количества технологий, таких как обработка данных в реальном времени, политики доступа, каталог метаданных, MDM, API. Также были внесены улучшения в процессы поступления, преобразования, запросов и поиска данных.

Архитектура типа Data Lakehouse стала популярной около 2020 года, когда компания Databricks представила эту концепцию вместе с архитектурой медальона. Концепция Data Lakehouse заключается в том, чтобы избавиться от реляционного DWH и использовать только один репозиторий Data Lake. Все типы данных — структурированные, полуструктурированные и неструктурированные — загружаются в Data Lake, и все запросы и отчёты выполняются также из Data Lake.

Мы помним, что впервые появившиеся Data Lakes использовали такой же подход, но потерпели неудачу и не смогли заменить DWH. Чем же тогда отличается Data Lakehouse?

У Data Lakehouse появляется программный слой транзакционного хранения данных, который работает поверх существующего Data Lake и делает его работу более похожей на реляционную БД. Среди конкурирующих вариантов с открытым исходным кодом для этого слоя были разработаны следующие табличные форматы: Delta Lake (от Databricks), Apache Iceberg и Apache Hudi. Главное назначение этого слоя — разделить пересекающиеся операции записи и чтения (concurrency) без ущерба для производительности платформы и потери данных.

Примерно в то же самое время вводится термин Data Mesh. Его автор Zhamak Dehghani, основатель компании Nextdata. В архитектуре Data Mesh есть много положительных моментов, но, несмотря на весь хайп, она подходит только для небольшого числа случаев.

Все вышеупомянутые архитектуры предполагают централизацию данных: копирование операционных данных в центральное хранилище, принадлежащее и управляемое ИТ-службой, где она и создаёт аналитические слои данных. Этот централизованный подход ставит три основных вопроса: кто владеет данными, кто отвечает за качество данных и как масштабировать организационные и технические решения. Цель Data Mesh — ответить на эти вопросы.

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

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

Сейчас в большинстве компаний на российском рынке всё ещё доминирует архитектура MDW (Modern Data Warehouse), которая включает продукты Data Lake & DWH. Есть компании, которые уже внедрили табличные форматы (Apache Iceberg), их архитектура претендует на то, чтобы называться Data Lakehouse. Многие находятся на стадии разработки и перехода к Data Lakehouse. Data Lake & DWH в этом отношении архитектурами уже не являются, поскольку используются только как один из компонентов для создания полного архитектурного решения.

В связи с возрастающими потребностями бизнеса в потоковых данных для автоматизации принятия решений в режиме реального времени на рынке появляются форматы, интегрирующие Data Lakehouse с технологиями real-time или near real-time(NRT). Например, Apache Paimon — формат, позволяющий наряду с пакетной загрузкой данных (batch) внедрить в архитектуру Data Lakehouse технологии для потоковой обработки данных (streaming), такие как Flink и Spark Streaming. Такую архитектуру называют Streaming Lakehouse. Apache Paimon — в прошлом Flink Table Store — был создан разработчиками Flink на базе табличного формата Apache Iceberg. Paimon в отличие от Iceberg использует LSM-деревья в качестве структур данных, позволяющих обслуживать обновления на потоковых данных. Apache Paimon активно развивается в рамках комьюнити Apache Flink и облачного вендора Ververica. Новые возможности Apache Paimon ожидаются с релизом Apache Flink в версии 2.0.

Data Lakehouse технически может поддерживать несколько слоев и стилей моделирования данных, разных по функциональным возможностям. Наиболее универсальной и популярной считается архитектура «медальон», предложенная компанией Databricks.

В зависимости от требований проекта и сценариев использования DWH в рамках Data Lakehouse могут применятся различные принципы организации данных в слои и техники моделирования данных.

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

Как мы видим, разработка DWH может включать в себя использование и комбинирование различных подходов к созданию слоёв. В зависимости от уникальных бизнес-требований проекта можно применять различные техники моделирования (например, использовать Data Vault на слое DDS, а на Data Mart — размерное моделирование). У каждой из них есть свои преимущества, и каждая может быть подходящим вариантом для различных сценариев использования.

Далее мы рассмотрим более подробно подходы к проектированию реляционного DWH как концепции или части в рамках верхнеуровневой архитектуры Data Lakehouse. Но сперва разберём технологию проектирования: её основные этапы и техники их реализации.

В общем виде при проектировании DWH с нуля используется top-down подход (не путать с top-down подходом по Инмону). Этот подход хорошо работает для отчётности и исторического анализа, когда конечным пользователям необходимо определить, что произошло (описательная аналитика) и почему это произошло (диагностическая аналитика). При top-down подходе сначала происходят общее планирование и проектирование архитектуры DWH, а затем разрабатываются конкретные компоненты. Этот метод подчёркивает важность определения корпоративного видения и понимания стратегических целей организации и информационных требований перед тем, как приступить к разработке DWH. Для сравнения, при проектировании Data Lake используют противоположный bottom-up подход.

Итак, на начальном этапе прорабатываются бизнес-требования к отчетности и KPI. На основе бизнес-требований создаётся общая архитектура DWH, включая его структуру, слои, модели данных и процессы интеграции с другими системами — это технические требования. Разрабатывается модель данных, что является одним из ключевых этапов в проектировании DWH. Модель данных — это своего рода ТЗ на то, как будут выглядеть каталоги, схемы, таблицы и поля в DWH. Далее на подготовленной структуре DWH создаются процессы ETL для извлечения данных из различных источников, их преобразования в нужный формат и загрузки в DWH. Разрабатываются и внедряются BI-инструменты. Впоследствии DWH тестируется, дорабатывается, масштабируется и оптимизируется с учетом бизнес- и технических требований.

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

В общем виде процесс разработки модели данных включает:

• Сбор требований. На этом этапе наиболее эффективным является метод, ориентированный на отчётность (report-driven): потребности в данных определяются путём анализа требований к отчётности пользователей BI. Эти требования собираются путём индивидуальных или небольших групповых интервью с заинтересованными сторонами (например, с бизнес-аналитиками, пользователями, техническими экспертами). Затем консолидированный список требований к данным проверяется на соответствие имеющимся источникам данных. После утверждения требований документация используется для организации процесса моделирования данных и последующего развития BI.

• Концептуальное моделирование. Включает создание высокоуровневой модели данных, которая иллюстрирует основные объекты и их взаимосвязи: выбор схемы представления данных или нотации; использование ER-диаграммы для представления данных; определение сущностей; определение ключевых свойств каждой сущности; определение связей между сущностями.

• Логическое моделирование. Происходит преобразование концептуальной модели в логическую модель данных с учётом требований: определение атрибутов, первичных и внешних ключей, ограничений; сопоставление атрибутов с сущностями; назначение ключей по мере необходимости и определение степени нормализации.

• Физическое моделирование. Преобразование логической модели в физическую модель, учитывая архитектуру и особенности DWH. Включает в себя все необходимые таблицы, столбцы, связи, свойства базы данных для физической реализации баз данных. Определяет индексы, триггеры, процедуры и другие объекты DWH. Для технологий Big Data физическое моделирование может быть избыточно и по факту не требуется.

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

• Обслуживание и обновление модели. Регулярный̆ мониторинг и обновление модели данных в соответствии с изменяющимися требованиями бизнеса.

Существуют 3 наиболее часто используемых подхода к моделированию данных:

• Реляционный
• Размерный (схема «звезда», схема «снежинка»)
• Data Vault 2.0

Какую модель выбрать? Это будет зависеть от бизнес-требований и того, какой слой или компонент Data Lakehouse проектируется.

Кратко рассмотрим каждый из подходов и случаи их применения.

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

Обычно реляционное моделирование начинается с диаграммы сущность-связь (ER-диаграммы) — высокоуровневой визуальной структуры базы данных, которая представляет сущности и отношения между ними.

Далее применяются правила нормализации, которые являются способом разбиения набора данных на более мелкие и простые таблицы. Нормализация уменьшает избыточность и зависимость, повышает целостность данных и делает базу данных более эффективной в обслуживании и управлении. Всего выделяют 6 форм уровней нормализации, которые применяются последовательно до нужной формы. Для реляционного моделирования чаще всего используется третья нормальная форма (3NF). Таблица находится в 3NF, если и только если она удовлетворяет всем условиям 1NF и 2NF, а также все атрибуты таблицы функционально зависят только от первичного ключа и отсутствуют транзитивные зависимости, т.е. ситуации, когда атрибут зависит от другого атрибута, который̆ не является ключом.

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

Реляционная модель чаще всего используется для конкретной реализации базы данных с использованием СУБД, таких как Oracle, Microsoft SQL Server, MySQL, PostgreSQL, т.е. случаи применения — это базы типа OLTP. В контексте Data Lakehouse — это внешние источники данных для Data Lake.

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

Факты, измерения и ключи — это основный понятия размерного моделирования.

Факты — это числовые данные, используемые для измерения чего-либо, например продаж, заказов или выручки. Факты могут быть агрегированы или суммированы из соображений производительности, например, посчитаны средние значения или общее количество.

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

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

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

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

Для отслеживания изменений, внесенных в таблицу при размерном моделировании, используется медленно изменяемые измерения (Slowly Changing Dimensions, SCD). Кратко опишем первые два как наиболее часто встречающиеся.

SCD type 1: существующие данные перезаписываются новыми данными, старые данные не сохраняются. Используется, когда изменения данных незначительны или когда старые данные больше не нужны, например, при исправлении номера телефона клиента.

SCD type 2: этот подход позволяет сохранить историчность. Дополнительно добавляются новая строка или служебные столбцы, которые могут отвечать за версионирование, статус, временной интервал, в течение которого данные строки можно считать актуальными.

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

Ключевое различие между 3NF-моделями и размерными моделями заключается в степени нормализации. Так, при размерном моделировании используют процесс, называемый денормализацией, при котором избыточные копии данных включаются в несколько таблиц. Это позволяет сократить количество таблиц и запросы выполняются намного быстрее, поскольку не требуются объединения. Меньшее количество объединений также удобнее для конечных пользователей при создании отчётов. Однако это означает, что избыточные копии данных должны быть синхронизированы в разных таблицах для обеспечения целостности, и для этого требуется тщательно настроенный процесс интеграции и загрузки данных.

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

Схема «звезды» в DWH — это схема, в центре которой находится таблица фактов, а по бокам — несколько связанных с ней по внешнему ключу таблиц измерений.

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

Размерные модели (также как и 3NF-модели) могут быть представлены в виде ER-диаграмм.

Когда речь заходит о построении размерной модели в DWH, обычно вспоминают о её популяризаторе Ральфе Кимбалле, авторе первой книги в области хранилищ данных «The Data Warehouse Toolkit». Размерное моделирование и методология Кимбалла — эти два термина обычно рассматриваются как синонимы. Кимбалл создал обширный набор методов и понятий для размерного моделирования, включая согласованные измерения, медленно меняющиеся измерения, мусорные измерения, мини-измерения, таблицы мостов, а также таблицы фактов периодических снимков.

У Кимбалла также был свой подход к проектированию DWH. Методология «bottom-up» по Кимбаллу начинается с извлечения сырых данных из каждой системы исходных OLTP во временные реляционные стейджевые таблицы без преобразования или очистки. Затем идет этап интеграции данных и обеспечения их качества, за которым следуют этапы моделирования, проектирования и организации доступа к данным. Архитектура DWH по Кимбаллу изображена ниже.

Основное отличие от некогда популярной методологии проектирования по Инмону в том, что Кимбалл пропускает слой нормализованного реляционного DWH. Данные из стейджевых таблиц сразу копируются в атомарные независимые хранилища данных Data Marts, которые обслуживают аналитические потребности отделов. Data Marts независимы, поскольку они фокусируются на конкретной предметной области или бизнес-процессе, а не хранят и не управляют всеми данными в единственном центральном репозитории, как это представлено в архитектуре DWH по Инмону. По Кимбаллу Data Marts (или ещё они могут представлять из себя просто витрины данных) спроектированы в размерной модели.

Для сравнения представлена архитектура DWH по Инмону, в центре которого — нормализованный DWH.

Обе методологии относятся к традиционным подходам проектирования DWH первого поколения. К недостаткам этих подходов относят отсутствие горизонтального масштабирования, длительный цикл обработки данных и высокую стоимость инфраструктуры для обеспечения отказоустойчивости. По мере развития и появления новых технологий Big Data подходы Инмона и Кимбалла адаптировались и сочетались в некой гибридной комбинации.

Созданная Д. Линстедтом в 2000 году, концепция Data Vault представляет методологию проектирования гибких и масштабируемых хранилищ данных.

Концепция Data Vault построена вокруг трёх основных сущностей.

Хабы (Hubs) — это центральные бизнес-сущности в модели, представляющие ключевые бизнес-концепции, такие как клиенты или продукты. Хабы обычно моделируются как отдельная таблица с уникальным идентификатором (например, первичным ключом или бизнес-ключом) и набором мета-атрибутов (дата загрузки, источник записи). Для каждого бизнес-ключа в хабе генерируется хэш-ключ. Хэш-ключ используется для ссылки на бизнес-объект в других сущностях Data Vault, таких как таблицы-ссылки и таблицы-сателлиты.

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

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

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

Стоит также кратко упомянуть технику Anchor Modeling (якорная модель), которая появилась позже модели Data Vault. Якорная модель предоставляет ещё большую степень гибкости, масштабируемости и устойчивости к изменениям в бизнес-требованиях, чем Data Vault. Хорошо подходит для моделирования динамических данных большого объёма, информация в которых со временем меняется не только по содержанию, но и по структуре.

Четыре основных понятия, используемых в якорном моделировании:
• якоря соответствуют сущностям или событиям,
• атрибуты моделируют свойства якорей,
• связи — отношения между якорями,
• узлы моделируют общие свойства или состояния.

Якорное моделирование имеет некоторые недостатки, такие как ухудшение производительности за счёт увеличения join'ов и сложности в понимании и разработке модели.

Для создания процессов ETL/ELT для извлечения данных из различных источников, их преобразования в нужный формат и загрузки в DWH могут использоваться различные инструменты.

Для начала объясним, в чем разница между ETL/ELT.

Процесс ETL (Extract, Transform, Load) включает в себя извлечение данных из внешних источников, их трансформацию и очистку в одном и том же процессе для соответствия формату и структуре места назначения, а затем загрузку в это место (обычно Data Lake или DWH). Здесь подчеркивается, что трансформация происходит на раннем этапе процесса, сразу после извлечения и перед загрузкой в целевую систему. У ETL существует несколько основных недостатков. Во-первых, извлечение и преобразование данных может занимать время, а также существенно влиять на производительность всей системы. Во-вторых, если в трансформации данных обнаружатся ошибки, не всегда есть возможность восстановить и перезагрузить исторические данные. ETL предпочтительнее использовать, когда и источник, и место назначения являются реляционными базами данных.

В случае ELT порядок действий другой. ELT также копирует данные из внешних источников в систему назначения, но данные не преобразуются в процессе передачи. Они попадают в систему назначения в своей первоначальной форме и затем преобразуются и очищаются для соответствия формату и структуре системы назначения. ELT имеет ряд преимуществ перед ETL, например, обеспечивает возможность изменять или оптимизировать преобразования без необходимости повторного извлечения данных. Также ELT-процессы могут поддерживать более широкий спектр типов данных и могут минимизировать возможные проблемы с производительностью на исходной системе, поскольку данные извлекаются только один раз, а будущие преобразования обрабатываются в целевой системе. При необходимости данные всегда являются доступными в своей первоначальный форме, как они были загружены из источника. ELT является предпочтительным подходом для Data Lakes для работы с большим объёмом неструктурированных или полуструктурированных данных.

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

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

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

На практике чаще используют комбинацию из этих двух методов.

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

Вот несколько методов для идентификации недавно измененных данных и реализации инкрементального извлечения из исходных систем:

• Метки времени
• СDC
• Триггеры БД
• Оператор MERGE
• Партицирование

На схеме ниже представлена реализация возможной архитектуры Data Lakehouse из доступных для российских компаний технологий, в основном с открытым исходным кодом. Данная схема позволяет продемонстрировать и кратко описать инструменты ELT, используемые в архитектуре Data Lakehouse.

Итак, в источниках (source1, source2 и т.д.) содержатся данные, которые должны быть реплицированы или переданы в реальном времени в другие системы для дальнейшей обработки и анализа. Для захвата изменений (CDC) может использоваться Debezium — инструмент, предназначенный для мониторинга и репликации данных в реальном времени из различных источников данных (таких как MySQL, PostgreSQL и другие) в формате транзакционных журналов баз данных (также известных как журналы изменений или WAL).

Debezium подписывается на журналы изменений баз данных и захватывает все операции CRUD (Create, Read, Update, Delete), преобразуя их в структурированные события, которые затем передаются через Kafka Connect. Kafka Connect — это фреймворк, предоставляемый Apache Kafka, который позволяет интегрировать Kafka с различными системами для потоковой обработки данных. Debezium работает как плагин для Kafka Connect, что позволяет передавать события изменений данных, полученные Debezium, напрямую уже в Kafka.
После того как данные попадают в Apache Kafka, приложение потоковой обработки данных в реальном времени, написанное, например, с использованием Spark Streaming или Flink, может читать эти данные из Kafka, попутно выполняя вычисления в реальном времени.

После чтения данных потоковое приложение записывает данные as-is в Data Lake в сырой слой данных (Raw). В качестве объектного хранилища может быть развёрнуто облачное объектное хранилище AWS S3 (как показано на схеме) либо как альтернативные варианты на HDFS.

Для хранения большого объёма данных они сохраняются в колоночном формате Parquet с использованием табличного формата Iceberg для организации эффективного доступа к ним. Далее для передачи данных из сырого слоя в операционный слой ODS могут применяться такие движки как Spark и Airflow, обеспечивающие автоматизацию процессов обработки данных. Spark выполняет вычисления и анализ данных, а Airflow управляет планированием и выполнением пакетных рабочих процессов.

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

Для загрузки данных из слоя ODS непосредственно в DWH в слой DDS можно использовать связку Airflow + dbt (data build tool). dbt — это фреймворк с открытым исходным кодом, предназначенный для перемещения данных между слоями в DWH и выполнения различных трансформаций данных (очистка, дедупликация, агрегирование, фильтрация, обогащение), а также для формирования документации и линейджа. Один из сценариев использования — формирования слоя DDS в модели Data Vault. Airflow в данном случае помогает оркестрировать задачи, которые извлекают данные и загружают их в хранилище. Dbt, как правило, позволяет аналитикам, использующим SQL, преобразовывать и трансформировать данные, которые уже находятся в хранилище. Инструменты Airflow + dbt также служат для передачи данных дальше в аналитический слой Mart.

На практике для обслуживания процессов CDC и загрузки данных из источников в сырой и операционный слои DWH сегодня чаще всего используется Spark. Для трансформаций данных и формирования аналитического слоя удобна связка Airflow + dbt. Однако, в зависимости от требований проекта и квалификации команды инженеров может быть построена собственная система с микросервисной архитектурой, реализующая ELT-операции с помощью приложений, написанных на Python, Go, Java и других языках программирования. Это встречается не часто, поскольку тот же Airflow уже является стандартом индустрии с удобным веб-интерфейсом и инструментами поддержки и мониторинга, в то время как для микросервисов необходимо самостоятельно настраивать системы мониторинга и алертинга.

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