Снежинка, Data Vault, Anchor Modeling. Какая методология проектирования DWH подойдет для вашего бизнеса?

Данные в Data Vault представлены в виде трех сущностей:

1. Хаб (hub) — бизнес-сущность, например клиент, продукт, заказ. Связывается только с Линком или с Сателлитом. Хаб-таблица содержит несколько полей: натуральные ключи сущности, суррогатный ключ, ссылка на источник записи и время добавления записи.
2. Линк (связь, link) — представление отношений между Хабами. Линки строятся в виде таблиц «многие ко многим» и содержат ссылки на суррогатные ключи связанных Хабов.
3. Сателлит (satellite) — изменяемые атрибуты сущностей, контекстные данные для хаб-таблицы, связанные с Хабами и Связями по принципу «один ко многим».

Плюсы Data Vault

• Интуитивно понятная структура, которая позволяет сформировать витрины под любые потребности бизнеса
• Простой доступ к анализу — первые верхнеуровневые отчеты доступны уже после загрузки Хабов и Связей
  
• Можно независимо разрабатывать смежные источники и легко заменять их, так как данные почти полностью отвязаны друг от друга
  

Минусы Data Vault

• Большое количество таблиц и join’ов, которые повышают риск ошибок и замедляют выполнение запросов относительно традиционных DWH, где таблицы более денормализованы
• Сложность выстраивания проверки данных из-за большого количества сущностей и сложных связей между ними
• Методология хорошо задокументирована, но требует от специалиста богатого абстрактного мышления, дополнительных навыков и знаний особенности работы специфических функций, например хеширования

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

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

Anchor Modeling (Якорная модель)

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

Якорная модель включает конструкции:

1. Якорь — представляет собой сущность или событие, содержит суррогатные ключи, ссылку на источник и время добавления записи
2. Атрибут — используется для моделирования свойств и характеристик якорей, содержит суррогатный ключ якоря, значение атрибута, ссылку на источник записи и время добавления записи
3. Связь — моделирует отношения между якорями
4. Узел — используется для моделирования общих свойств (состояния)

Плюсы Anchor Modeling

• Нормализованная модель, которая эффективно обрабатывает изменения и позволяет масштабировать хранилища данных без отмены предыдущих действий
• Можно независимо разрабатывать смежные источники, так как данные почти полностью отвязаны друг от друга
• Значительная экономия места в связи с отсутствием нулевых значений (null) и дублирования

Минусы Anchor Modeling

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

Anchor Modeling представляет возведенную в абсолют нормализацию данных: одна таблица — один атрибут (характеристика). Обеспечивает низкую стоимость добавления новых атрибутов даже на данных объемом в несколько десятков терабайт, но делает таблицу абсолютно не читаемой для человека. Усложняет процессы по поддержанию документации в актуальном состоянии, повышает стоимость разработки, так как увеличивает порог входа в проект и количество задач для обслуживания.

Выбор методологии для DWH

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

При выборе методологии для проектов специалисты Qlever Solutions оценивают объем поступающих новых данных, перспективы изменения (текучесть) и появления новых источников данных. На основе описанных ранее критериев мы разработали алгоритм выбора методологии построения DWH:

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

Так как исходные данные хранятся на Staging слое, можно полностью перейти на новую методологию, без потери данных и с минимальными изменениям в ELT/ETL процессах. Возможен органический переход от более простой модели Снежинка к Data Vault или Anchor Modeling для масштабирования и достижения необходимой гибкости хранилища.

***

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

Читайте про внедрение DWH, которое может стать дорогим удовольствием, только усугубляющим проблемы в работе с данными, и узнайте, как этого избежать

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

Планируете внедрение DWH?

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