DWH. Data Vault 2.0
Когда я впервые услышал о Data Warehouse (DWH), мне казалось, что это просто большая база данных. Однако, углубившись в тему, я понял, что настоящее хранилище данных должно отвечать множеству требований. Например, оно должно обеспечивать гетерогенность — возможность принимать данные из множества различных и несвязанных систем, что отличает его от классических реляционных или транзакционных баз данных. Оно должно обладать гибкостью и расширяемостью, позволяя добавлять новые источники данных без нарушения работы системы. Также важна историчность — способность хранить изменяющиеся атрибуты, такие как смена фамилии сотрудника. Хранилище должно быть способно обрабатывать огромные объемы данных и при этом обеспечивать высокую скорость обновления, позволяя создавать отчеты на основе актуальной информации.
Эти особенности делают хранилище данных сложной и важной системой, необходимой для бизнеса. В этой статье мы разберем классические подходы к построению DWH, их недостатки, а также рассмотрим современный подход Data Vault 2.0, который решает многие проблемы традиционных архитектур.
Архитектура DWH
Подходы к построению хранилищ данных (DWH) претерпели значительные изменения с момента их появления. Первоначально использовались классические методологии Ральфа Кимбалла и Билла Инмона, каждая из которых имела свои преимущества и ограничения. Эти подходы фокусировались на построении централизованных хранилищ с четко структурированными данными для оптимальной аналитики и отчетности. Однако по мере усложнения бизнес-процессов и увеличения объемов данных возникла необходимость в более гибких и масштабируемых архитектурах, таких как Data Vault, которые способны поддерживать историчность, легко адаптироваться к изменениям и обеспечивать работу с гетерогенными источниками данных.
Рассмотрим классические подходы к построению хранилищ и обозначим их проблемы.
Классический подход
Традиционная архитектура DWH может быть построена по методу Ральфа Кимбалла (Ralph Kimball)или Билла Инмона (Bill Inmon).
Метод Кимбалла предполагает выгрузку данных из источников в хранилище, построенное по схеме «звезда», где центральный элемент — это таблица фактов, а лучи — измерения (свойства + атрибуты).
Методологии построения DWH Ральфа Кимбалла (Ralph Kimball)
Примером применения классического подхода к построению DWH могут служить данные розничной торговли, где данные структурируются по схеме «звезда». В центре находится таблица фактов продаж, содержащая такие метрики, как объем и сумма продаж, себестоимость и прибыль. Вокруг нее расположены измерения, которые позволяют анализировать данные по различным критериям: продукт (категория, бренд), клиент (возраст, пол), время (день, месяц, год) и локация (магазин, регион). Такая структура позволяет агрегировать данные и получать аналитические отчеты, например, по продажам конкретных товаров в разных регионах и в различные периоды времени.
Метод Инмона предполагает сначала разработку, проектирование и создание централизованного хранилища и только потом создание витрин для выгрузки данных, отчетов и т. д.
Методологии построения DWH Билла Инмона (Bill Inmon)
Проблемы классического подхода
Жесткая кардинальность связей. В классических архитектурах DWH, таких как схема «звезда» или «снежинка», внешние ключи создают жесткие ограничения между таблицами. Это означает, что каждая запись в таблице фактов должна иметь соответствующую запись в таблице измерений. При изменении или добавлении данных необходимо учитывать все связи и зависимости, что усложняет обновление данных и приводит к проблемам с согласованностью.
Дублирование данных. Для обеспечения историчности часто приходится дублировать данные, добавляя к ним временные атрибуты, такие как from_date и to_date. Это приводит к избыточности: одна и та же информация хранится в нескольких местах с незначительными изменениями. В результате объемы данных значительно увеличиваются, усложняется поддержка и возрастает риск ошибок при обновлении или изменении данных.
Нелинейная сложность доработки. Добавление новых функций, таблиц или источников данных в классической архитектуре требует значительных усилий. Каждое новое требование может привести к необходимости перепроектирования существующих связей и таблиц, что приводит к нелинейному росту сложности. Чем больше добавляется новых элементов, тем больше требуется изменений в уже существующих структурах, что делает процесс трудоемким и подверженным ошибкам.
Слишком рано приходящие данные. В гетерогенных системах данные могут поступать с разной скоростью. Например, в ритейле обновления по продажам могут приходить быстрее, чем данные по созданию новых магазинов. В результате в таблице фактов появляются записи о продажах в магазинах, которых еще нет в таблице измерений. Это приводит к ошибкам и необходимости дополнительной обработки данных, чтобы устранить несоответствия.
Большое время разработки. Проектирование и реализация классической архитектуры требует значительного времени. Построение схемы «звезда» или «снежинка» с учетом всех связей и ограничений, написание сложных ETL-процессов и обеспечение согласованности данных занимают много ресурсов и требуют тщательного планирования. Это делает внедрение системы долгим и дорогим процессом.
Проблемы с историчностью данных. Обеспечение историчности на уровне атрибутов в классических DWH-системах требует дополнительных временных меток или версий записей, что усложняет запросы и ведет к дублированию данных. Историчность на уровне фактов практически невозможно реализовать без значительного усложнения структуры данных, что снижает производительность и увеличивает объемы хранения.
Невозможность описать реальность с помощью «звезды». Реальные бизнес-процессы часто гораздо сложнее, чем можно описать схемой «звезда» или даже «снежинка». Попытка учесть все вариации и связи приводит к появлению сложных иерархий и многомерных комбинаций, которые становятся трудными для поддержки и анализа. Это приводит к необходимости постоянных модификаций и перестроений структуры хранилища.
Сложность разделения доступа к данным. В классических DWH-системах трудно разграничить доступ к отдельным атрибутам или свойствам данных. Например, если необходимо предоставить пользователю доступ только к определенным атрибутам в таблице фактов, это часто требует создания дополнительных представлений или витрин данных. Такое решение усложняет архитектуру и увеличивает количество необходимых изменений при расширении системы.
Эти проблемы делают классический подход менее гибким и масштабируемым, что особенно критично в современных условиях, когда бизнес требует быстрой адаптации к изменениям и возможности работы с большими объемами данных из разных источников.
Пример: «Проекты-ресурсы»
Многие проблемы классического подхода можно увидеть даже на очень простом примере. Предположим мы имеем:
таблицу resource (ресурсов, т. е. сотрудников);
таблицу project (проектов);
таблицу allocation (распределения), где указано, какой ресурс в какое время был задействован в каком проекте.
Для обеспечения историчности в проектах, таблицах и других сущностях используются атрибуты from_date и to_date.
Классический подход
Предположим мы через некоторый промежуток времени получаем от бизнеса следующие требования:
1. Добавить информацию об отделах сотрудников
Проблемы:
Изменение схемы данных: Потребуется добавить новую таблицу Departments и установить связи с таблицей Resource. Это изменение приведет к необходимости обновления схемы базы данных, а также может затронуть существующие ETL-процессы и отчеты, которые зависят от текущей структуры данных.
Изменение ETL-процессов: Нужно будет изменить процессы загрузки данных, чтобы учитывать новую таблицу и связи между отделами и сотрудниками. Это увеличит время выполнения ETL-задач и усложнит поддержку.
Обновление отчетов и витрин: Существующие отчеты и витрины данных, которые используют данные сотрудников, нужно будет адаптировать под новую структуру, что может привести к временным сбоям в их работе.
2. Добавить иерархию отделов
Проблемы:
Изменение структуры таблицы: Потребуется добавить дополнительные поля в таблицу Departments, например, Parent_Department_ID, чтобы хранить информацию о родительских отделах. Это изменение повлияет на все существующие процессы, работающие с данными отделов.
Обновление связей и ограничений: Необходимо будет установить новые ограничения внешних ключей для корректного управления иерархией, что усложнит целостность данных и увеличит риск ошибок при загрузке данных.
Изменение отчетов и витрин: Витрины и отчеты нужно будет адаптировать для отображения иерархической структуры отделов, что потребует времени и ресурсов на доработку.
3. Добавить возможность сложной вложенности отделов (прямое и функциональное подчинение)
Проблемы:
Изменение логической модели данных: Для хранения информации о прямом и функциональном подчинении потребуется добавить дополнительные поля или создать новые таблицы, например, Department_Relationships, где будут храниться типы подчинения. Это усложнит логическую модель и увеличит количество таблиц и связей.
Модификация ETL-процессов: Придется переработать существующие ETL-процессы, чтобы учитывать оба типа иерархии. Это увеличит время на обработку данных и усложнит отладку.
А теперь рассмотрим подход Data Vault 2.0
Подход Data Vault 2.0
Data Vault 2.0 — это современный подход к построению хранилищ данных, разработанный для решения проблем классических архитектур. В отличие от методов Кимбалла и Инмона, Data Vault 2.0 позволяет эффективно управлять изменяющимися данными и поддерживать историчность без дублирования информации и избыточности. Его ключевые элементы — хабы, ссылки и сателлиты — структурируют данные так, чтобы можно было легко добавлять новые источники и атрибуты, не нарушая целостность системы. Это делает Data Vault 2.0 идеальным решением для динамичных проектов с большим количеством гетерогенных данных, где требуется гибкость и масштабируемость.
В подходе DataVault 2.0 есть достаточно простые и понятные правила/требования, предъявляемые к сущностям.
Хабы, ссылки, сателлиты
Хабы — это объекты, т. е. сущности, в которых обычно хранится только суррогатный или бизнес-ключ. Записи в хабах не меняются, а ссылки наружу недопустимы.
В хабах используются следующие поля:
По сути, хабы — это только id, которые не меняются, как и ссылки на них. В случае изменения названия отдела это название выносится в сателлит, где используются атрибуты from_date и to_date.
Таблица ссылок — это таблица связей между хабами, которая связывает отделы, людей и т. д. По сути, ссылки представляют собой глаголы (например, «сотрудник состоит в отделе»). В таблице хранятся суррогатные ключи (ключи связываемых хабов/сущностей и единый суррогатный ключ), при это количество ссылок может быть от двух и до бесконечности.
Satellite — это таблица свойств/атрибутов (фамилии, имена, телефоны и т. д.) сущности. Набор свойств и атрибутов может быть произвольным, т. е. каждая сущность может иметь сколько угодно сателлитов и ссылаться на хаб или линк, но напрямую на satellite никто ссылаться не может. Именно через такие таблицы реализуется историчность данных.
Пример «Проекты-ресурсы»
Рассмотрим аналогичный пример. Для начала приведем его к виду DataVault
В получившейся структуре:
синие блоки hub_ — , объекты, они же ресурсы, отделы, проекты, сущности
желтые блоки sat_ — satellite, атрибуты объектов
красные ромбы link_ — таблицы ссылок.
Решение с использованием подхода Data Vault 2.0
В подходе Data Vault 2.0 каждое новое бизнес-требование обрабатывается путем добавления новых хабов, ссылок и сателлитов, не изменяя при этом существующую структуру данных. Это обеспечивает гибкость и минимизирует влияние на существующую архитектуру. Рассмотрим, как можно реализовать каждое из приведенных выше требований.
Добавить информацию об отделах сотрудников
Для добавления таблицы отделов в Data Vault потребуется создать хаб для хранения уникальных идентификаторов отделов и их ключевых атрибутов.
Создание хаба для отделов (hub_department)
Создание сателлита для атрибутов отделов (sat_department 1, 2)
Создание ссылки между сотрудниками и отделами (link_department_resource)
Таким образом, мы создаем новые таблицы для отделов, не затрагивая существующую структуру.
Структура Data Vault
Добавить иерархию отделов
Для добавления иерархии между отделами создается новая ссылка, описывающая отношения между отделами.
Создание ссылки иерархии отделов (link_department)
Эта таблица позволяет фиксировать иерархию между отделами, при этом поддерживая изменения в структуре без необходимости изменения хаба или сателлитов отделов.
3. Добавить возможность сложной вложенности отделов (прямое и функциональное подчинение)
Для реализации сложной иерархии с несколькими типами подчинения можно использовать ту же таблицу ссылок иерархии отделов (link_department), либо создав новую таблицу ссылок.
Это также не потребует никаких изменений в уже созданной структуре данных и поэтому не повлечет значительных изменений уже созданных отчетов и т.д.
Особенности загрузки данных
В обычной реляционной базе данных загрузка данных — это многоступенчатый процесс. Любой SELECT или выборка данных собирает 10–15 JOIN-ов, при этом приходится загружать таблицы по очереди, потому что на них ссылаются другие таблицы. Таким образом весь этот процесс занимает достаточно большое количество шагов, зависящее от количества таблиц и от того, как они джойнятся.
При подходе Data Vault все происходит только в два шага.
Сначала загружаются хабы, которые ни на что не ссылаются и представляют собой независимые самодостаточные единицы — это просто информация о наших объектах. При этом количество хабов, которые загружаются параллельно, не имеет значения.
После загрузки хабов загружается все остальное, потому что все таблицы ссылок и сателлиты ссылаются только на загруженные хабы. Таким образом, мы можем загрузить все данные в наше хранилище всего за два шага.
Преимущества подхода Data Vault
Гибкость — В Data Vault любая новая сущность добавляется в виде нового хаба, который хранит уникальные ключи и идентификаторы. Связи между сущностями оформляются через таблицы ссылок, а атрибуты и их изменения хранятся в сателлитах. Такая структура позволяет легко добавлять новые сущности или связи, не затрагивая существующие таблицы. Например, добавление новой таблицы для хранения информации об отделах сотрудников требует создания лишь нового хаба и сателлитов для его атрибутов, что никак не повлияет на другие сущности, такие как сотрудники или проекты.
Отказоустойчивость — В случае отказа или недоступности одного из сателлитов, система продолжает работать с доступными данными. Если, например, сателлит с контактными данными сотрудников временно недоступен, другие сателлиты, такие как информация о должностях или проектах, будут по-прежнему работать корректно. Это позволяет минимизировать влияние инцидентов на общую работоспособность хранилища и обеспечивает высокую доступность системы.
Расширяемость — Подход Data Vault предусматривает, что один хаб может иметь множество сателлитов, каждый из которых хранит отдельный набор атрибутов. Это упрощает добавление новых характеристик или свойств сущностей без изменения самой структуры хаба или других сателлитов.
Быстрота и удобство разработки ETL-процессов. Каждый сателлит практически независим и хранит отдельный набор атрибутов, что упрощает разработку и тестирование ETL-процессов. Можно разрабатывать и загружать данные в новые сателлиты без необходимости изменять, пересчитывать другие сателлиты или хабы. Это позволяет эффективно разрабатывать и внедрять новые функциональности, избегая сложных перекрестных зависимостей между процессами.
Agile-подход «из коробки» — В Data Vault можно начать работу с уже существующими объектами и постепенно добавлять новые элементы. Например, можно сначала создать хабы для ключевых сущностей, таких как сотрудники и проекты, а затем, по мере уточнения требований, добавлять новые сателлиты и связи. Это позволяет реализовать проект поэтапно, быстро адаптируясь к изменениям и новым требованиям бизнеса.
Отсутствие избыточности данных — изменяющиеся атрибуты сущностей выносятся в отдельные сателлиты, что позволяет избежать дублирования данных. Например, информация о местоположении сотрудника или его контактные данные, которые могут часто изменяться, хранятся в отдельном сателлите и обновляются независимо от других атрибутов, таких как имя или должность. В отличие от классических моделей, где такие изменения могут дублироваться в основной таблице, Data Vault минимизирует избыточность и снижает объемы хранения данных.
Отсутствие аномалии историчности свойств (измерений), В Data Vault историчность измерений реализуется с помощью отдельных сателлитов, которые хранят все изменения атрибутов. Благодаря этому подходу можно легко получить данные на любую интересующую дату или извлечь последнюю актуальную запись без сложных и ресурсоемких запросов. Например, если изменяется название отдела, это изменение фиксируется в сателлите, и текущая информация всегда доступна по соответствующему хэш-коду. Это упрощает управление историческими данными и снижает риск появления ошибок, связанных с некорректным представлением изменений.
Недостатки
Обилие JOIN-ов. Каждая сущность разделяется, как минимум, на хаб и на сателлит, что увеличивает количество таблиц в два раза. Кроме того, в отдельные таблицы выносятся все ссылки, которые раньше были внутри. Соответственно, количество таблиц возрастает. Если по каким-то причинам большое количество джоинов будет делаться медленно, то это может стать проблемой.
Обязательное наличие витрин данных. Это можно считать недостатком, хотя вряд ли для конечного пользования кто-нибудь дает нормальную форму базы и предлагает поискать в ней данные. В любом случае строятся витрины для экономистов, финансистов, аналитиков и т. д.
Проблемы с данными в EDW
Часто возникают проблемы при работе с Master Data Management (MDM), также известным как нормативно-справочная информация (НСИ). В контексте MDM ключевая задача — обеспечить консистентность и единообразие данных, поступающих из различных источников. Например, если данные о сотрудниках поступают из трех разных систем, необходимо провести их сопоставление и интеграцию. При этом каждая система может хранить данные в разном формате, с разными идентификаторами и уровнем детализации. Это приводит к ряду проблем:
Отсутствие единого ключа: В каждой системе сотрудник может иметь разные идентификаторы, что затрудняет автоматическое сопоставление записей. Требуется разработка алгоритмов маппинга или использование дополнительных атрибутов (например, ФИО и дата рождения), что не всегда дает точный результат.
Различие форматов и наименований: Одни и те же данные могут быть представлены по-разному в разных системах. Например, название департамента может быть указано сокращенно или с различными префиксами, что требует нормализации и приведения к единому стандарту.
Дублирование и разночтения данных: Из-за различных источников одна и та же информация может иметь расхождения. Например, в одной системе указано одно подразделение сотрудника, а в другой — другое. Это требует разрешения конфликтов и выбора эталонного источника.
Эти проблемы усложняют процесс интеграции данных в хранилище и требуют тщательного проектирования и использования надежных инструментов для управления и консолидации мастер-данных.
На изображении ниже показан пример реальных данных, где одни и те же сотрудники имеют различные идентификаторы в разных системах.
Для сопоставления данных из различных источников с единой общей таблицей (Common) используется промежуточная таблица маппинга, которая позволяет установить соответствие между разными идентификаторами и упорядочить информацию.
Сведение нескольких записей в одну
MDM позволяет решить проблему разнородности ключей, которые приходят из разных систем и складываются в один хаб. Поступающие данные сопоставляются с данными в эталонной таблице автоматически или вручную. Для автоматического маппинга можно использовать ИИ для оценки записей по похожести, чтобы, например, маппить данные, похожие на 95%.
Верхнеуровневая схема хранилища
Прежде чем данные попадут в основное хранилище и станут доступны для аналитики, они проходят через несколько ключевых этапов обработки. Это позволяет последовательно трансформировать и очищать данные, обеспечивая их качество и целостность. Вначале данные из различных источников загружаются в слой сырых данных (Staging.Raw), где они сохраняются в неизменном виде для упрощения последующих ETL-процессов и обеспечения возможности аудита. Далее на уровне Staging.Intelligence данные стандартизируются и нормализуются: приводятся к единым названиям полей, единицам измерения и формату. После этого происходит их консолидация в слое MDM, где с помощью таблиц маппинга данные объединяются и связываются с эталонными записями. Только после этого информация попадает в Enterprise Data Warehouse (EDW), где она структурируется по принципам Data Vault и становится доступной для создания витрин данных, используемых в аналитических отчетах.
Слои данных:
Source Systems — источники, реальные АС
Staging. Raw — из Source Systems данные собираются и складываются в слой сырых данных (Staging). При этом данные складываются «один в один», чтобы упростить ETL-процедуру и поиск ошибок.
Staging. Intelligence — На этом этапе данные приводятся к единым единицам измерения, единым названиям полей и т. д.
MDM (Master Data Managment) — на этом этапе мы приводим данные с помощью mapping таблицы к common таблицам, в которых находится единственная запись для одного объекта, которую мы и считаем правильной.
EDW (Enterprise Data Warehouse) — хранилище с сателлитами, хабами и линками, поверх которых создаются витрины.
Information Delivery — Витрины данных
Алгоритм создания витрин данных
Выводы
Подход Data Vault позволяет эффективно справляться с задачами интеграции данных из множества различных источников и поддерживать их историчность, что делает его востребованным в крупных и динамичных системах. Благодаря четкому разделению неизменяемых бизнес-ключей (хабов) и изменяемых атрибутов (сателлитов), а также гибкой модели связи между ними (линки), Data Vault обеспечивает высокую адаптивность к изменениям бизнес-логики и новым требованиям. Однако, как и любая архитектура, Data Vault не является универсальным решением и требует внимательного анализа условий проекта перед внедрением. Важно учитывать специфику используемых баз данных и оценивать необходимость его применения в зависимости от масштабов системы и частоты изменений.
Подход Data Vault будет полезен:
В больших и сложных системах хранения данных, где большое количество разных источников. Таких систем сейчас очень много благодаря использованию микросервисной архитектуры. Каждый микросервис имеет свою базу со своим ограниченным набором полей, которые приходится выгружать.
В системах, где много изменений: Agile подход, много новых источников.
В системах, где много данных и нужна историчность.
В системах, где требуется параллельная разработка. Само хранилище можно строить разными командами, кусками и с разных концов, поскольку есть простые и четкие правила, как это делать.
В системах которые, позволяют делать быстрые JOIN-ы (современные базы данных, например, Greenplum, Snowflake, Vertica, Postgres).
Подход Data Vault будет плохо работать:
На проектах с медленными JOIN-ами, например, Hadoop, Hive, noSQL.
На небольших и простых проектах, где не имеет смысла городить все это, «забивая гвозди микроскопом». Где небольшая реляционная БД позволит решить все проблемы.
На проектах, где изменение требований маловероятно.
На проектах с использованием транзакционных баз данных, где все задачи позволяет решать обычный подход.
Полезные ссылки
Базовое объяснение: Data Engineering: ETL, ELT, Data Pipeline, Data Warehouse, Data Lakes, Data Marts. (Иван Шамаев) Раздел: обзор методологий, принципов и концепций разных типов хранилищ данных.
https://ivan-shamaev.ru/data-engineering-etl-pipeline-data-warehouse-datalake/#i-3
Базовое объяснение: Data Vault 2.0. Николай Голов.
https://www.youtube.com/watch? y=-ZgzpQXsxiO
Видео-курс: Основы теории создания хранилищ данных (DWH). Вячеслав Ерин.
http://www.youtube.com/watch? y=-vi6-PYiB-yE
Продвинутое объяснение: Организация хранилища в manychat и ее стоимость. Николай Голов.
https://www.youtube.com/watch? y=BnJzYUI96XE
Vertica+Anchor Modeling = запусти рост своей грибницы. Николай Голов.
https://habr.com/ru/company/avito/blog/322510/
Data Vault и Anchor Modeling в Яндекс. Евгений Ермаков.
http://www.youtube.com/watch? y=_W-38jTkNLM
