Зачем нужен Data Vault
Вы уже знаете два классических подхода к проектированию хранилища: Inmon с нормализованным ядром и Kimball с размерными витринами. Оба родились в эпоху, когда источников данных было немного, они менялись редко, а загрузка шла раз в сутки большими батчами. Сегодня всё иначе: у компании могут быть десятки источников — CRM, биллинг, мобильное приложение, рекламные кабинеты, выгрузки партнёров. Каждый из них меняет свою структуру независимо. Регуляторы требуют доказать, откуда взялась каждая цифра в отчёте. На этом стыке требований и появился третий подход — Data Vault.
Data Vault придумал Dan Linstedt; первая версия формализована в начале 2000-х, а Data Vault 2.0 в 2010-х добавил hash keys, паттерны параллельной загрузки и интеграцию с современным тулингом. Это не замена Kimball и не замена Inmon — это слой между источниками и витринами, оптимизированный под три вещи: полную auditability, агрессивный приём данных и устойчивость к изменениям.
Проблема, которую решает Data Vault
Представьте классическое нормализованное хранилище уровня 3NF. К нему подключены восемь источников. Завтра один из них добавляет новое поле, второй переименовывает таблицу, третий начинает присылать дубли. В нормализованной схеме каждое такое изменение задевает существующие таблицы: нужно менять DDL, переписывать ETL, тестировать, что ничего не сломалось у соседних источников. Релиз растягивается на недели. А когда приходит аудитор и спрашивает «почему в отчёте за март выручка 4.1 млн, покажите путь каждой строки» — выясняется, что Type 1-перезапись давно затёрла исходные значения.
Data Vault решает обе боли архитектурно. Модель разбита на мелкие, слабо связанные структуры трёх типов: Hub, Link и Satellite (подробно — в следующем уроке). Новый источник или новое поле — это почти всегда добавление новой структуры, а не изменение существующей. А исходные данные не перезаписываются никогда: каждая загрузка только добавляет строки.
Ключевая мысль: Data Vault — это не то, что видит аналитик. Аналитик работает с витринами (star schema, OBT), построенными поверх Vault. Сам Vault — это backbone: место, где данные хранятся честно, полно и навсегда.
Auditability: данные только добавляются
Главный принцип Data Vault — insert-only. Ни одна строка никогда не обновляется и не удаляется. Если атрибут клиента изменился — в Satellite добавляется новая строка с новым load timestamp. Если запись пропала из источника — мы просто перестаём её получать, но всё, что было загружено раньше, остаётся на месте.
Это даёт свойство, которое называют auditability: для любой строки в любом отчёте можно проследить полный путь — из какого источника она пришла, когда была загружена, какие значения имела на каждый момент времени. Сравните с Type 1-перезаписью из урока про SCD: там старое значение исчезает физически, и восстановить его нельзя.
Посмотрим на типовой набор метаданных, который Data Vault добавляет к каждой строке:
-- Каждая таблица Data Vault несёт служебные столбцы
CREATE TABLE sat_customer_details (
customer_hk BYTEA, -- hash key хаба-родителя
load_date TIMESTAMP, -- когда строка загружена (часть PK)
load_end_date TIMESTAMP, -- когда версия перестала быть актуальной
record_source VARCHAR(50), -- ОТКУДА строка: 'crm.customers'
hashdiff BYTEA, -- хеш атрибутов для change detection
-- описательные атрибуты:
full_name VARCHAR(200),
email VARCHAR(200),
city VARCHAR(100),
PRIMARY KEY (customer_hk, load_date)
);Три служебных столбца — load_date, load_end_date, record_source — присутствуют почти в каждой таблице Vault. record_source отвечает на вопрос «откуда»: если один и тот же клиент пришёл из CRM и из биллинга, мы видим обе строки и знаем, какой источник что прислал. load_date отвечает на вопрос «когда». Вместе они делают хранилище самодокументируемым: история не реконструируется по логам ETL, она лежит прямо в данных.
Insert-only — это не «удобная привычка», а проектное ограничение. Оно убирает целый класс ошибок: нельзя случайно затереть данные неверным UPDATE, нельзя потерять историю из-за бага в ETL. Цена — хранилище растёт быстрее, но на колоночных warehouse с дешёвым хранением и хорошим сжатием это приемлемо.
Агрессивный приём: грузим всё и сразу
Второе свойство Data Vault — способность принимать данные агрессивно. «Агрессивно» здесь значит: грузим из источника всё, что он даёт, не дожидаясь, пока бизнес договорится о правилах очистки и согласования.
В классическом хранилище приём данных — это узкое место. Прежде чем загрузить таблицу, нужно решить: как чистить, как дедуплицировать, как мэтчить с другими источниками, какие бизнес-правила применить. Пока эти вопросы открыты — данные не грузятся. Data Vault разрывает эту зависимость: он делит работу на два слоя.
Raw Vault принимает данные source-driven: структура повторяет источник, трансформаций минимум, история полная. Загрузка нового источника не блокируется ничем — добавили хабы, линки, сателлиты и грузим. Business Vault строится отдельно, поверх Raw Vault, и уже там применяются бизнес-правила: очистка, согласование, вычисляемые атрибуты. Подробно эти два слоя разберём в пятом уроке модуля.
Такое разделение даёт практическую гибкость: данные начинают накапливаться с первого дня, даже если бизнес ещё спорит о правилах. Когда правила согласуют — их применяют в Business Vault, и при этом вся история уже в Raw Vault, её не нужно собирать заново.
Ещё одна причина, по которой Data Vault принимает данные легко, — слабая связанность структур. В нормализованной схеме таблицы связаны жёстко через foreign keys, и загрузка должна идти в строгом порядке: сначала родители, потом дети. В Data Vault hubs, links и satellites загружаются независимо и параллельно. Как именно это достигается через hash keys — тема третьего урока; пока запомните, что независимая загрузка — прямое следствие устройства модели.
Когда Data Vault уместен, а когда избыточен
Data Vault — мощный инструмент, но не бесплатный. Он добавляет слой, увеличивает число таблиц в разы и требует дисциплины. Стоит честно понимать, когда он оправдан.
| Ситуация | Data Vault уместен? |
|---|---|
| Десятки источников, меняются независимо | Да — слабая связанность окупается |
| Жёсткие требования регуляторов к auditability | Да — insert-only даёт это из коробки |
| Команда быстро растёт, источники добавляются часто | Да — новый источник не ломает существующее |
| Один-два стабильных источника, маленькая команда | Нет — Kimball напрямую проще |
| Нужны только витрины «здесь и сейчас», история не важна | Нет — overhead не окупится |
Типичная зрелая архитектура 2025-2026 — гибрид: Data Vault как auditable backbone (приём и хранение), Kimball star schema как consumption-слой поверх него (то, что видит аналитик). Это не «или Data Vault, или Kimball» — это синтез, где каждый подход делает то, в чём силён.
Если вы джун и попали в проект с Data Vault — не пугайтесь количества таблиц. Их много именно потому, что каждая делает одну простую вещь. Разберитесь с тремя типами структур (Hub, Link, Satellite) — и любая, даже огромная, Data Vault-схема станет читаемой.
Попробуй сам
Возьмите любую знакомую предметную область — например, интернет-магазин с источниками: база заказов (PostgreSQL), платёжный шлюз (API), система складского учёта (выгрузка CSV).
- Для каждого источника выпишите 2-3 «бизнес-сущности», которые он содержит (клиент, заказ, товар, платёж, остаток на складе).
- Отметьте, какие сущности встречаются в нескольких источниках. Например, «заказ» может фигурировать и в базе заказов, и в платёжном шлюзе.
- Подумайте: если завтра платёжный шлюз добавит новое поле
currency, какие таблицы пришлось бы менять в нормализованной 3NF-схеме? А что изменилось бы в Data Vault, где для атрибутов есть отдельные Satellite-таблицы? - Запишите для каждого источника, какое значение попало бы в столбец
record_source.
Это упражнение — подготовка к следующему уроку, где мы разберём, как именно Hub, Link и Satellite раскладывают эти сущности по таблицам.