В каком случае выбрать Data Vault вместо третьей нормальной формы для ядра хранилища
Что проверяют
Понимаете ли вы, какую проблему решает Data Vault и сколько он стоит, или повторяете «он гибче». Следом обычно спрашивают, как поверх Data Vault строить витрины и чем это отличается от подходов Инмона и Кимбалла.
Как отвечать
Ядро в 3NF по Инмону нормализовано, интегрировано и строго, но изменение источника часто требует переделки таблиц и загрузок. Data Vault (методология Дэна Линстедта, сейчас обычно версия 2.0) делит данные на три типа таблиц:
- хабы: бизнес-ключи сущностей, например номер клиента, и ничего больше;
- линки: связи между хабами, всегда в форме «многие ко многим»;
- сателлиты: описательные атрибуты с историей, каждая версия строки с датой загрузки и источником.
Новые источники и атрибуты добавляются новыми сателлитами и линками, существующие таблицы не меняются. Загрузка устроена как insert-only, а хэш-ключи позволяют грузить хабы, линки и сателлиты параллельно.
Когда выбирать Data Vault:
- много источников: разные ключи для одних и тех же сущностей, частые изменения структуры;
- аудит: нужно показать, какое значение пришло из какой системы и когда;
- масштаб команды: несколько человек параллельно подключают разные источники.
Когда хватит 3NF или сразу звезды: один-два стабильных источника, небольшая команда, быстрый результат важнее аудита.
Цена Data Vault: таблиц в разы больше, запросы к ядру требуют множества join. Поэтому аналитики работают не с ядром, а с витринами поверх него, обычно это звезда Кимбалла. Генерацию моделей часто автоматизируют через dbt и пакеты вроде AutomateDV.
Где спотыкаются
Выбирают Data Vault потому что «модно», для хранилища с тремя источниками. Сложность модели и затраты на загрузку тогда не окупаются.
Думают, что историчность есть только в Data Vault. В 3NF и в звезде её дают SCD2 и темпоральные таблицы.
Дают аналитикам доступ прямо к хабам и сателлитам. Без слоя витрин запросы получаются медленными и непонятными.