ddadminandClaude Opus 5
a82c75705d
- Зачем:
- ярлык snapshot_date выжившей строки доставался жребием, а объём
пересборки DDS держался на константе окна с двумя несверяемыми копиями
(ADR 0014, развилка #163).
- Что:
- ods.order_rep переведена на ReplacingMergeTree(snapshot_date): выживает
строка позднейшего слепка, ярлык стал правдивым.
- order_scope.sql выводит окно из дней последнего слепка; ORDER_WINDOW_DAYS
и параметр window_days сняты со стенда, мёртвая защита краем источника
убрана.
- документы и комментарии SQL приведены к ADR 0014: роль ODS, условие
«одна дата — один слепок», объём прогона и слепые пятна конвейера.
- Проверка:
- make lint; make rebuild-storage, затем make smoke, make check-clickhouse,
make check-services — зелёные.
- после двух слепков snapshot_date всех 1917 строк ods.order_v равен
последнему слепку заказа, расхождений ноль; деловые поля построчно
совпали с эталоном argMax по updated_at из сырья.
- dds_transform без K: первый прогон 06-01…06-07, после нового дня мира
06-02…06-08, повтор прогона содержимого не изменил.
Closes #165
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Слой 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; роли объектов и конвенция чтения заданы докой хранилища, «Имена объектов». - Служебные колонки — координаты собственной загрузки слоя; чужие ярлыки не переносятся, а спрашиваются у их слоя по ключу сущности. Вывод правила и цепочка расследования — модель заказа.
- Наполняет слой дневной конвейер: запуск, объём прогона и замена партиций на кластере — его устройство.
Родословная
Дом набора и первая сущность собраны развилкой #130 карты #127; форма набора — ADR 0011.