← вся теориятеория к собесу · DWH и моделирование данных

Data Vault

Data Vault: ядро под изменчивые источники

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

Стержень: ядро (ключи и связи) стабильно и без атрибутов, атрибуты живут в insert-only сателлитах, аналитик работает не с vault, а с витринами поверх.

// Формулировки: «что такое хаб/линк/сателлит?», «в чём выигрыш Data Vault?», «когда он избыточен?».

Хабы, линки, сателлиты

Хаб - только бизнес-ключ сущности плюс хеш-ключ и метаданные загрузки, никаких атрибутов: ключ клиента стабилен, даже когда всё вокруг меняется. Линк - связь хабов (заказ-клиент-товар), тоже без атрибутов, по умолчанию many-to-many, что даёт гибкость к смене кардинальности.

Сателлит - атрибуты хаба или линка с историей по load_date. Новые атрибуты источника оформляются новым сателлитом, старое не трогают это insert-only мир.

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

hub / link / satellite: бизнес-ключи / связи / исторические атрибуты
insert-only: данные только добавляются, ничего не перезаписывается

Загрузка и хеш-ключи

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

Хеш-ключи (например, md5 бизнес-ключа) - детерминированные суррогаты: их можно вычислить в любом потоке без предварительного lookup'а в измерение, что и развязывает загрузку.

// Тут же грабли: бизнес-ключи надо привести к единому виду (регистр, пробелы) ДО хеширования, иначе «Ivan» и «ivan» дадут разные хеши и один клиент разъедется на два хаба.

hash key: хеш бизнес-ключа как детерминированный суррогат
business vault: слой с бизнес-правилами поверх raw vault

Цена и когда оправдан

Цена Data Vault - джойны и сложность чтения: собрать сущность целиком значит соединить хаб, его сателлиты и линки. Поэтому аналитик не работает с vault напрямую - поверх него строят витрины-звёзды (raw vault → business vault → marts).

Выбор честен: DV (Data Vault) оправдан, когда источников много, нужен аудит и схемы часто меняются. Для пары стабильных источников он - двойная работа без выигрыша, и правильнее сразу строить звезду Кимбалла.

// Пускать аналитиков в raw vault - значит обречь их на джойн-ад и неверные выводы. Витрины поверх - не опция, а обязательная часть архитектуры DV.

raw vault → marts: vault как ядро, витрины-звёзды поверх для чтения
аудитируемость: insert-only история всех изменений источников

Как отвечать: «Что такое Data Vault и когда он оправдан?»

Data Vault - модель ядра хранилища для ситуаций, где источников много и их схемы часто меняются. Он раскладывает данные на три типа таблиц: хабы хранят только бизнес-ключи сущностей, линки - связи между хабами, сателлиты - атрибуты с историей, причём всё insert-only. Смысл в том, что ядро из ключей и связей стабильно, а любые изменения и новые источники добавляются новыми сателлитами, не перестраивая модель. Это даёт параллельную загрузку через детерминированные хеш-ключи и полную аудитируемость. Цена - много джойнов, поэтому аналитиков в raw vault не пускают, а строят поверх витрины-звёзды. Оправдан он при множестве источников, требованиях аудита и частой смене схем. Если источников пара и они стабильны это лишняя сложность, и я сразу строю Кимбалла.

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

На чём валят

−Атрибуты в хабе или линке - модель теряет главное свойство, стабильность ядра.
−Пускать аналитиков в raw vault - джойн-ад и неверные выводы; витрины обязательны.
−Data Vault ради моды на один стабильный источник - двойная работа без выигрыша.
−Разный регистр/пробелы в бизнес-ключах до хеширования - один клиент разъехался на два хаба.
−Сателлит с атрибутами разной волатильности - версии плодятся из-за одного поля.

Проверьте себя

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

#data_vault_modeling1 / 5
Что моделирует link (линк) в Data Vault?
A)Link хранит бизнес-ключи одной сущности, дублируя тем самым назначение хаба в модели
B)Link хранит все описательные атрибуты связи и их полную историю изменений во времени
C)Связь/отношение между хабами (например, клиент ↔ счёт), храня только их ключи; отношения ведут инсертами
D)Link — это витрина-звезда, собираемая поверх хабов для конечного потребления в BI-отчётах
показать ответ и разбор
+C)Связь/отношение между хабами (например, клиент ↔ счёт), храня только их ключи; отношения ведут инсертами
// разбор: Link представляет связь между двумя и более хабами — например, факт, что клиент владеет счётом, заказ содержит товар. Он хранит только хеш-ключи участвующих хабов (и свой), без описательных атрибутов (те — в сателлите линка). Любое отношение, включая транзакции, моделируется линком, и оно insert-only: изменение связи — это новая строка, старая остаётся ради аудита. Такая гибкость (новые связи добавляются новыми линками) — причина, по которой Data Vault хорошо переживает эволюцию источников.
#data_vault_modeling2 / 5
Когда Data Vault оправдан вместо прямой звезды Кимбалла?
A)Data Vault предпочтительнее звезды, вытесняя подход Кимбалла
B)Data Vault оправдан для маленьких хранилищ с одним стабильным источником данных
C)Data Vault выбирают ради экономии дискового пространства за счёт нормализации
D)DV — под интеграцию/аудит многих источников; Kimball — под BI-потребление
показать ответ и разбор
+D)DV — под интеграцию/аудит многих источников; Kimball — под BI-потребление
// разбор: Data Vault силён как интеграционный raw-слой корпоративного хранилища: много разнородных, часто меняющихся источников, требования аудита и прослеживаемости, параллельная загрузка, устойчивость схемы к изменениям (новый источник — новые сателлиты/линки, старое не трогаем). Но сам по себе он неудобен для аналитики (много джойнов). Поэтому типовая связка: Data Vault внизу для интеграции и истории, а витрины-звёзды Кимбалла сверху — под BI. Для небольшого хранилища с парой стабильных источников DV — избыточная сложность, берут сразу звезду.
#data_vault_modeling3 / 5
Почему Data Vault строят как insert-only (без update/delete строк)?
A)Ради полной аудируемости и прослеживаемости: любое изменение — новая строка с меткой загрузки, ничего не затирается
B)Чтобы экономить дисковое пространство, ведь вставки занимают меньше места, чем обновления строк
C)Потому что базы данных под Data Vault технически не поддерживают операции UPDATE и DELETE
D)Чтобы конечные пользователи не могли случайно изменить или удалить данные в готовых витринах
показать ответ и разбор
+A)Ради полной аудируемости и прослеживаемости: любое изменение — новая строка с меткой загрузки, ничего не затирается
// разбор: Insert-only значит, что данные никогда не обновляются и не удаляются на месте — изменение атрибута или связи добавляется новой строкой с временем загрузки и источником. Это даёт полную историю и аудит (видно, что и когда пришло из какого источника), упрощает параллельную загрузку (нет конфликтов обновления одной строки) и делает загрузку идемпотентной/переигрываемой. Плата — рост объёма и необходимость витрин сверху, чтобы получить «текущее» состояние для аналитики.
#data_vault_modeling4 / 5
Зачем в современном Data Vault используют хеш-ключи вместо последовательных суррогатов?
A)Хеш-ключи нужны для шифрования и защиты бизнес-ключей от несанкционированного доступа
B)Хеш от бизнес-ключа детерминирован — хабы, линки и сателлиты грузятся параллельно и независимо, без ожидания lookup суррогата
C)Хеш-ключи занимают меньше места, чем целочисленные суррогаты, что и есть их главное преимущество
D)Последовательные суррогаты не получится применять в модели Data Vault по её правилам
показать ответ и разбор
+B)Хеш от бизнес-ключа детерминирован — хабы, линки и сателлиты грузятся параллельно и независимо, без ожидания lookup суррогата
// разбор: Последовательный суррогат генерится централизованно, и чтобы поставить внешний ключ в линк/сателлит, надо сперва загрузить хаб и подсмотреть его суррогат — это последовательная зависимость, мешающая распараллеливанию. Хеш-ключ (хеш от бизнес-ключа) вычисляется детерминированно из самих данных, одинаково в любой таблице, поэтому хабы, линки и сателлиты можно грузить одновременно и независимо, не дожидаясь друг друга. Минусы — риск коллизий (редко) и размер ключа; плюс — масштабируемая параллельная загрузка, ради которой это и делают.
#data_vault_modeling5 / 5
Data Vault: что хранит таблица-хаб (hub)?
A)все атрибуты сущности с полной историей изменений
B)связи «многие ко многим» между сущностями
C)бизнес-ключи сущности и метаданные их появления
D)готовые агрегаты для отчётов по сущности
показать ответ и разбор
+C)бизнес-ключи сущности и метаданные их появления
// разбор: Хаб — реестр сущностей: уникальные бизнес-ключи (номер клиента, номер договора) плюс метаданные — когда и из какого источника ключ впервые пришёл. Атрибуты и их история живут в сателлитах, связи между сущностями — в линках. Такое разделение позволяет добавлять источники и атрибуты, не перестраивая ядро модели.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: DWH и моделирование данных