ddmitry/clickstream-ch-kafka-superset-demo
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Карта: боевой реализм стенда #10

New Issue
Closed
opened 2026-07-26 21:39:10 +03:00 by ddmitry · 3 comments
ddmitry commented 2026-07-26 21:39:10 +03:00
Owner
Copy Link
Copy Source

Destination

Принятая спека в docs/specs/ «Боевой реализм стенда»: где менти получает
кластерный опыт ClickHouse и в какой топологии; какие доработки реализма
данных генератора делаем; явные границы. Спека готова к разбиению через
/to-tickets.

Notes

  • Расчёт на ноутбук менти 16 ГБ RAM (у кого 8 ГБ — VDS за счёт менти).
  • Исполнение доработок — после фичи «Редизайн пути менти» (#9); карта
    решений может идти параллельно с ней.
  • Изменения генератора тянут пересборку эталонного мира
    (data/startup_history/reference-world.json.xz) и «поплывшие» числа
    в лабах — учитывать в каждом решении.
  • Скиллы: /grilling и /domain-modeling для тикетов-решений,
    /research для тикетов-исследований.
  • Рабочая гипотеза владельца: кластер здесь, облегчённо (2 шарда без
    реплик), цель — Distributed и ON CLUSTER на живом потоке; «голый»
    clickhouse-learning-cluster этого не даёт.
  • Порядок: решение по модели данных предшествует кластерному — иначе
    межшардовые джойны четырёх топиков придётся оплатить дважды.

Decisions so far

  • Реализм генератора: границы применимости стенда — документ
    docs/generator-realism.md (коммит 068d96f): честно как в бою —
    схема/воронка/сессии/волна/обвязка; упрощено — четыре топика, только
    pageview, клоны пользователей, нет «грязи», масштаб.
  • Ресурсный бюджет стенда на 16 ГБ — полный стенд в покое ≈3,4 ГБ;
    2×1 добавляет ≈0,6–0,8 ГБ (влезает свободно), 2×2 — ≈1,7–1,9 ГБ (влезает,
    но впритык к дефолтному бюджету WSL2 ~8 ГБ); координатором брать
    clickhouse-keeper, не ZooKeeper.
  • Цена кластера для пайплайна — объём средне-крупный (~15–20 файлов,
    тяжёлое — SQL); главная боль — JOIN поверх Distributed и TRUNCATE в
    трансформациях (риск для контрольных сумм), приём из Kafka требует одного
    консьюмера + Distributed-цели; рекомендация исследования — опциональный
    make up-cluster, не дефолт.
  • Что отдаёт Яндекс как кликстрим — плоское широкое ядро (~140
    колонок) плюс параллельные массивы для многозначного, вложенного JSON
    нет (Яндекс ближе к Snowplow, чем к Segment); доставка батчем (Logs API,
    TSV, лог доформировывается ~3 дня), поток только в «Метрике Про» через
    Data Transfer с задержкой до 15 минут — Kafka у Яндекса нет, наша Kafka
    учебная замена; детали в docs/research/2026-07-26-yandex-clickstream-format.md
    (влита в main, коммит e6e34f2).
  • Модель данных: широкое событие и второй источник — переходим на
    одно широкое событие по образцу Яндекс Метрики (плоское ядро +
    параллельные массивы + сырое поле ecommerce, таксономия event_type);
    интеграционная ценность — заказы бэкенда той же Kafka, но пачками с
    опозданиями и отменами (одна труба, два режима), каталог товаров —
    словарь ClickHouse из файла; прямое чтение прод-Postgres и файловые
    источники отклонены (файлы — зона Lakehouse-стенда); Kafka — учебная
    замена батчевого Logs API, фиксируем в docs/generator-realism.md.
  • Purchase с выручкой: форма события и место в стенде — деньги на
    обеих сторонах (клиент объявляет через dataLayer, бэкенд — итоговая
    правда; атрибуция по трекеру, деньги по бэкенду); клиент:
    pageview+add_to_cart+purchase; заказы — ежедневный полный слепок
    окна изменяемости K со статусами и JSON-позициями, приём через
    ReplacingMergeTree; сверка по purchaseID=order_id с четырьмя
    конструируемыми расхождениями (отмена, потеря, дельта суммы, дубль);
    выручка в DM — только от заказов.
  • Кластер: где живёт опыт менти и какая топология — кластер в
    стенде единственным режимом: 2 шарда × 1 реплика + clickhouse-keeper,
    движки Replicated*, без HAProxy, Superset — на вторую ноду
    (рекомендация #13 об опциональном профиле пересмотрена); шардирование
    событий по clientID, заказы hash(order_id) + GLOBAL-сверка; приём
    Kafka обеими нодами в Distributed-цели; конвейер без TRUNCATE —
    append + переобработка по дневным партициям; проверки только по
    Distributed; хвосты — в спеку #17 (резолюция в #14).
  • Анонимы и identity stitching — кликстрим полностью анонимный:
    у события только clientID (честно к Logs API Метрики, email из событий
    уходит); склейка — через мост purchase↔заказ, без новых полей и
    транспорта; N:1 — часть покупателей с двумя куками; лаба «сколько
    посетителей мы знаем» + лекция «как в бою»; витрины разводят
    «посетителей» и «известных пользователей», манифест получает числа
    идентичности; доля и форма карты — в спеку #17 (резолюция в #16).

Not yet specified

  • «Грязь» в данных: боты, дубли событий, опоздавшие мобильные батчи,
    расхождение часов клиент/коллектор — вернуться после решений по
    purchase и identity.
  • Политика версионирования эталонного артефакта при изменениях
    генератора (когда пересобирать, как жить лабам со сменой чисел).
  • Как новые возможности лягут в лабы курса (после редизайна лаб, #7).

Out of scope

  • Формат доставки событий: закрыть теорией — решение отменено
    2026-07-22: исследование цены кластера показало, что четыре топика
    несовместимы с шардированием без GLOBAL JOIN; вопрос вернулся в рамку
    тикетом «Модель данных: широкое событие и второй источник» (#18).
  • Редизайн лаб курса — отдельный issue #7.
  • Инкрементальный ETL — отдельный issue #8; багфиксы — #1, #2.

Перенесено с GitHub (github.com/dementev-dev, аккаунт заблокирован
2026-07-26). Строка про #15 в Decisions so far добавлена при переносе —
на GitHub она доехать не успела.

## Destination Принятая спека в `docs/specs/` «Боевой реализм стенда»: где менти получает кластерный опыт ClickHouse и в какой топологии; какие доработки реализма данных генератора делаем; явные границы. Спека готова к разбиению через `/to-tickets`. ## Notes - Расчёт на ноутбук менти 16 ГБ RAM (у кого 8 ГБ — VDS за счёт менти). - Исполнение доработок — после фичи «Редизайн пути менти» (#9); карта решений может идти параллельно с ней. - Изменения генератора тянут пересборку эталонного мира (`data/startup_history/reference-world.json.xz`) и «поплывшие» числа в лабах — учитывать в каждом решении. - Скиллы: `/grilling` и `/domain-modeling` для тикетов-решений, `/research` для тикетов-исследований. - Рабочая гипотеза владельца: кластер здесь, облегчённо (2 шарда без реплик), цель — Distributed и ON CLUSTER на живом потоке; «голый» clickhouse-learning-cluster этого не даёт. - Порядок: решение по модели данных предшествует кластерному — иначе межшардовые джойны четырёх топиков придётся оплатить дважды. ## Decisions so far <!-- одна строка на закрытый тикет: гист + ссылка --> - [Реализм генератора: границы применимости стенда](#11) — документ `docs/generator-realism.md` (коммит 068d96f): честно как в бою — схема/воронка/сессии/волна/обвязка; упрощено — четыре топика, только pageview, клоны пользователей, нет «грязи», масштаб. - [Ресурсный бюджет стенда на 16 ГБ](#12) — полный стенд в покое ≈3,4 ГБ; 2×1 добавляет ≈0,6–0,8 ГБ (влезает свободно), 2×2 — ≈1,7–1,9 ГБ (влезает, но впритык к дефолтному бюджету WSL2 ~8 ГБ); координатором брать clickhouse-keeper, не ZooKeeper. - [Цена кластера для пайплайна](#13) — объём средне-крупный (~15–20 файлов, тяжёлое — SQL); главная боль — JOIN поверх Distributed и TRUNCATE в трансформациях (риск для контрольных сумм), приём из Kafka требует одного консьюмера + Distributed-цели; рекомендация исследования — опциональный `make up-cluster`, не дефолт. - [Что отдаёт Яндекс как кликстрим](#27) — плоское широкое ядро (~140 колонок) плюс параллельные массивы для многозначного, вложенного JSON нет (Яндекс ближе к Snowplow, чем к Segment); доставка батчем (Logs API, TSV, лог доформировывается ~3 дня), поток только в «Метрике Про» через Data Transfer с задержкой до 15 минут — Kafka у Яндекса нет, наша Kafka учебная замена; детали в `docs/research/2026-07-26-yandex-clickstream-format.md` (влита в main, коммит `e6e34f2`). - [Модель данных: широкое событие и второй источник](#18) — переходим на одно широкое событие по образцу Яндекс Метрики (плоское ядро + параллельные массивы + сырое поле `ecommerce`, таксономия event_type); интеграционная ценность — заказы бэкенда той же Kafka, но пачками с опозданиями и отменами (одна труба, два режима), каталог товаров — словарь ClickHouse из файла; прямое чтение прод-Postgres и файловые источники отклонены (файлы — зона Lakehouse-стенда); Kafka — учебная замена батчевого Logs API, фиксируем в docs/generator-realism.md. - [Purchase с выручкой: форма события и место в стенде](#15) — деньги на обеих сторонах (клиент объявляет через dataLayer, бэкенд — итоговая правда; атрибуция по трекеру, деньги по бэкенду); клиент: `pageview`+`add_to_cart`+`purchase`; заказы — ежедневный полный слепок окна изменяемости K со статусами и JSON-позициями, приём через ReplacingMergeTree; сверка по `purchaseID`=`order_id` с четырьмя конструируемыми расхождениями (отмена, потеря, дельта суммы, дубль); выручка в DM — только от заказов. - [Кластер: где живёт опыт менти и какая топология](#14) — кластер в стенде единственным режимом: 2 шарда × 1 реплика + clickhouse-keeper, движки Replicated*, без HAProxy, Superset — на вторую ноду (рекомендация #13 об опциональном профиле пересмотрена); шардирование событий по clientID, заказы hash(order_id) + GLOBAL-сверка; приём Kafka обеими нодами в Distributed-цели; конвейер без TRUNCATE — append + переобработка по дневным партициям; проверки только по Distributed; хвосты — в спеку #17 (резолюция в #14). - [Анонимы и identity stitching](#16) — кликстрим полностью анонимный: у события только clientID (честно к Logs API Метрики, email из событий уходит); склейка — через мост purchase↔заказ, без новых полей и транспорта; N:1 — часть покупателей с двумя куками; лаба «сколько посетителей мы знаем» + лекция «как в бою»; витрины разводят «посетителей» и «известных пользователей», манифест получает числа идентичности; доля и форма карты — в спеку #17 (резолюция в #16). ## Not yet specified - «Грязь» в данных: боты, дубли событий, опоздавшие мобильные батчи, расхождение часов клиент/коллектор — вернуться после решений по purchase и identity. - Политика версионирования эталонного артефакта при изменениях генератора (когда пересобирать, как жить лабам со сменой чисел). - Как новые возможности лягут в лабы курса (после редизайна лаб, #7). ## Out of scope - ~~Формат доставки событий: закрыть теорией~~ — решение отменено 2026-07-22: исследование цены кластера показало, что четыре топика несовместимы с шардированием без GLOBAL JOIN; вопрос вернулся в рамку тикетом «Модель данных: широкое событие и второй источник» (#18). - Редизайн лаб курса — отдельный issue #7. - Инкрементальный ETL — отдельный issue #8; багфиксы — #1, #2. --- *Перенесено с GitHub (github.com/dementev-dev, аккаунт заблокирован 2026-07-26). Строка про #15 в Decisions so far добавлена при переносе — на GitHub она доехать не успела.*
ddmitry added the wayfinder:map label 2026-07-26 21:39:10 +03:00
ddmitry commented 2026-07-26 21:39:11 +03:00
Author
Owner
Copy Link
Copy Source

Перенос с GitHub (автор dementev-dev, 2026-07-23):

Решение 2026-07-23: дальнейшая работа карты пойдёт в новом v2-репозитории.
v1 замораживается как стабильный стенд для менти (добить путь менти, баги
#1/#2, лекции). v2 стартует пустым репозиторием с осознанным первым
коммитом (переносим только нужное; генератор переписывается,
переиспользуются идеи). Имя нового репозитория выберем из решения о нише;
карта и открытые тикеты переедут туда после создания.

*Перенос с GitHub (автор dementev-dev, 2026-07-23):* Решение 2026-07-23: дальнейшая работа карты пойдёт в новом v2-репозитории. v1 замораживается как стабильный стенд для менти (добить путь менти, баги #1/#2, лекции). v2 стартует пустым репозиторием с осознанным первым коммитом (переносим только нужное; генератор переписывается, переиспользуются идеи). Имя нового репозитория выберем из решения о нише; карта и открытые тикеты переедут туда после создания.
ddmitry commented 2026-07-26 21:39:12 +03:00
Author
Owner
Copy Link
Copy Source

Перенос с GitHub (автор dementev-dev, 2026-07-23):

Рабочий кандидат имени v2-репозитория: clickstream-data-platform
(согласован 2026-07-23). Мотив: стенд перерастает классическое DWH —
потоковый приём, оркестрация, кластер, витрины; «data platform» описывает
целое. Финальное закрепление — при решении тикета о нише.

*Перенос с GitHub (автор dementev-dev, 2026-07-23):* Рабочий кандидат имени v2-репозитория: **clickstream-data-platform** (согласован 2026-07-23). Мотив: стенд перерастает классическое DWH — потоковый приём, оркестрация, кластер, витрины; «data platform» описывает целое. Финальное закрепление — при решении тикета о нише.
ddmitry commented 2026-07-30 16:00:11 +03:00
Author
Owner
Copy Link
Copy Source

Карта переехала в v2: ddmitry/clickstream-data-platform#1. Спека принята (#17), исполнение — в clickstream-data-platform.

Карта переехала в v2: https://git.dementev.space/ddmitry/clickstream-data-platform/issues/1. Спека принята (#17), исполнение — в clickstream-data-platform.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No labels wayfinder:map
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ddmitry/clickstream-ch-kafka-superset-demo#10