0 Fork 0

Files

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

4.9 KiB

Raw Blame History

Слой DDS: бизнес-модель хранилища

Устройство детального слоя: сущности, которыми хранилище говорит с витринами, их связи и правила слоя. Набор собирается развилками карты #127 (этап 4) и правится по мере постройки.

Рамки заданы мастер-спекой «Боевой реализм стенда (v2)»: карта таблиц и витрины — раздел 7, сверка — раздел 4, склейка идентичностей — раздел 5. Дом выбран развилкой #130 — первой, которой понадобилось записать резолюцию в доки: записи этапа 4 живут здесь, по хранилищную сторону границы «источник | хранилище». Устройство источников остаётся их собственным наборам (заказы бэкенда) — генератор переносим и о нашем DDS не знает.

Карта модели

Целостность модели — связи и ко-локация — живёт в этом разделе; файлы сущностей держат глубину и на карту ссылаются.

Заказ (dds.order_v, хранение dds.order_rep / _dist) — физическая сущность: одна строка — заказ в текущем состоянии, позиции массивами в строке, наполняется заменой партиций — модель заказа.
Сессия (dds.session_v, хранение dds.session_rep / _dist) — расчётная сущность: одна строка — визит, нарезку по правилу визита стенд делает сам, VisitID генератора — эталон сверки; наполнение заменой дневной партиции — модель сессии.
Событие (dds.event_v) — контракт над ODS, а не копия: представление, переводящее событие на язык бизнес-модели, — контракт события.
Карта идентичностей (dds.identity_map_v, хранение dds.identity_map_rep / _dist) — кука ↔ пользователь магазина — модель карты.

Связи держатся двумя ключами моста (спека, разделы 4 и 5): purchaseID[1] события равен order_id заказа — по нему идут сверка и сборка склейки; user_id заказа связывает куки одного человека. Ко-локацию задаёт шардирование: события и карта идентичностей раскладываются одним выражением от куки, заказы — от order_id. Поэтому обогащение витрин склейкой локально, а сверка и сборка карты ходят через GLOBAL JOIN с обеими сторонами-подзапросами (исследование соединений).

Правила слоя

DDS обслуживает человека с дашбордом: время лежит в поясе счётчика, пересчёт — один раз при наполнении слоя (дока хранилища, «Часовые пояса»).
Публичный договор каждой сущности — _v; роли объектов и проверяемая граница доступа заданы конвенциями хранилища, «Имена объектов».
Служебные колонки — координаты собственной загрузки слоя; чужие ярлыки не переносятся, а спрашиваются у их слоя по ключу сущности. Вывод правила и цепочка расследования — модель заказа.
Наполняет слой дневной конвейер: запуск, объём прогона и замена партиций на кластере — его устройство.

Открытые решения

Витрины DM — #135.

Родословная

Дом набора и первая сущность собраны развилкой #130 карты #127; форма набора — ADR 0011.

4.9 KiB Raw Blame History