Files
clickstream-data-platform/docs/architecture/dds/README.md
T
ddadminandClaude Fable 5 ebe3de4ae8 docs(etl): спроектирован дневной конвейер трансформаций
Зачем: развилка #134 карты #127 — чем и когда гоняются трансформации DDS
и витрины-таблицы, пока спека числила etl_pipeline за этапом 5.

Что: дока docs/architecture/etl.md — даг etl_pipeline рождается этапом 4:
дёргает dds_transform и dm_transform последовательно (DQ — будущее звено);
живой день зовёт его с ожиданием после установки позиции, после разгона
пачкой менти запускает рукой, world_initialize — последним шагом; параметров
нет, объём выводится из world_position и состояния слоёв; первый шаг —
ожидание хвоста hits; механика REPLACE PARTITION — этап 4, этапу 5 —
партиционная переобработка. Указатели в доках заказа, сессии, README слоя
и ретро-пометки в ADR 0008/0009 переведены на новую доку.

Проверка: вычитка; резолюция и доводы — в тикете #134.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 03:22:35 -04:00

65 lines
4.9 KiB
Markdown

# Слой DDS: бизнес-модель хранилища
Устройство детального слоя: сущности, которыми хранилище говорит с
витринами, их связи и правила слоя. Набор собирается развилками карты #127
(этап 4) и правится по мере постройки.
Рамки заданы мастер-спекой [«Боевой реализм стенда
(v2)»](../../specs/2026-07-30-stand-v2-realism.md): карта таблиц и витрины —
раздел 7, сверка — раздел 4, склейка идентичностей — раздел 5. Дом выбран
развилкой #130 — первой, которой понадобилось записать резолюцию в доки:
записи этапа 4 живут здесь, по хранилищную сторону границы
«источник | хранилище». Устройство источников остаётся их
собственным наборам ([заказы бэкенда](../orders/README.md)) — генератор
переносим и о нашем DDS не знает.
## Карта модели
Целостность модели — связи и ко-локация — живёт в этом разделе; файлы
сущностей держат глубину и на карту ссылаются.
- **Заказ** (`dds.order_v`, хранение `dds.order_rep` / `_dist`) — физическая
сущность: одна строка — заказ в текущем состоянии, позиции массивами в
строке, наполняется заменой партиций — [модель заказа](order.md).
- **Сессия** (`dds.session_v`, хранение `dds.session_rep` / `_dist`) —
расчётная сущность: одна строка — визит,
нарезку по правилу визита стенд делает сам, `VisitID` генератора — эталон
сверки; наполнение заменой дневной партиции — [модель сессии](session.md).
- **Событие** (`dds.event_v`) — контракт над ODS, а не копия: представление,
переводящее событие на язык бизнес-модели, — [контракт события](event.md).
- **Карта идентичностей** (`dds.identity_map_v`, хранение
`dds.identity_map_rep` / `_dist`) — кука ↔ пользователь магазина —
[модель карты](identity.md).
Связи держатся двумя ключами моста (спека, разделы 4 и 5): `purchaseID[1]`
события равен `order_id` заказа — по нему идут сверка и сборка склейки;
`user_id` заказа связывает куки одного человека. Ко-локацию задаёт
шардирование: события и карта идентичностей раскладываются одним выражением
от куки, заказы — от `order_id`. Поэтому обогащение витрин склейкой
локально, а сверка и сборка карты ходят через GLOBAL JOIN с обеими
сторонами-подзапросами ([исследование
соединений](../../research/2026-08-22-distributed-join.md)).
## Правила слоя
- DDS обслуживает человека с дашбордом: время лежит в поясе счётчика,
пересчёт — один раз при наполнении слоя ([дока хранилища](../storage.md),
«Часовые пояса»).
- Публичный договор каждой сущности — `_v`; роли объектов и проверяемая
граница доступа заданы [конвенциями хранилища](../storage.md), «Имена
объектов».
- Служебные колонки — координаты собственной загрузки слоя; чужие ярлыки не
переносятся, а спрашиваются у их слоя по ключу сущности. Вывод правила и
цепочка расследования — [модель заказа](order.md).
- Наполняет слой [дневной конвейер](../etl.md): запуск, объём прогона и
замена партиций на кластере — его устройство.
## Открытые решения
- Витрины DM — #135.
## Родословная
Дом набора и первая сущность собраны развилкой #130 карты #127; форма
набора — [ADR 0011](../../adr/0011-component-docs.md).