Этап 2: DDL и генератор #4
Notifications
Due Date
No due date set.
Blocks
Depends on
#5 Этап 3: заказы и каталог
ddmitry/clickstream-data-platform
#3 Этап 1: каркас стенда — кластерный compose
ddmitry/clickstream-data-platform
Reference: ddmitry/clickstream-data-platform#4
Reference in New Issue
Block a user
Part of #1
Цель этапа: собрать DDL событий ON CLUSTER и генератор клиентской стороны целиком (широкое событие, таксономия, анонимность, две куки на покупателя), наладить приём топика
hitsобеими нодами и зафиксировать маленький «зерновой» мир для стабильных приёмок следующих этапов.Спека: docs/specs/2026-07-30-stand-v2-realism.md, разделы 1 и 5.
Минимальный критерий приёмки этапа:
make upработает, smoke-проверки зелёные.Блокируется: #3.
Этап начат с проектирования: спека генератора собрана и принята (тикет #14, карта #26), остальные тикеты нарезаны по ней. Спека генератора: docs/specs/2026-08-01-generator.md.
Дочерние тикеты
Порядок — это и есть цепочка блокировок (нативные зависимости Gitea); #37 и #38 идут параллельно после #36. После холодного ревью нарезки #37 расколот по шву STG/ODS: типизированный ODS выделен в #43.
6 августа 2026 года #41 и #43 переставлены местами. Раньше хранилище шло первым и пинило форму на проводе как первый потребитель, но платило за это дорого: событий в топике ещё нет, значит #43 пришлось бы выдумывать их своим модулем — вторым местом сериализации против правила «сериализатор один». Форма на проводе к тому времени и так записана словами (спека генератора, раздел 4), так что довод за обратный порядок отработал. Заодно три критерия переехали из #41 в #43: «день доезжает до ods.event», «*_errors пуст на честном прогоне» и «повтор не меняет счёт после дедупа» — это утверждения про хранилище, а не про сериализатор.
ddmitry referenced this issue2026-07-30 16:41:39 +03:00
Наблюдение ревьюера #12 — вход для DDL этого этапа.
Smoke-проверка кластера использует шаблон пути в keeper
/clickhouse/tables/{shard}/<таблица>— без{database}и без{uuid}. Для двух временных таблиц проверки этого достаточно, но рабочие DDL слоёв, скопировав этот шаблон, столкнутся: одноимённые таблицы в разных базах получат один и тот же путь в keeper.Решить при написании DDL: добавлять ли
{database}в путь и использовать ли{uuid}(последний завязан на Atomic-движок базы и наdefault_replica_path).Этап принят 7 августа 2026 года.
Приёмка прогнана честно — не «оно вчера работало», а с нуля, и по планке
спеки (раздел 9 называет три цели поимённо), а не по формулировке этой карты:
make clean && make upс пустого стендаmake smokemake check-clickhousemake check-servicesmake lint,make typecheckmake testВсе десять дочерних тикетов закрыты. Вход, висевший на карте с 30 июля
(наблюдение ревьюера #12 про путь в keeper), отработан: DDL слоёв берут
/clickhouse/tables/{shard}/{database}/{table},{uuid}не взят, решениезаписано в
docs/architecture/storage.md.Хвост спеки «Kafka Engine на двух нодах» закрыт решением, а не проверкой:
дубли и раскладку партиций между прогонами решено не проверять — дубль
возможен по устройству движка, а в ODS его схлопывает
ReplacingMergeTree.Решение и свежие замеры записаны в доки — PR #67.
Осталось жить рядом с этапом, но его не блокирует: #65, #63, #60, #48, #47.