Введение в Data Vault как третий путь

Inmon и Kimball — два классических подхода, и оба появились в 1990-х. Но у каждого есть ограничение. Нормализованное ядро Inmon тяжело менять, когда добавляется новый источник: схема ядра завязана на интеграцию всех систем сразу. Размерная модель Kimball отлично подходит для потребления, но плохо приспособлена к роли строго auditable-хранилища сырых данных из множества источников.

Data Vault — третий подход, который появился во многом как ответ на эти ограничения. Его создал Dan Linstedt; первая версия (DV1.0) сформирована в начале 2000-х, а Data Vault 2.0 добавил hash-ключи, паттерны параллельной загрузки и интеграцию с современным тулингом. Этот урок — обзорное введение; подробно Data Vault разбирается в отдельном модуле курса.

Зачем нужен Data Vault

Data Vault решает три задачи, которые плохо даются классическим подходам.

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

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

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

Data Vault обычно располагается между source-системами и витринами потребления — как интегрированный, auditable backbone. Финальные витрины для BI (star schema) строятся уже поверх него.

Стоит понять, почему Data Vault так хорош именно в приёме данных из многих источников. Главная боль интеграции — источники меняются: один добавляет новое поле, другой меняет формат, третий вообще появляется впервые. В нормализованном ядре Inmon такое изменение часто требует переделки схемы ядра, потому что ядро спроектировано как единое целое. Data Vault устроен так, что новый источник или новый атрибут — это всегда добавление таблицы (нового satellite, нового hub, нового link), а не изменение существующих. Структура растёт «вширь» новыми таблицами, и уже работающие загрузки не ломаются. Эта устойчивость к изменениям источников — прямое следствие дробления данных на hub, link и satellite, и она же делает Data Vault удобным фундаментом для долгоживущего хранилища, в которое источники добавляются годами.

Три строительных блока

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

Hub — хранит business keys. Hub представляет одну бизнес-сущность через её business key — устойчивый идентификатор из реального мира (номер клиента, артикул товара). В hub только: hash key (PK), сам business key, дата загрузки, источник записи. Никаких описательных атрибутов. Hub отвечает на вопрос «какие сущости этого типа вообще существуют».

Link — хранит связи. Link представляет связь или транзакцию между бизнес-ключами (всегда трактуется как many-to-many). В link только: собственный hash key, hash-ключи связываемых hubs, дата загрузки, источник. Тоже никаких описательных атрибутов. Link отвечает на вопрос «какие сущности связаны между собой».

Satellite — хранит атрибуты и историю. Satellite содержит описательные атрибуты hub или link И всю их историю во времени. Каждое изменение атрибутов — новая строка satellite. Satellite отвечает на вопрос «какими были атрибуты сущности и как они менялись».

Сравним с обычным подходом. В Kimball-dimension dim_customer в одной таблице слиты: идентификатор клиента, описательные атрибуты, история (через SCD). Data Vault разносит это по трём таблицам: business key клиента — в hub, его атрибуты и история — в satellite, его связь, скажем, с заказами — в link. Зачем такое дробление? Именно оно даёт гибкость (новый атрибут — новый satellite, ничего не ломается) и параллельную загрузку (hub, link, satellite грузятся независимо).

Стоит разобрать, почему дробление так влияет на гибкость. Когда идентификатор, атрибуты и связи слиты в одну таблицу, любое изменение задевает всю таблицу: добавили атрибут — изменили схему dim_customer, поменяли способ связи — снова трогаем ту же таблицу. Когда же эти три аспекта разнесены, каждый меняется независимо. Появился новый набор атрибутов из нового источника — это новый satellite, прицепленный к существующему hub; сам hub и другие satellites не трогаются. Появилась новая связь между сущностями — это новый link; hubs остаются как были. Дробление превращает «изменение схемы» в «добавление таблицы», а добавление таблицы безопасно: оно ничего не ломает в уже работающих загрузках. Это и есть инженерная причина, по которой Data Vault так устойчив к эволюции источников.

Полезно также понять, почему link всегда трактуется как many-to-many, даже если связь сейчас выглядит как «один к одному». Data Vault сознательно закладывает максимальную общность: сегодня у заказа один клиент, но завтра бизнес-правила могут измениться (совместные заказы, смена владельца), и если связь зафиксирована как link, такое изменение — это просто новые строки в существующем link, без переделки структуры. Жёстко зашитая связь «один к одному» при изменении правил потребовала бы миграции. Link как универсальная many-to-many структура — это ещё одно проявление главного принципа Data Vault: проектировать так, чтобы будущие изменения добавляли данные, а не ломали схему.

Hash-ключи: почему не sequence

В Data Vault 2.0 ключи (PK у hub и link) — это hash от business key: MD5 или SHA-256. Не монотонные integer-последовательности, как привычные surrogate keys.

Зачем хеш? Хеш детерминирован: любой процесс, зная business key, независимо вычислит ровно тот же ключ — без обращения к центральному генератору последовательности. А это и открывает параллельную загрузку: hub, его satellites и links можно грузить одновременно разными процессами, каждый сам считает нужные хеши, координация между ними не нужна. С sequence-ключами так нельзя — пришлось бы синхронизироваться вокруг общего счётчика. Бонус хеша — фиксированная ширина ключа (16 байт у MD5, 32 у SHA-256). Цена — риск коллизий и стоимость вычисления хеша. Подробнее — в отдельном модуле про Data Vault.

Data Vault в ряду трёх подходов

Поставим Data Vault рядом с Inmon и Kimball, чтобы увидеть его нишу.

Важно понимать: Data Vault — не замена Inmon или Kimball, а дополнение. Он не предназначен для прямого потребления аналитиками — запросы к hub/link/satellite требуют множества JOIN. Его роль — быть auditable, гибким, параллельно загружаемым backbone. А витрины для BI поверх него почти всегда строят размерными — то есть по Kimball.

Именно поэтому Data Vault так хорошо вписывается в гибридные архитектуры из прошлого урока: он играет роль того самого интегрированного слоя (silver в medallion), а Kimball-витрины — слоя потребления (gold). Современная мейнстрим-связка — Data Vault как backbone плюс Kimball как consumption.

Попробуй сам

Возьмите бизнес-сущность «клиент» и её связь с «заказами».

1. Распределите по трём типам таблиц Data Vault: где будет храниться номер клиента (business key)? где — его имя, адрес и их история? где — факт связи клиента с заказом?
2. Сравните с тем, как те же данные хранились бы в одной Kimball-dimension dim_customer со SCD2. Что Data Vault разносит по трём таблицам и зачем.
3. Объясните своими словами: почему детерминированность hash-ключа делает возможной параллельную загрузку, а sequence-ключ — нет.
4. В гибридной архитектуре «Data Vault + Kimball» — какой слой за что отвечает? Почему витрины для аналитиков всё равно делают размерными, а не запрашивают Data Vault напрямую.