Raw Vault, Business Vault, PIT и bridge

Мы разобрали кирпичи Data Vault (Hub, Link, Satellite) и два хеша (hash key, hashdiff). Теперь поднимемся на уровень архитектуры. В первом уроке мы упомянули, что Data Vault делится на два слоя: Raw Vault и Business Vault. Этот урок объясняет, что именно в каждом и зачем такое разделение. А ещё разберём две вспомогательные структуры — PIT и bridge, — которые решают конкретную боль Data Vault: запросы к нему медленные.

Главная мысль урока: Data Vault — это не один однородный пласт таблиц. Это слои с разной ответственностью. Raw Vault отвечает за честное хранение сырья. Business Vault — за применённые бизнес-правила. PIT и bridge — за то, чтобы поверх всего этого было можно строить витрины с приемлемой скоростью.

Raw Vault: сырьё как есть

Raw Vault — слой, который принимает данные source-driven: структура Hub/Link/Satellite повторяет то, что прислал источник, с минимумом трансформаций. Здесь нет бизнес-правил — никакой очистки, никакого согласования, никаких вычисляемых атрибутов. Задача Raw Vault — сохранить всё, что пришло, честно и навсегда.

Что значит «минимум трансформаций» на практике:

• Вычислить hash keys и hashdiff (без этого Data Vault не работает).
• Добавить служебные метаданные: load_date, record_source.
• Разложить плоскую строку источника по Hub, Link, Satellite.

И всё. Если источник прислал телефон в формате +7 (999) 123-45-67, в Raw Vault он ляжет ровно так — со скобками и пробелами. Если два источника называют один город по-разному (СПб и Санкт-Петербург) — в Raw Vault будут оба варианта как есть. Raw Vault не судит данные, он их фиксирует.

Это и есть фундамент auditability из первого урока. Raw Vault — источник истины: что бы ни случилось дальше, всегда можно вернуться сюда и увидеть, что именно прислал источник и когда.

Business Vault: применённые бизнес-правила

Business Vault строится поверх Raw Vault и содержит то, чего в Raw Vault принципиально нет: результаты применения бизнес-правил. Очищенные значения, согласованные между источниками данные, вычисляемые атрибуты.

Структуры Business Vault — те же Hub, Link, Satellite (плюс PIT и bridge, о них ниже). Отличие не в форме, а в содержании: данные здесь уже обработаны. Примеры того, что появляется в Business Vault:

• Очистка. Телефон +7 (999) 123-45-67 приводится к 79991234567. Города СПб и Санкт-Петербург сводятся к одному каноническому значению.
• Согласование источников. Клиент пришёл из CRM и из биллинга с разными написаниями имени — Business Vault применяет правило, какое значение считать «золотым».
• Вычисляемые атрибуты. «Сегмент клиента» (A/B/C) или «полная стоимость заказа с налогом» — этого нет ни в одном источнике, это результат бизнес-логики. Такие атрибуты складывают в computed satellite.

Почему правила живут отдельно от сырья? Из-за двух свойств. Первое — auditability: правила меняются (бизнес передумал, как считать сегмент), а сырьё в Raw Vault неизменно, и старые расчёты всегда можно воспроизвести заново. Второе — скорость приёма: Raw Vault грузится сразу, не дожидаясь, пока бизнес согласует правила, как мы обсуждали в первом уроке. Business Vault достраивается потом, когда правила готовы.

Проблема: запросы к Data Vault медленные

У Data Vault есть оборотная сторона гибкости — запросы к нему многословны и медленны. Вспомните устройство модели: атрибуты разнесены по нескольким Satellites, сущности — по Hubs, связи — по Links. Чтобы собрать «полную картину клиента с его заказами», нужно соединить десяток таблиц. А Satellites ещё и историчны — на каждый hash key несколько версий, и нужно для каждой даты выбрать актуальную.

Особенно болезненны два паттерна:

1. Temporal join нескольких Satellites одного Hub. У клиента три Satellites: sat_customer_crm, sat_customer_billing, sat_customer_segment. Каждый историчен. Чтобы получить «состояние клиента на 15 марта», нужно в каждом Satellite найти версию, актуальную на эту дату (range scan по load_date и load_end_date), и соединить три результата. Дорого, и так на каждый запрос.
2. Обход цепочки Hub-Link-Hub-Link. «Клиент -> заказ -> позиции заказа -> товар» — это четыре структуры и три перехода через Links, каждый — JOIN.

Data Vault решает это не переделкой модели, а предвычислением. В Business Vault добавляют две специальные структуры: PIT и bridge. Они не источник истины — это кэш, ускоряющий частые паттерны.

PIT-таблица: снимок версий на каждую дату

PIT (point-in-time) таблица предвычисляет temporal join Satellites одного Hub. Идея: для каждого нужного момента времени заранее записать, какая версия каждого Satellite была тогда актуальна.

Строка PIT-таблицы содержит: hash key хаба, дату снимка и — для каждого подключённого Satellite — load_date той его версии, что действовала на эту дату.

CREATE TABLE pit_customer (
    customer_hk         BYTEA      NOT NULL,
    snapshot_date       DATE       NOT NULL,  -- дата снимка
    crm_load_date       TIMESTAMP,            -- версия sat_customer_crm на эту дату
    billing_load_date   TIMESTAMP,            -- версия sat_customer_billing
    segment_load_date   TIMESTAMP,            -- версия sat_customer_segment
    PRIMARY KEY (customer_hk, snapshot_date)
);

-- Пример: клиент 0x8f3a... на разные даты
-- customer_hk | snapshot_date | crm_load_date | billing_load_date | segment_load_date
-- 0x8f3a...   | 2026-03-01    | 2026-01-10    | 2026-02-15        | 2026-01-10
-- 0x8f3a...   | 2026-04-01    | 2026-03-20    | 2026-02-15        | 2026-03-25

Теперь запрос «состояние клиента на 1 апреля» не делает range scan по каждому Satellite. Он берёт строку PIT за нужную дату и соединяет Satellites по точному ключу (hash key, load_date) — это equi-join по первичному ключу, самый быстрый вид соединения. Дорогой поиск «какая версия актуальна» сделан заранее, при построении PIT, а не на каждый пользовательский запрос.

Bridge-таблица: предвычисленная цепочка связей

Bridge-таблица решает второй паттерн — обход цепочек Hub-Link-Hub. Она заранее «уплощает» частую цепочку в один набор готовых ключей.

Если запрос «клиент -> его заказы -> товары в заказах» выполняется постоянно, bridge-таблица предвычисляет результат обхода: одна строка на готовую комбинацию hash keys вдоль всей цепочки.

CREATE TABLE bridge_customer_orders (
    snapshot_date  DATE   NOT NULL,
    customer_hk    BYTEA  NOT NULL,  -- хаб клиента
    order_hk       BYTEA  NOT NULL,  -- хаб заказа (через link_order_customer)
    product_hk     BYTEA  NOT NULL,  -- хаб товара (через link_order_product)
    PRIMARY KEY (snapshot_date, customer_hk, order_hk, product_hk)
);

Вместо трёх JOIN через Links на каждый запрос — один JOIN с готовой bridge-таблицей. Цепочка пройдена заранее.

Важно понимать статус PIT и bridge. Это не источник истины — в них нет данных, которых нет в Raw Vault. Это производные структуры, кэш под конкретные паттерны запросов. Их можно в любой момент удалить и пересобрать из Vault. Если паттерн запросов поменялся — старые PIT/bridge выбрасывают и строят новые. По духу это близко к денормализации из урока про нормализацию: сознательная избыточность ради скорости чтения.

Куда ведёт Data Vault: витрины

Последний шаг. Сам Data Vault — Raw и Business — аналитику не показывают. Поверх него строят витрины потребления: star schema или One Big Table, те самые размерные модели из предыдущих модулей курса. Финальная dimension собирается из Hub плюс его Satellites; финальная fact-таблица — из Link плюс его Satellites. PIT и bridge делают эту сборку быстрой.

Это и есть гибридная архитектура, о которой шла речь в первом уроке: Data Vault как auditable backbone внизу, Kimball star schema как consumption-слой сверху. Вы прошли весь путь — от «зачем Data Vault» до того, как из него рождается витрина.

Попробуй сам

1. Возьмите свою предметную область (интернет-магазин) и разделите придуманные ранее структуры на два слоя. Что лежит в Raw Vault как есть? Какие атрибуты потребуют очистки или вычисления и попадут в Business Vault?
2. Придумайте один computed satellite: вычисляемый атрибут, которого нет ни в одном источнике (например, customer_lifetime_value или order_total_with_tax).
3. У клиента три Satellites. Спроектируйте pit_customer: какие столбцы в нём будут? Объясните, почему запрос «состояние клиента на дату X» через PIT быстрее, чем без неё.
4. Найдите в своей схеме цепочку из двух и более переходов через Links, которая часто запрашивалась бы. Спроектируйте для неё bridge-таблицу.
5. Сформулируйте: почему PIT и bridge можно безопасно удалить и пересоздать, а Hub, Link и Satellite Raw Vault — нет?

На этом модуль про Data Vault завершён. Дальше — современные подходы к моделированию: medallion, OBT и semantic layer.