В предыдущей статье мы договорились, что трансформировать данные нужно прямо внутри хранилища под управлением dbt. Но когда мы проектируем слой Core нашего DWH, велик соблазн складывать данные из Staging-слоя в привычные широкие денормализованные таблицы.

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

Чтобы хранилище не рассыпалось от каждого изменения на стороне источника, в слое Core использую методологию Data Vault. Её суть — разделение данных на три независимых атомарных элемента:

1. Hub (Хабы) — это фундамент и бизнес-ключи. Они хранят только уникальные идентификаторы бизнес-сущностей (customer_id, order_id, product_id), время их первого появления и источник. Они никогда не меняются. В dbt это реализуется через строгий инкремент — мы дописываем только новые ключи, которых еще нет в базе.

2. Link (Линки) — это связи. Они фиксируют транзакции и пересечения между хабами (например, связь «Заказ — Клиент»). Если завтра бизнес-логика изменится, и один заказ смогут оформлять несколько клиентов (совместные корзины), структура таблиц хабов не изменится — поменяется только логика линка.

3. Satellite (Сателлиты) — это контекст и история. Только здесь живут описательные атрибуты (имя клиента, адрес, даты). Чтобы не перегружать базу постоянным обновлением строк (UPDATE), изменения отслеживаются через hashdiff. Если хэш-сумма новых данных по клиенту совпала с уже существующей — запись игнорируется. Если изменилась — dbt инкрементально добавляет новую версию строки.

Что это дает инженеру на практике?

• Изоляция изменений: Источник может менять структуру полей, но скелет вашего хранилища (Хабы и Линки) остается монолитным.

• Инкрементальная скорость: Никаких тяжелых FULL REFRESH. Каждая модель проверяет только дельту новых валидных данных.

• Готовность к историчности: Храня версии в сателлитах, мы можем легко развернуть SCD2-логику.

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

А какой подход для Core-слоя выбираете вы на своих проектах: классический Data Vault, третью нормальную форму (3NF) или сразу строите витрины Кимбалла?

Исходный код dbt-моделей Хабов, Линков и Сателлитов: https://github.com/lelik-bolek/eltdwh-airflow-dbt

#DataEngineering #DataVault #dbt #DWH #Architecture #SQL #eltdwh_pipeline