Data Vault 2.0 остаётся одним из самых популярных методов моделирования данных. Его выбирают за гибкость, масштабируемость и устойчивость к изменениям. Этот разработанный Дэном Линстедом подход помогает организациям быстро адаптироваться к новым бизнес-требованиям, легко интегрировать новые источники данных и надёжно хранить исторические данные.

Эта статья будет полезна дата-инженерам, аналитикам данных, архитекторам данных и бизнес-аналитикам. Она поможет усовершенствовать умения в моделировании данных. Мы рассмотрим ключевые принципы Data Vault 2.0 и на практическом примере покажем, как разложить сырые данные по Data Vault 2.0.

Data Vault — это техника моделирования, которая помогает спроектировать гибкое и масштабируемое корпоративное хранилище данных. Представляет собой детализированный, исторически отслеживаемый и уникально связанный набор нормализованных таблиц, поддерживающий одну или несколько функциональных областей бизнеса. Это гибридный подход, сочетающий в себе преимущества третьей нормальной формы (3NF) и схемы «звезда».

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

Схема «звезда» в многомерном моделировании, которая получила своё широкое применение в 80-ых годах, имела ряд ограничений. При постоянно возрастающем объёме данных в организациях на рубеже 90-ых годов этот подход уже не соответствовал предъявляемым требованиям к историзации, гибкости, масштабируемости и интеграции данных. Таким образом, Data Vault был создан для преодоления недостатков схемы «звезда» в многомерном моделировании. Схема «звезда» (или снежинка) обычно хорошо подходит для простых и стабильных аналитических систем, но она становится менее гибкой при изменении бизнес-требований или добавлении новых источников данных. К тому же, имеются трудности в обслуживании данной модели и поддержании историчности атрибутов. Например, обновления атрибутов измерений могут потребовать внесения изменений в нескольких местах.

Data Vault 1.0 был разработан и представлен Дэном Линстедтом в конце 1990-х. В начале 2000-х годов дизайн Data Vault был протестирован, усовершенствован и внедрён у первых пользователей. Data Vault 1.0 был спроектирован как совершенно новый подход к моделированию данных, а не адаптация существующих моделей. Он был основан на концепции архитектуры «транзитная система» (hub-and-spoke), где данные разделены на три типа таблиц: хабы (hubs), ссылки (links) и сателлиты (satellites).

В 2013 году Дэн Линстедт и Майкл Ольшимке представили Data Vault 2.0. Это расширение и улучшение версии 1.0 с новыми функциями и улучшенными практиками. Data Vault эволюционировал, чтобы решить ограничения версии 1.0 и оптимизировать процесс создания и управления хранилищами данных.

Data Vault 2.0 по-прежнему использует архитектуру hub-and-spoke, но добавляет новые концепции:

• Business Vault — содержит бизнес-правила и преобразования, применяемые к исходным данным.
• Raw Vault — это сырой слой данных, где хранятся исходные данные.
• Information Mart и Data Mart — это аналитический слой данных. Он предназначен для построения отчётов и визуализации данных для пользователей.

Data Vault 1.0 и 2.0 различаются по своей реализации и оптимизации хранилища данных.

Во-первых, Data Vault 2.0 использует хеш-ключи для создания идентификаторов для хабов, ссылок и сателлитов, что увеличивает производительность, масштабируемость и отслеживаемость данных — это и есть основное различие между Data Vault 1.0 и Data Vault 2.0. Оно заключается во введении хэширования в качестве суррогатных ключей вместо использования последовательных ключей. Это стало сдвигом парадигмы в способе загрузки и реализации Data Vault. Такой подход открыл возможности для устранения ссылочной целостности, обеспечиваемой базой данных.

Если раньше ссылочная целостность применялась в Data Vault 1.0, это означало, что необходимо указывать внешние ключи между сателлитом и его хабом/ссылкой, а также между ссылкой и её хабами.

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

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

Во-вторых, в Data Vault 2.0 вводится концепция бизнес-ключей. Бизнес-ключи являются естественными ключами исходных систем, хранимыми в хабах для связывания данных из различных источников.

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

В завершение темы эволюции модели Data Vault отметим, что принципы проектирования Data Vault — модульность, гибкость и масштабируемость — похожи на принципы микросервисов и проектирования, ориентированного на домены (Domain Driven Design). Эти подходы появились примерно в одно и то же время в начале 2000-х годов. Оба эти подхода акцентируют внимание на разделении, адаптивности и независимом развитии. Поэтому Data Vault хорошо дополняет архитектуру микросервисов для управления и интеграции сложных данных.

Архитектура Data Vault 2.0 основана на трёх уровнях (см. рис.1) :

1. Область подготовки данных (слой Staging/ODS), которая собирает необработанные данные из источников.

2. Уровень корпоративного хранилища данных (слой DDS), смоделированный как модель Data Vault 2.0.

3. Уровень представления (слой Data Marts & Information Marts) с аналитическими витринами в виде звёздных схем и других структур.

Архитектура Data Vault 2.0 поддерживает разные способы загрузки данных:

• Пакетную загрузку из источников.
• Загрузку в реальном времени через корпоративную шину данных (ESB) или сервисно-ориентированную архитектуру (SOA).

Также можно интегрировать неструктурированные NoSQL данные в Data Vault 2.0. Поскольку Data Vault 2.0 не зависит от платформ, NoSQL можно использовать на всех уровнях хранилища данных, включая подготовку данных, корпоративное хранилище и уровень предоставления информации.

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

При проектировании модели данных Data Vault архитекторы и аналитики затрагивают такие темы, как:

• Источники данных;
• Бизнес-правила для агрегации и преобразования данных;
• Типы данных;
• Сценарии использования и другие аспекты.

В Data Vault 2.0 требования собираются на протяжении всего проекта. В этом отличие от классического подхода, где все требования собираются в начале проекта.

По мнению Линстэда, лучший подход — это использовать сырые витрины данных (Raw Marts). Эти витрины создаются для быстрого предоставления данных бизнес-пользователям. Они содержат сырые данные и неполную бизнес-логику. Витрины создаются для обсуждения требований с ограниченным числом пользователей, а не для распространения.

Итак, процедура сбора требований состоит в следующем:

• Определите необходимые источники данных для сырой витрины.
• После загрузки данных в сырой Data Vault создайте сырую витрину из этих данных.
• Постройте сырой отчёт или дашборд и предоставьте его бизнес-пользователям.
• Позвольте пользователям добавлять комментарии и исправления.
• Соберите бизнес-правила и требования, спрашивая пользователей о проблемах в отчётах и необходимых изменениях.
• Переведите бизнес-правила в программную логику: реализуйте их в ETL-процессах или SQL-скриптах, чтобы превратить сырые данные в информацию.

В этом разделе будут представлены сущности, используемые в моделировании Data Vault 2.0. Это хабы, ссылки и сателлиты. Мы расскажем, как находить бизнес-ключи в исходных данных и связывать их с другими бизнес-ключами в Data Vault с помощью ссылок. Также покажем, как выявлять дополнительные атрибуты в исходных данных и моделировать их как сателлиты. Мы рассмотрим разделение сателлитов по критериям, например, по типу данных или источнику.

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

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

Бизнес-ключи являются основными атрибутами в хабах и используются для установления связей между различными сущностями модели данных Data Vault 2.0. Они обеспечивают точную идентификацию и отслеживание данных, что критически важно для бизнес-анализа и отчётности.

Фактически, чтобы выделить сущность «Хаб», необходимо идентифицировать её бизнес-ключ.

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

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

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

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

Мета-атрибуты (LoadDate и RecordSource) могут размещаться в начале сущности для упрощения дизайна и обслуживания.

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

Критерии определения хабов и их бизнес-ключей в моделировании Data Vault 2.0:

• Уникальность и стабильность: Бизнес-ключи должны быть уникальными и устойчивыми к изменениям, чтобы обеспечить точную идентификацию и отслеживание объектов.
• Значимость для бизнеса: Выбранные хабы и бизнес-ключи имеют важное значение для бизнес-операций и предоставляют критически важные данные для аналитики и отчётности.
• Удобство интеграции: Хабы и бизнес-ключи должны легко интегрироваться с другими системами и процессами, поддерживая консистентность данных и легкость доступа к информации.

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

Бизнес-ключи, как правило, значимы для бизнеса. Чтобы выделить бизнес-ключи или хабы в модели Data Vault для какой-либо организации, необходимо погрузиться в бизнес-процесс, чтобы определить основные его элементы и их взаимосвязи. Примеры бизнес-ключей для e-commerce: уникальные идентификаторы для каждого клиента, SKU товаров, номера заказов, уникальные номера для счетов-фактур, идентификаторы для накладных на доставку, коды магазинов, номера возвратов, уникальные коды для подарочных сертификатов или купонов.

Тип данных бизнес-ключа ориентирован на данные источника. Некоторые бизнес-ключи представлены целыми числами (bigint), но чаще всего бизнес-ключ представлен строковыми значениями (string). Поэтому тип данных и длина атрибута должны тщательно моделироваться с учетом исходной системы данных. Для моделирования типа данных и длины атрибута бизнес-ключа рекомендуется сначала собрать информацию обо всех бизнес-ключах, которые будут использоваться в модели. Например, проанализировать, как эти ключи хранятся в исходных системах (тип данных, длина строк, наличие специальных символов и т.д.). Это поможет определить наиболее подходящий тип данных и длину для ключей в модели Data Vault. Если бизнес-ключ в исходной системе представлен строкой длиной 50 символов, то нужно учесть этот размер при проектировании модели. Можно немного увеличить эту длину, чтобы предусмотреть возможные изменения в будущем.

В некоторых случаях полезно стандартизировать тип данных для всех бизнес-ключей, чтобы упростить управление и обработку данных. Например, использовать тип VARCHAR определенной длины для всех бизнес-ключей. Оптимальной длиной может быть VARCHAR(255), что часто используется в Data Vault для хранения большинства строковых ключей. Это должно покрывать большинство сценариев при моделировании.

Рекомендуется избегать использования типов данных, которые могут изменить значение ключа при миграции или конверсии данных (например, плавающие числа или типы данных времени и даты).

Каждый тип сущности Data Vault 2.0 содержит стандартные атрибуты, которые помогают в создании модели. Тип сущности «хаб» содержит следующие атрибуты, которые являются общими для всех хабов Data Vault 2.0:

• Хеш-ключ (Hash key)
• Бизнес-ключ(и) (Business key(s))
• Дата загрузки (Load date)
• Источник записи (Record source)

Запросы к модели Data Vault 2.0 требуют гораздо большего числа соединений, чем в традиционном хранилище данных. Поэтому во время создания модели она должна быть подготовлена соответствующим образом для увеличения скорости обработки соединений. Именно здесь используется хеш-ключ, как ключ, основанный на бизнес-ключе. Он становится первичным ключом сущности «хаб» и используется в качестве внешнего ключа для связи с таблицами-ссылками и таблицами-сателлитами.

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

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

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

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

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

Основное преимущество Data Vault — это гибкость. Изменения в бизнес-правилах не требуют переделки ссылок. В Data Vault отношения всегда «многие-ко-многим», но они могут моделировать и другие типы (1:m, m:1, 1:1) без изменения структуры таблиц. Это упрощает ETL-процессы, поскольку не нужно заново проектировать их при изменениях. В традиционных хранилищах данных это было бы невозможно, так как любое изменение требует переделки ETL-процессов. Data Vault сводит такие усилия к минимуму. ИТ-отделу требуется меньше времени на адаптацию к изменениям. Для добавления новой функциональности достаточно создать новые хабы и связать их с уже существующими через ссылки.

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

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

Изменение существующих структур таблиц-ссылок больше не является приемлемой практикой в моделировании Data Vault 2.0. Если добавляются новые ключи в таблицу-ссылку, то лучший вариант — создать новую ссылку для новых поступающих данных и «закрыть» старую ссылку. Закрытие ссылки означает, что новые данные больше не добавляются в таблицу ссылок. Вместо этого новые данные добавляются в новую ссылку.

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

• Хэш-ключ (Hash key)
• Дата загрузки (Load date)
• Источник записи (Record source)

Также можно использовать опциональные атрибуты:

• Дата последнего видения (Last seen date)
• Ключ зависимого дочернего элемента (Dependent child key)
• Дата начала действия (valid_from, Start date
• Дата окончания действия (valid_to, End date)
• Метки активности и удаления (active_flag, deleted_flag)

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

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

Данные в сателлите по методологии Data Vault 2.0 не принято обновлять или модифицировать. В сателлит добавляются только те записи источника, в которых произошли изменения. Таким образом, сателлит работает на основе дельта-обновлений, сравнимо с SCD2 в размерном моделировании.

В методологии Data Vault 2.0 не принято хранить всю описательную информацию бизнес-объекта в атрибутах одного сателлита. Вместо этого рекомендуется распределять данные между различными сателлитами. Рекомендуется разделить сырые данные сначала по системе-источнику, а затем по скорости изменений.

По методологии Data Vault 2.0 стоит начинать с разделения входящих данных по исходной системе. Это означает, что каждый набор входящих данных сохраняется в отдельных сателлитах, то есть один источник данных — один стеллит. Таким образом, данные из денормализованного набора исходных данных распределяются по разным сателлитам, чтобы зависеть от соответствующего бизнес-объекта, связи или транзакции. Преимущества такой практики следующие:

• Позволяет добавлять новые источники данных без изменения существующих таблиц-сателлитов.
• Исключает необходимость изменять входящие данные, чтобы они соответствовали существующим структурам.
• Сохраняет историю исходной системы.
• Максимизирует параллелизм загрузки, так как нет конкуренции за целевой ресурс. Данные могут быть немедленно загружены в сателлит.
• Обеспечивает интеграцию данных в реальном времени без необходимости интеграции их с сырыми данными, загруженными в пакетном режиме.
• Отсутствуют зависимости, требующие от хранилища данных готовности потоковых и пакетных данных одновременно.

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

Помимо атрибутов, хранящих описательные данные в таблице-сателлите, требуются следующие метаданные:

• Дата загрузки (Load Date)
• Источник записи (Record source)
• Родительский хеш-ключ (Parent hash key)
• Дата окончания загрузки (Load end date)
• Дата начала действия (valid_from, Start date
• Дата окончания действия (valid_to, End date)
• Метки активности и удаления (active_flag, deleted_flag)

Следующие атрибуты являются необязательными по Линстэду для сателлитов Data Vault 2.0:

• Дата извлечения (Extract date)
• Хэш-дифф (Hash diff)

Для демонстрации применения техник Data Vault 2.0 при моделировании данных возьмём имеющуюся тестовую OLTP базу Adventureworks. Эта база включает данные, охватывающие различные аспекты бизнеса, такие как производство, продажи, управление персоналом и другие бизнес-процессы. Эта база вполне подходит в качестве источника сырых данных для построения модели Data Vault.
Допустим, нам необходимо построить модель данных, включающую:

• слой DDS c Data Vault 2.0;
• слой Data Mart со схемой «звезда»;
• слой Information Mart c готовыми аналитическими витринами, на которых можно строить дашборд.

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

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

Имея данное описание метрик от отдела аналитики, сначала мы анализируем сырые данные в Adventureworks (условный слой Raw/Staging). Далее нужно выделить необходимые хабы, ссылки и сателлиты и построить слой Data Vault 2.0. На готовом слое Data Vault 2.0 необходимо построить схему «звезда», а на «звезде» сформировать слой конечных аналитических витрин.

В модели Data Vault 2.0 выделение хабов осуществляется на основе ключевых бизнес-объектов или сущностей. Критерии для выделения хабов включают:
1. Уникальные бизнес-ключи (Business Keys).
2. Стабильные бизнес-объекты: Хабы представляют стабильные сущности, которые редко меняются. Изменения данных этих сущностей хранятся в сателлитах, а сами хабы остаются неизменными.
3. Основные бизнес-объекты: Хабы должны быть основными объектами бизнеса, которые важны для анализа и отчетности. Это могут быть такие сущности, как заказы, клиенты, продукты и т.д.

В соответствии с этими критериями из таблиц-источников Sales.SalesOrderHeader, Production.Product, Sales.SalesOrderDetail, Production.ProductCategory, Production.ProductSubcategory были выделены следующие хабы:

• h_order: заказы.
• h_product: продукты.
• h_order_detail: детали заказов (позиции продуктов, входящих в один заказ).
• h_product_category: категории продуктов.
• h_product_subcategory: подкатегории продуктов.

Ссылки были выделены на основе принципов модели Data Vault 2.0, которые включают следующие аспекты:
Связи между основными бизнес-объектами:

• l_sales_order_order_detail_product: соединяет заказы, детали заказов и продукты. Эта ссылка необходима для отображения связи между заказом (h_order), его деталями (h_order_detail) и продуктами (h_product).

Иерархические отношения:

• l_product_product_subcategory: соединяет продукты с подкатегориями продуктов. Эта ссылка отображает иерархическое отношение между продуктами (h_product) и их подкатегориями (h_product_subcategory).
• l_product_subcategory_product_category: соединяет подкатегории продуктов с категориями продуктов. Эта ссылка отображает иерархическое отношение между подкатегориями продуктов (h_product_subcategory) и категориями продуктов (h_product_category). Особенностью данных в Adventureworks есть то, что между продуктом и его категориями нет прямой связи в виде внешнего ключа. Категории можно связать с продуктом только через подкатегории.

Сателлиты выделяются по следующим принципам:

1. Атрибутивные данные: Сателлиты содержат атрибуты, описывающие бизнес-объекты, такие как заказы, продукты и категории.
2. Историчность: Сателлиты поддерживают временную информацию, что позволяет отслеживать изменения атрибутов во времени.
3. Декомпозиция: Каждому хабу соответствует один или несколько сателлитов, которые хранят подробные атрибуты, относящиеся к этому хабу.
4. Минимизация избыточности: Атрибуты, которые меняются с разной частотой, могут быть распределены по разным сателлитам, чтобы минимизировать избыточность данных.

Описание выделенных сателлитов и их атрибутов в этом примере:
1. s_order:
Атрибуты: SalesOrderID, OrderDate, TotalAmount, ExpenseFreight, TotalTax, SubTotal — эти атрибуты описывают основные характеристики заказа, такие как дата заказа, общая сумма, расходы и налоги. Они необходимы для анализа финансовых показателей, таких как выручка, общие расходы, налоги и чистая прибыль.
2. s_product:
Атрибуты: ProductID, Name, ProductNumber, Color, StandardCost, ListPrice, Size — эти атрибуты описывают продукты, включая название, цвет, стоимость и цену. Они необходимы для анализа продаж по продуктам, оценки стоимости продуктов и других аналитических задач.
3. s_order_detail:
Атрибуты: SalesOrderDetailID, SalesOrderID, OrderQty, UnitPrice, UnitPriceDiscount — эти атрибуты описывают детали заказов, такие как количество, цена за единицу и скидка. Они необходимы для анализа средней стоимости заказа, роста средней стоимости заказа и других метрик, связанных с деталями заказов.
4. s_product_category:
Атрибуты: ProductCategoryID, Name — эти атрибуты описывают категории продуктов, включая название категории. Они необходимы для анализа продаж по категориям продуктов и других аналитических задач, связанных с категоризацией продуктов.
5. s_product_subcategory:
Атрибуты: ProductSubCategoryID, ProductCategoryID, Name — эти атрибуты описывают подкатегории продуктов, включая название подкатегории и связь с категорией. Они необходимы для анализа продаж по подкатегориям продуктов и других аналитических задач, связанных с подкатегоризацией продуктов.

Получившаяся модель Data Vault 2.0 представлена на диаграмме ниже:

Следующий шаг — это построение поверх сформированного слоя DDS по Data Vault 2.0 следующего слоя Data Mart по схеме «звезда». Слой «звезды» необходим, поскольку дата марты для дашбордов обычно не строят прямо на слое Data Vault по нескольким ключевым причинам.

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

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

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

В результате получилось 2 таблицы фактов и 2 таблицы измерений.

Таблицы фактов:

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

Таблицы измерений:

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

Далее на готовом слое Data Mart можно строить финальные аналитические витрины. Эти витрины будут уже непосредственно использоваться для построения дашбордов в любом доступном BI-инструменте (Redash, Metabase, Tableau).

Все SQL-скрипты, формирующие слои от сырых данных до аналитического слоя, доступны в репозитории Github.

Дашборд, построенный на аналитическом слое Information Mart, выглядел бы следующим образом:

С таким сырым дашбордом уже можно идти к аналитикам для уточнения и подтверждения бизнес-требований.

Мы прошли путь от анализа сырых данных тестовой OLTP-базы Adventureworks до готовых витрин для визуализации финансовых метрик по заказу условного отдела аналитики. В приведённом примере реализован подход, описанный в разделе «Сбор требований при проектировании Data Vault 2.0» этой статьи статьи.

Building a Scalable Data Warehouse with Data Vault 2.0 by Daniel Linstedt & Michael Olschimke, 2016