Введение

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

В этой статье мы разберем основные подходы к моделированию данных: методологии Кимбелла (Kimball), Data Vault 2.0 и Anchor Modeling. Особое внимание уделим типам медленно изменяющихся измерений (Slowly Changing Dimensions, SCD), их роли в построении аналитических систем и выбору подходящих методик для решения различных задач. Понимание этих концепций поможет проектировать надежные и масштабируемые DWH, соответствующие современным требованиям к аналитике.

Модели данных / Моделирование данных

Моделирование данных — это фундаментальный процесс для проектирования и создания хранилищ данных (Data Warehouses), который помогает структурировать данные и обеспечить их эффективное использование. Различают три ключевых уровня моделирования данных: концептуальная, логическая и физическая модели. Каждый из них имеет свои цели, задачи и уровень детализации. Подход заключается в том, чтобы начать с концептуальной модели, где вы определяете сущности в вашей организации сверху вниз и с точки зрения высокого уровня и моделируете их вместе. Обычно для этого используется диаграмма связей сущностей (ERD).

Концептуальная модель данных представляет собой высокоуровневое представление (сверху вниз).

Цель: Понять бизнес-требования и определить основные сущности и связи между ними.

Концептуальная модель — это высокоуровневое представление данных, которое используется для обсуждения с бизнес-экспертами. Она отвечает на вопрос: «Какие данные важны для бизнеса и как они связаны?» На этом этапе определяются ключевые сущности (например, «Клиенты», «Продукты», «Заказы») и их взаимосвязи, но не углубляются в технические детали.

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

Цель: Структурировать данные, детализировать сущности и связи, сохраняя независимость от конкретной платформы.

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

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

Цель: Реализовать модель в конкретной системе управления базами данных (СУБД).

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

Kimball — некоторые ключевые термины и концепции

Типы ключей

Dimension Surrogate Keys

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

Система DWH/BI должна взять на себя контроль над первичными ключами всех измерений. Вместо использования явных естественных ключей или естественных ключей с добавлением дат, рекомендуется создавать анонимные целочисленные первичные ключи для каждого измерения. Эти суррогатные ключи измерений представляют собой простые целые числа, которые назначаются последовательно, начиная с значения 1, всякий раз, когда требуется новый ключ.

Измерение «Дата» является исключением из правила суррогатных ключей; это высокопредсказуемое и стабильное измерение может использовать более осмысленный первичный ключ.

С сайта Microsoft про Суррогатный ключ

В таблице измерения примера есть суррогатный ключ, который называется Salesperson_SK.

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

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

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

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

Natural, Durable, and Supernatural Keys

Естественные ключи, создаваемые операционными системами-источниками, подчиняются бизнес-правилам, которые находятся вне контроля системы DWH/BI.

Например, номер сотрудника (естественный ключ) может быть изменен, если сотрудник уволится, а затем будет вновь принят на работу. Если хранилище данных должно иметь единый ключ для этого сотрудника, необходимо создать новый устойчивый ключ, который будет постоянным и не изменится в подобной ситуации. Такой ключ иногда называют устойчивым сверхъестественным ключом (durable supernatural key).

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

С сайта Microsoft про Естественный ключ

В таблице измерений примера также есть естественный ключ, который называется EmployeeID.

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

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

Fact Table Surrogate Keys

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

1. В качестве одноколонного первичного ключа таблицы фактов.
2. Для служения мгновенным идентификатором строки таблицы фактов без необходимости навигации через несколько измерений, что упрощает работу ETL.
3. Для обеспечения возможности отката или продолжения прерванного процесса загрузки.
4. Для того чтобы операции обновления таблицы фактов могли быть разделены на менее рискованные операции вставки (insert) и удаления (delete).

Типы измерений (Dimensional Data Modeling)

Хорошая статья: Моделирование измерений в хранилище Microsoft Fabric: таблицы измерений

Conformed Dimension (Согласованное измерение)

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

Outrigger Dimension (Вспомогательное измерение)

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

Shrunken Dimension (Урезанное измерение)

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

Role-Playing Dimension (Ролевое измерение)

Ролевое измерение может использоваться по-разному в одной и той же таблице или других таблицах модели данных. Это фактически одно и то же измерение, но представленное с разных точек зрения. Примером может быть измерение «Дата», которое одновременно используется как «Дата заказа» и «Дата отгрузки» в таблице фактов о продажах.

Dimension to Dimension Table (Таблица связи измерений)

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

Junk Dimension (Сборное или «мусорное» измерение)

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

Degenerate Dimension (Вырожденное измерение)

Вырожденное измерение – это измерение, производное от таблицы фактов, также известное как факт-измерение (Fact Dimension). Оно содержит данные, которые используются для группировки или фильтрации, но не связаны с другими измерениями.

Swappable Dimension (Заменяемое измерение)

Заменяемое измерение – это измерение, которое можно заменить на другое схожее измерение без влияния на структуру или работу хранилища данных. Это позволяет упростить модель данных и повысить производительность.

Step Dimension (Шаговое измерение)

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

Slowly Changing Dimensions, SCD Types

Дополнительно рекомендую почитать wikipedia Slowly changing dimension.

---

Медленно изменяющиеся измерения (Slowly Changing Dimensions, SCD) — это техника обработки изменений в dimensions, которая позволяет сохранять историю изменений или заменять устаревшие значения в зависимости от бизнес-требований. Грамотный выбор типа SCD помогает обеспечить баланс между производительностью, объемом хранилища и аналитическими возможностями.

Типы SCD подразделяются на шесть основных категорий, каждая из которых подходит для определенных сценариев.

SCD Тип 0 (Сохранение оригинального значения)

При использовании типа 0 значение атрибута в измерении никогда не изменяется, поэтому факты всегда группируются по этому оригинальному значению.

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

Это также применимо к большинству атрибутов в измерении даты.

SCD Тип 1 (Перезапись значений без сохранения истории)

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

Применяется, когда история не важна, и бизнес всегда работает с актуальными данными.

• Преимущества: простота реализации.
• Недостатки: потеря исторической информации.

Пример: изменение орфографии в имени клиента или корректировка адреса.

Пример:

SCD Тип 2 (Добавление новой строки — Сохранение полной истории изменений)

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

Минимально для изменений типа 2 необходимо добавить три дополнительных столбца:

• Дата или временная метка начала действия строки (start_date).
• Дата или временная метка окончания действия строки (end_date).
• Индикатор текущей строки.

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

• Преимущества: позволяет точно отслеживать историю.
• Недостатки: увеличение объема данных.

Пример: изменение уровня лояльности клиента или смена региона проживания.

Пример:

SCD Тип 3 (Добавление нового атрибута)

Изменения типа 3 добавляют новый атрибут в измерение для сохранения старого значения атрибута. Новое значение при этом заменяет основное значение атрибута, как в типе 1. Этот подход иногда называют «альтернативной реальностью». Пользователь может группировать и фильтровать данные фактов по текущему значению или по альтернативному. SCD 3 типа используется сравнительно редко.

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

Применяется, когда требуется сохранять только последние изменения.

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

Пример: текущий и предыдущий менеджер клиента.

Пример:

SCD Тип 4 (Добавление мини-измерения)

Тип 4 используется, когда группа атрибутов измерения часто меняется, и их выносят в мини-измерение.

Такая ситуация иногда называется «быстро изменяющееся монстроизмерение (rapidly changing monster dimension)».

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

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

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

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

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

Пример: история изменения цен на продукты.

Пример:

SCD Тип 5 (Добавление мини-измерения и типа 1)

Техника типа 5 используется для точного сохранения исторических значений атрибутов и обеспечения отчетности фактов в соответствии с текущими значениями атрибутов.

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

При обновлении текущего назначения мини-измерения команда ETL должна перезаписать эту ссылку типа 1.

Пример:

SCD Тип 6 (Гибридный подход — Добавление атрибутов типа 1 в измерение типа 2)

Как и тип 5, тип 6 обеспечивает доступ к историческим и текущим значениям атрибутов измерения.

Тип 6 основан на технике типа 2, но добавляет текущие версии атрибутов типа 1 в строки измерения. Это позволяет фильтровать или группировать строки фактов как по значению атрибута типа 2, действовавшему в момент измерения, так и по текущему значению атрибута. В этом случае атрибут типа 1 систематически перезаписывается во всех строках, связанных с данным устойчивым ключом, при обновлении атрибута.

Этот тип сочетает в себе элементы SCD Type 1, 2 и 3. В основной таблице сохраняется текущее значение, полный исторический контекст через новые строки (как в Type 2), а также ограниченная история через дополнительные столбцы (как в Type 3).

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

• Преимущества: максимальная гибкость для бизнес-анализа.
• Недостатки: высокая сложность реализации и управления.

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

Пример:

SCD Тип 7 (Двойные измерения типа 1 и типа 2)

Тип 7 используется для поддержки отчетности «как было» и «как есть».

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

• Для типа 1 фильтруются только текущие строки, а связь идет через устойчивый ключ.
• Для типа 2 ограничения на текущие строки не накладываются, а связь идет через суррогатный ключ.

Эти два подхода реализуются как отдельные представления для BI-приложений.

Пример:

И еще 1 пример:

Выбор типа SCD в зависимости от задач

• Если важна только актуальность данных — SCD Type 1.
• Для детальной аналитики изменений — SCD Type 2.
• Если нужно хранить только последние изменения — SCD Type 3.
• Для разграничения актуальных и исторических данных — SCD Type 4.
• Для сложных бизнес-задач с множеством аналитических сценариев — SCD Type 6 и SCD Type 7.

YouTube Video

Understand Slowly Changing Dimensions

Слои данных в хранилище данных (DWH)

Какие уровни/слои данных есть в современном DWH и зачем они нужны?

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

Основные цели разделения хранилища данных на несколько слоев:

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

Слои могут называться по разному в зависимости от подходов и инструментов.

Обычно в DWH выделяют пять ключевых слоев:

1. STG (Staging): Слой для консолидации данных из различных источников. Временное хранилище для консолидации данных перед обработкой. Данные в сыром виде, без нормализации.
2. ODS (Operational Data Store): Хранилище для операционных данных. Это полноценный слой с обработанными данными, готовыми для оперативного использования. Данные обработаны и приведены к единому формату.
3. DDS (Detail Data Store): Хранилище для детальных исторических данных.
4. CDM (Common Data Marts): Слой, содержащий широкие витрины данных.
5. REP (Reporting)/Consumption Layer (Слой потребления данных): Слой для детальных витрин данных или отчетности.

Не все хранилища включают все эти слои. Основной минимальный набор обычно состоит из STG, DDS и CDM. В зависимости от сложности и объема данных в системе, разные слои могут использовать различные типы СУБД. В более простых системах с меньшим объемом данных можно использовать классические реляционные базы данных, например, PostgreSQL, который часто применяется для создания DWH.

Еще одна визуальная схема слоев данных DWH и Data Lake (Modern Data Warehouse Architecture Layers):

Modern Data Warehouse Architecture

STG (Staging) — Слой приземления данных

Это входная точка хранилища, куда данные загружаются из различных источников: CRM, ERP, файловых систем, API и т.д.

Staging, или промежуточное хранение, это начальный уровень в архитектуре хранилища данных, куда поступает первичная информация из разнообразных источников. Этот слой часто упоминается под разными названиями, такими как STG, staging area или RAW, поскольку он содержит данные в их исходном, необработанном виде. Важно отметить, что этот слой не предназначен для построения отчетов или витрин данных, так как он может быть огромным и неоптимизированным для таких задач.

Характеристики:

• Сырые, несогласованные данные.
• Хранятся в том виде, в котором их отдал источник.
• Минимальная логика обработки — максимум это дедупликация и проверка целостности.
• Форматы могут быть разные: JSON, CSV, Parquet, AVRO, бинарные файлы.

Основные вызовы:

• Контроль качества данных: если источник прислал ошибочные данные, важно вовремя это заметить.
• Историчность: решаем, храним ли мы все версии данных или только последнюю.

ODS (Operational Data Store) — Операционное хранилище данных

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

Operational Data Store (ODS) хранит операционные, часто текущие детальные данные, которые еще не агрегированы. Этот слой служит источником оперативной информации для создания отчетов и может напрямую использоваться для построения более высокоуровневых слоев. На основе ODS может сразу строится CDM.

Основные принципы:

• Данные приведены к единому формату (например, вместо «yes/no», «Y/N» и «true/false» оставляем одно значение).
• Минимальная нормализация.
• Структурированные таблицы с историей изменений.
• Часто обновляются и могут поддерживать near real-time обработку.

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

В ODS существуют два основных подхода к управлению данными:

1. Текущие данные: ODS может хранить исключительно актуальные данные без учета их истории. В таком случае ODS выступает в роли промежуточного этапа в цепочке ETL, где происходит нормализация и очистка данных, или как источник сведений для CDM.
2. Интегрированные данные: В другом подходе данные в ODS полностью интегрированы и могут быть связаны друг с другом, иногда даже с соблюдением третьей нормальной формы (3НФ), при этом сохраняется полная история изменений данных.

На этом слое решаются следующие задачи:

• Интеграция: Объединяет данные из разных источников в реляционную модель.
• Очистка: Удаляет или обновляет неверные данные.
• Актуальность: Предоставляет текущие операционные данные для оперативных отчетов.

DDS (Detail Data Store) — Слой детализированных данных

Здесь начинается магия: данные из разных источников объединяются, очищаются и приводятся к единому виду. Этот слой чаще всего строится по одной из методологий: Kimball, Data Vault, Anchor Modelling.

Detail Data Store (DDS) является ядром DWH и содержит полную историю данных. Этот слой может быть представлен в разной степени нормализации и служит для проведения исторического анализа и выявления тенденций.

• Историчность: Хранит полную историю изменений данных.
• Анализ: Позволяет проводить исторический анализ и выявлять тенденции.

Варианты реализации:

• Kimball (многомерное моделирование): строим измерения (dimensions) и факты (facts) для отчетности.
• Data Vault: храним данные в гибкой структуре «хабов», «линков» и «сателлитов».
• Anchor Modelling: динамическая модель, заточенная на быстрое изменение структуры.

Этот слой — ключевое долгосрочное хранилище детальных исторических данных.

CDM (Common Data Marts) — Слой витрин данных

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

Пользователи могут напрямую забирать данные из Common Data Marts (CDM), однако это может быть не самым удобным способом.

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

• Информативность: Обеспечивает доступ к детальным и агрегированным данным для анализа.
• Детализация: Предоставляет информацию с высокой степенью детализации.

Особенности:

• Создаются витрины данных для конкретных бизнес-процессов.
• Данные хранятся в виде денормализованных таблиц (звезда, снежинка).
• Производится расчет показателей и метрик.

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

REP (Reporting) — Слой отчетности и финального потребления

Финальный уровень — представление данных в удобном виде для BI-систем, ML-моделей или других сервисов.

Reporting Layer (REP) — это конечный продукт, где данные подготовлены специально для пользовательских отчетов. Это полностью готовые ДАННЫЕ, представленные в удобном для визуализации и анализа виде. Этот слой не всегда присутствует в архитектуре DWH, но когда он есть, он обеспечивает быстрый и наглядный доступ к информации для конечных пользователей.

• Отчеты: Генерирует данные для конкретных отчетов и аналитических запросов.
• Визуализация: Предоставляет данные в формате, удобном для визуализации в BI-инструментах.

Ключевые задачи:

• Оптимизация запросов: предрасчитанные агрегации, материализованные представления.
• Доступ через API или SQL.
• Мониторинг производительности и управления нагрузкой.

Data Vault 2.0

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

Вот ключевые аспекты Data Vault 2.0:

1 — Масштабируемая интеграция данных

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

2 — Архитектура «звезда и спицы» (Hub-and-Spoke)

Архитектура Data Vault 2.0 основана на модели «звезда и спицы».

Основные компоненты включают:

• Hub (узел): представляет основную бизнес-сущность или концепцию (например, Клиент, Продукт, Счет). Hub хранит уникальный бизнес-ключ для этой сущности (например, идентификатор клиента), а также суррогатный идентификатор (часто хэш или сгенерированный последовательностью ключ) и метаданные, такие как временная метка загрузки и источник. Изолируя бизнес-ключи в Hubs, Data Vault гарантирует, что каждая сущность будет захвачена один раз , избегая дублирования и поддерживая согласованность на предприятии. Новые Hubs добавляются всякий раз, когда требуется отслеживание нового типа бизнес-объекта, не нарушая существующие структуры.
• Link (связь): определяет связь или отношение между двумя или более концентраторами. Ссылки моделируют отношения «многие ко многим» как отдельные таблицы, сохраняя суррогатные ключи связанных концентраторов вместе с их собственным уникальным ключом и метаданными. Поскольку отношения хранятся как данные (а не жестко запрограммированы в одной таблице), они становятся проверяемыми и легко развиваемыми . Например, ссылка на заказ может соединять концентратор клиентов и концентратор продукта, представляя событие покупки. Ссылки также могут иметь свои собственные спутники, если нам нужно описать само отношение (например, статус заказа или способ доставки). В большинстве случаев ссылки рассматриваются как двунаправленные, то есть вы можете перемещаться по отношениям из любого подключенного концентратора.
• Satellite (спутник): Содержит описательные атрибуты и историю для Hub или Link. Satellites хранят контекст — когда, что, кто из изменений — например, имя клиента, адрес или детали заказа, каждый с эффективными датами/временными метками. Несколько Satellites могут быть присоединены к одному Hub или Link для разделения данных по исходной системе или предметной области (например, Customer Hub может иметь один Satellite для контактной информации, другой для демографических данных). Каждая строка Satellite имеет временную метку и опционально помечена как текущая или просроченная, что позволяет полностью отслеживать историю того, как атрибуты сущности изменяются с течением времени. Важное правило проектирования: Satellites подключаются только к своему родительскому Hub или Link — никогда напрямую к другим Satellites. Это обеспечивает четкое разделение между точками необработанных данных и их контекстом.

Примечание: в Raw Data Vault присутствуют только Hubs, Links и Satellites (загружаемые напрямую из исходных данных без бизнес-преобразований). Business Vault — это дополнительный уровень расширения, где бизнес-правила или вычисления применяются поверх raw vault (например, создание таблиц на определенный момент времени, производных метрик или агрегаций). Business Vault заполняет пробелы, добавляя мягкие правила и улучшения производительности без изменения raw данных, гарантируя, что «единая версия фактов» в Raw Vault остается нетронутой. Этот многоуровневый подход позволяет Data Vault служить средним уровнем интеграции: Raw Vault консолидирует и сохраняет все исходные данные, а Business Vault (вместе с нижестоящими витринами данных) предоставляет курируемые выходные данные (например, схемы звезд, широкие таблицы, хранилища функций) для потребления конечным пользователем.

---

3 — Гибкость и адаптивность

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

4 — Отслеживание исторических данных

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

5 — Автоматизация и метаданные

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

Лучшие практики Data Vault 2.0

Data Vault 2.0 также формализовал несколько лучших практик, которые теперь широко используются в проектах Data Vault:

• Хэш-ключи для суррогатных идентификаторов: вместо использования последовательных целых чисел из одного источника современные хранилища часто используют сгенерированные хэш-ключи (например, хэши MD5/SHA бизнес-ключа) для концентраторов и ссылок. Хэш-ключи гарантируют глобально уникальные идентификаторы, упрощают дедупликацию бизнес-ключей и обеспечивают параллельную загрузку (нет центральной последовательности, с которой нужно бороться). Это имеет решающее значение для распределенных и облачных конвейеров, обрабатывающих большие объемы данных. (Например, ключ клиентского концентратора может быть предназначен HASH_MD5(CustomerID) для последовательной идентификации одного и того же клиента во всех системах.)
• Agile, итеративная разработка: методология DV2.0 охватывает agile-принципы — стройте хранилище в инкрементальных спринтах , добавляя новые концентраторы/ссылки/сателлиты по мере появления новых источников или требований. Поскольку концентраторы и ссылки неизменяемы после вставки (новая информация добавляется через сателлиты), изменения в исходных схемах, как правило, не нарушают схему хранилища. Это минимизирует нисходящую перестройку, позволяя модели быстро развиваться в соответствии с потребностями бизнеса .
• Проектирование и автоматизация на основе метаданных: основным принципом Data Vault являются его повторяющиеся шаблоны, которые поддаются автоматизации. Команды все чаще используют инструменты и фреймворки автоматизации для создания структур Data Vault и загрузки кода из определений метаданных. Например, спецификации сопоставления могут управлять автоматизированным созданием таблиц концентраторов и логики ETL. Это снижает количество человеческих ошибок и ускоряет разработку. (Современные инструменты, такие как WhereScape, VaultSpeed, dbt с AutomateDV и другие, предоставляют шаблоны или макросы для автоматизации создания и загрузки Hub/Link/Satellite.) Подход на основе метаданных обеспечивает согласованность во всем хранилище и позволяет быстро адаптироваться к изменениям источника.
• Point-in-Time (PIT) и Bridge Tables: Хотя Data Vault 2.0 не является частью ядра Raw Vault , он допускает использование вспомогательных конструкций (часто в Business Vault ) для повышения производительности запросов для конечных пользователей. Таблицы PIT записывают предварительно объединенные снимки состояний концентратора/ссылки в определенные моменты времени (что упрощает получение полной размерной картины без сложных объединений), а таблицы Bridge сглаживают связи «многие ко многим» для более легкого использования. Эти дополнения, наряду с агрегациями или таблицами бизнес-правил, ускоряют извлечение информации из Data Vault, не нарушая целостность Raw Vault.

Архитектура Data Vault 2.0

Архитектура Data Vault 2.0 решает задачи расширяемости и масштабируемости посредством модификации типичной трехслойной архитектуры хранилища данных.

Основная цель корпоративного хранилища данных (EDW) — это поставка и представление информации, то есть агрегированных и консолидированных данных, помещенных в определенный контекст. Чтобы подчеркнуть эту основную цель EDW, используем термин информационная витрина (information mart) вместо витрины данных (data mart), который обычно используется в сообществе BI.

Другие модификации стандартной архитектуры включают:

• Промежуточный слой (staging area), который не хранит историческую информацию и не изменяет данные, за исключением приведения их к ожидаемым типам данных.
• Слой хранилища данных (data warehouse layer), смоделированный в соответствии с техникой моделирования Data Vault.
• Один или несколько слоев информационных витрин, которые зависят от слоя хранилища данных.
• Необязательное хранилище метрик (Metrics Vault), предназначенное для захвата и записи информации о выполнении процессов.
• Необязательное бизнес-хранилище (Business Vault), которое используется для хранения данных, к которым применены бизнес-правила. Во многих случаях бизнес-правила изменяют или трансформируют данные, чтобы сделать их полезной информацией. Это еще один тип информационной витрины.
• Необязательное операционное хранилище (Operational Vault), которое хранит данные, поступающие в хранилище данных из операционных систем.
• Возможности управляемого самообслуживания в BI (managed self-service BI), позволяющие бизнес-пользователям выполнять собственный анализ данных без вовлечения IT, включая возможность обратной записи информации в слой корпоративного хранилища данных.

Все необязательные слои хранилища — Metrics Vault, Business Vault и Operational Vault — являются частью Data Vault и интегрированы в слой хранилища данных. Референсная архитектура в стандарте Data Vault 2.0.

Архитектура Data Vault 2.0 основана на трех слоях:

1. Промежуточный слой (staging area): собирает исходные данные из систем-источников.
2. Слой корпоративного хранилища данных (enterprise data warehouse layer): смоделирован в формате Data Vault 2.0.
3. Слой предоставления информации (information delivery layer): информационные витрины в виде звездных схем или других структур.

Еще один пример:

Архитектура поддерживает как пакетную загрузку данных из источников, так и загрузку в реальном времени через шину корпоративных сервисов (ESB) или любую другую сервисно-ориентированную архитектуру (SOA). Кроме того, в эту архитектуру можно интегрировать неструктурированные базы данных NoSQL. Благодаря платформенной независимости Data Vault 2.0, NoSQL можно использовать на любом уровне хранилища данных, включая промежуточный слой, слой корпоративного хранилища данных и слой предоставления информации.

Таким образом:

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

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

В Data Vault различают:

• жесткие бизнес-правила (hard rules);
• и мягкие бизнес-правила (soft rules).

Архитектура Hub-and-Spoke: Архитектура Data Vault 2.0 основана на модели Hub-and-Spoke. Центральными компонентами являются Hubs, Links и Satellites.

Data Vault 2.0 позволяет:

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

Основные компоненты Data Vault 2.0

Хабы (Hubs)

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

Хабы содержат уникальные бизнес-ключи и служат точкой отсчета для связи с остальными данными. Они отвечают на вопрос: «Какие сущности присутствуют в системе?»

Каждый хаб состоит из:

• Уникального бизнес-ключа (набор ключей).
• Технического идентификатора (например, Surrogate Key/Суррогатный ключ, рекомендуется хеш бизнес-ключей).
• Метаданных, например, временной метки загрузки (load timestamp) и источника данных (record source).

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

Линки (Links)

Линки описывают связи между хабами. Они служат для отображения отношений, таких как «Кто продал товар кому» или «Как связаны сущности».

Каждый линк содержит:

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

Спутники (Satellites)

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

Спутники включают:

• Атрибуты бизнес-данных.
• Временные метки (начало и конец действия записи).
• Источник данных.

Пример как это выглядит в формате таблиц:

Еще 1 пример с продажами по методологии Data Vault:

Ключевые Термины

• Business Key (BK): Уникальный идентификатор бизнес-сущности, используемый для интеграции данных из разных источников.
• Hub Key (HK): Суррогатный ключ, используемый в хабе для внутренней идентификации сущности.
• Load Date (LD): Время загрузки или обновления записи, что важно для трассировки изменений.
• Record Source (RS): Информация о источнике данных, позволяет отслеживать, откуда были получены данные.
• Hash Key: Используется для быстрого поиска и соединения данных, часто создается на основе бизнес-ключа.
• PIT (Point-In-Time) Tables: Таблицы, которые позволяют делать запросы данных «на определенный момент времени» для построения отчетности.
• Bridge Tables: Используются для моделирования сложных связей между сущностями, часто в контексте иерархий или многомерных отношений.

---

• Суррогатный ключ (surrogate key) — это искусственно созданный идентификатор, который не имеет бизнес-смысла, но уникально идентифицирует запись в базе данных.
• Бизнес-ключ (business key) — это атрибут или комбинация атрибутов, которые имеют реальное значение в бизнес-контексте и уникально идентифицируют сущность в рамках системы.

---

• Суррогатный ключ — это сгенерированное системой (может быть GUID, последовательностью, уникальным идентификатором и т. д.) значение без бизнес-смысла, которое используется для уникальной идентификации записи в таблице. Сам ключ может состоять из одного или нескольких столбцов (т. е. составной ключ).
• Естественный ключ (Natural Key) — это столбец или набор столбцов, которые уже существуют в таблице (например, они являются атрибутами сущности в модели данных) и однозначно идентифицируют запись в таблице. Поскольку эти столбцы являются атрибутами сущности, они, очевидно, имеют бизнес-значение.

YouTube подборка

Методология моделирования данных для хранилища Data Vault

Марк Порошин — Data Vault на Greenplum c помощью DBT

Перевод книги «Building a Scalable Data Warehouse with Data Vault 2.0»

• Перевод 1 Главы — Введение в хранилища данных
• Перевод 2 Главы — Масштабируемая архитектура хранилища данных
• Перевод 3 Главы — Методология Data Vault 2.0
• Перевод 4 Главы — Моделирование Data Vault 2.0 — Что такое Hub / Link / Satellite?
• Перевод 5 Главы – Intermediate Моделирование Data Vault
• Перевод 6 Главы — Продвинутое моделирование Data Vault 2.0 — Advanced Data Vault Modeling

Anchor Modeling

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

Техника моделирования включает четыре элемента моделирования: anchor (якорь), attribute (аттрибут), tie (связь) и knot (узел), каждый из которых охватывает различные аспекты моделируемой области. Якоря соответствуют сущностям и событиям, атрибуты моделируют свойства якорей, связи — отношения между якорями, а узлы — общие свойства, такие как состояния.

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

Основные компоненты Anchor Modeling

Пример модели (из википедии):

Anchor (якорь)

• Представляет собой уникальную сущность или объект в модели (например, пользователя, продукт, клиент). Якорь содержит только суррогатный ключ (например, ID).
• Каждая таблица Anchor (Якорь) имеет уникальный идентификатор — суррогатный ключ (например, ID).

Attribute (атрибут)

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

• Характеристика Anchors (например, имя клиента, цена продукта, количество товара в продаже).
• Атрибуты могут быть историческими, то есть сохранять версию значений для временной осведомленности.
  • Historized Attribute: Атрибут, который отслеживает изменения во времени, сохраняя все исторические значения.
  • Non-Historized Attribute: Атрибут, который не изменяется со временем или его изменения не отслеживаются.

Tie (связь)

Моделирует отношения между якорями, например, связь «пользователь купил продукт». Связи также могут быть историзированы, показывая, когда отношения были установлены или изменены.

• Ассоциативная таблица, описывающая отношения между Anchors (например, продажа связана с клиентом и продуктом).
• Содержит идентификаторы связанных Anchors и временные метки.
• Tie может быть историческим или статическим:
  • Historized Tie: это связь, которая хранит историю изменений в отношениях между сущностями. Каждый факт, представляющий связь, сохраняется с указанием временного контекста (например, с датами начала и окончания действия связи). Это позволяет анализировать, как и когда отношения между сущностями изменялись.
  • Non-Historized Tie: это связь, которая не хранит историю изменений. Она представляет текущее состояние отношений между сущностями, и при изменении данных предыдущая информация теряется.

Пример Historized:

Выбор между Historized Tie и Non-Historized Tie зависит от потребностей бизнеса и требований к анализу данных.

Knots (узлы)

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

• Хранилище справочных данных, неизменных по своей природе (например, категории продуктов или типы платежей).
• Узлы связаны с Anchors или Ties для нормализации справочной информации.

Posit (позиция)

• Данные, которые фиксируют состояние атрибута, привязываясь ко времени.

Ключи в модели Anchor

Surrogate key (Anchor)

Foreign keys (Tie)

Business keys и Descriptors (Attribute)

Преимущества модели Anchor

• Гибкость: Добавление новых атрибутов, связей и узлов не требует изменений в существующих таблицах.
• Историчность: Все изменения данных фиксируются с помощью временных меток ValidFrom и ValidTo.
• Нормализация: Данные хранятся в атомарном виде, что уменьшает избыточность.
• Масштабируемость: Таблицы компактные, легко масштабируются.

Пример архитектуры хранилища данных для продаж в парадигме Anchor Modeling

Сущности (Anchors):

• Клиент (Customer)
• Продукт (Product)
• Продажа (Sale)

Атрибуты (Attributes):

• Клиент:
  • Имя (Name),
  • Адрес (Address),
  • Телефон (Phone)
• Продукт:
  • Наименование (ProductName),
  • Цена (Price),
  • Категория (Category)
• Продажа:
  • Дата продажи (SaleDate),
  • Количество (Quantity),
  • Сумма (Amount)

Связи (Ties):

• Продажа связана с Клиентом и Продуктом.

Узлы (Knots):

• Типы оплаты (PaymentType): Наличные, Кредитная карта и т.д.
• Категории продуктов (ProductCategory): Еда, Техника, Одежда и т.д.

Инструмент для построения Анкор модели (Anchor Modeler)

• https://www.anchormodeling.com/modeler/latest/
• https://github.com/Roenbaeck/anchor