Работали ли вы с моделированием и использованием Data Vault и dbt в текущих проектах

Что проверяют

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

Как отвечать

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

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

Где спотыкаются

Называют dbt инструментом полного цикла загрузки. Он ничего не извлекает и не переносит, он выполняет SQL там, где данные уже лежат. Доставку делает отдельный загрузчик, расписание оркестратор.

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

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