Модель данных: широкое событие и второй источник #18

Closed
opened 2026-07-26 21:39:19 +03:00 by ddmitry · 1 comment
Owner

Part of #10

Question

Решить целевую модель данных стенда: переходить ли с четырёх топиков
(склейка по event_id/click_id) на широкое событие кликстрима
(Snowplow-подобное, одна Kafka-таблица) — и чем сохранить интеграционную
учебную ценность.

Рабочие гипотезы владельца и координатора:

  • широкое событие с таксономией event_type; ключ шардирования click_id
    (все джойны DDS/DM становятся локальными на будущем кластере);
  • интеграцию учим на честном втором источнике (заказы бэкенда с суммами
    и/или каталог товаров) вместо «осколков одного трекера»; сверка
    «клиентский purchase против бэкенд-заказа» — учебный сюжет;
  • решение предшествует кластерному (иначе платим за GLOBAL JOIN дважды)
    и определяет форму purchase;
  • цена: генератор, DDL, слои, дашборд, пересборка эталонного мира —
    исполняется после фичи mentee-path.

Фактура: границы применимости стенда (#11), цена кластера (#13),
ресурсный бюджет (#12).

Тело восстановлено дословно из транскрипта сессии; перенос с GitHub 2026-07-26.

Part of #10 ## Question Решить целевую модель данных стенда: переходить ли с четырёх топиков (склейка по event_id/click_id) на широкое событие кликстрима (Snowplow-подобное, одна Kafka-таблица) — и чем сохранить интеграционную учебную ценность. Рабочие гипотезы владельца и координатора: - широкое событие с таксономией event_type; ключ шардирования click_id (все джойны DDS/DM становятся локальными на будущем кластере); - интеграцию учим на честном втором источнике (заказы бэкенда с суммами и/или каталог товаров) вместо «осколков одного трекера»; сверка «клиентский purchase против бэкенд-заказа» — учебный сюжет; - решение предшествует кластерному (иначе платим за GLOBAL JOIN дважды) и определяет форму purchase; - цена: генератор, DDL, слои, дашборд, пересборка эталонного мира — исполняется после фичи mentee-path. Фактура: границы применимости стенда (#11), цена кластера (#13), ресурсный бюджет (#12). *Тело восстановлено дословно из транскрипта сессии; перенос с GitHub 2026-07-26.*
ddmitry added the wayfinder:grilling label 2026-07-26 21:39:19 +03:00
Author
Owner

Резолюция (дословный перенос с GitHub, автор dementev-dev):

Ответ

Да, переходим на широкое событие. Четыре топика-осколка уходят;
модель одна, целевая (двух моделей «для дефолта и для кластера» не держим).
Мотив — реализм: менти должен узнавать в стенде тот кликстрим, с которым
столкнётся на работе. Кластер — побочный довод, не причина.

Форма события — по образцу Яндекс Метрики (фактура — #27,
docs/research/2026-07-26-yandex-clickstream-format.md): плоское широкое
ядро плюс параллельные массивы для многозначного (товары, цели, свои
параметры) плюс одно сырое поле-строка ecommerce. Вложенных объектов в
стиле Segment/Amplitude не делаем. Таксономия event_type вместо «только
pageview». Точный состав полей — в спеку (#17), опора — таблица 53 полей
из исследования.

Интеграционная учебная ценность (взамен склейки осколков):

  • Второй источник — заказы бэкенда. Вторая версия правды о покупке;
    учебный сюжет — сверка клиентского purchase против заказа, расхождения,
    отмены. Форма события заказа и сверка — тикет #15.
  • Транспорт заказов — та же Kafka, но пачками: бэкенд выгружает заказы
    раз в модельный день, с опозданиями и отменами. Одна труба, два режима —
    как в бою, где батчи льют в брокер из удобства. Открывает темы, которых
    у менти нет после курсовой airflow-greenplum: согласование потока и
    батча, поздние данные, кросс-источниковые проверки, сенсоры/Datasets
    (DAG слоя DDS ждёт дневной батч).
  • Каталог товаров — словарь ClickHouse из файла (CSV в репозитории;
    тот же файл использует генератор — расхождений нет по построению).
    Даёт dictGet и политику обновления словаря.

Ландшафт итогом: Kafka — единственная труба (кликстрим потоком,
заказы пачками); Postgres остаётся только служебной базой Airflow;
смешанность ландшафта выражена режимами и частотами, а не второй трубой.

Отклонено по дороге:

  • прямое чтение прод-базы магазина из ClickHouse (движок PostgreSQL /
    словарь из БД) — анти-приём: нагрузка на прод и связность; в документе
    о реализме зафиксировать как явный учебный пункт «в бою — реплика или
    выгрузка»;
  • файловые дропы как источник — учебная ценность здесь мала, файлы — зона
    следующего стенда (Lakehouse); остаются теорией («настоящий Logs API —
    это скачанный TSV»);
  • HTTP-сервис заказов и CDC (Debezium) — цена выше учебной отдачи;
  • каталог отдельным топиком Kafka — выдумка, в бою так не делают.

Честность к Яндексу: у Метрики кликстрим — батч (Logs API), потока в
общем доступе нет; наша Kafka — учебная замена, так и называем в
docs/generator-realism.md.

Что это открывает дальше: #15 (purchase и форма заказа) и #14
(кластер: с широким событием склейка осколков исчезает, ключ шардирования
решается там) разблокированы; новые приёмы стенда — ARRAY JOIN, словари,
сенсоры/Datasets, кросс-источниковый DQ; кандидат — версии записи через
Sign (механика CollapsingMergeTree из потока Метрики Про).

*Резолюция (дословный перенос с GitHub, автор dementev-dev):* ## Ответ **Да, переходим на широкое событие.** Четыре топика-осколка уходят; модель одна, целевая (двух моделей «для дефолта и для кластера» не держим). Мотив — реализм: менти должен узнавать в стенде тот кликстрим, с которым столкнётся на работе. Кластер — побочный довод, не причина. **Форма события — по образцу Яндекс Метрики** (фактура — #27, `docs/research/2026-07-26-yandex-clickstream-format.md`): плоское широкое ядро плюс параллельные массивы для многозначного (товары, цели, свои параметры) плюс одно сырое поле-строка `ecommerce`. Вложенных объектов в стиле Segment/Amplitude не делаем. Таксономия `event_type` вместо «только pageview». Точный состав полей — в спеку (#17), опора — таблица 53 полей из исследования. **Интеграционная учебная ценность** (взамен склейки осколков): - **Второй источник — заказы бэкенда.** Вторая версия правды о покупке; учебный сюжет — сверка клиентского purchase против заказа, расхождения, отмены. Форма события заказа и сверка — тикет #15. - **Транспорт заказов — та же Kafka, но пачками**: бэкенд выгружает заказы раз в модельный день, с опозданиями и отменами. Одна труба, два режима — как в бою, где батчи льют в брокер из удобства. Открывает темы, которых у менти нет после курсовой airflow-greenplum: согласование потока и батча, поздние данные, кросс-источниковые проверки, сенсоры/Datasets (DAG слоя DDS ждёт дневной батч). - **Каталог товаров — словарь ClickHouse из файла** (CSV в репозитории; тот же файл использует генератор — расхождений нет по построению). Даёт `dictGet` и политику обновления словаря. **Ландшафт итогом:** Kafka — единственная труба (кликстрим потоком, заказы пачками); Postgres остаётся только служебной базой Airflow; смешанность ландшафта выражена режимами и частотами, а не второй трубой. **Отклонено по дороге:** - прямое чтение прод-базы магазина из ClickHouse (движок PostgreSQL / словарь из БД) — анти-приём: нагрузка на прод и связность; в документе о реализме зафиксировать как явный учебный пункт «в бою — реплика или выгрузка»; - файловые дропы как источник — учебная ценность здесь мала, файлы — зона следующего стенда (Lakehouse); остаются теорией («настоящий Logs API — это скачанный TSV»); - HTTP-сервис заказов и CDC (Debezium) — цена выше учебной отдачи; - каталог отдельным топиком Kafka — выдумка, в бою так не делают. **Честность к Яндексу:** у Метрики кликстрим — батч (Logs API), потока в общем доступе нет; наша Kafka — учебная замена, так и называем в `docs/generator-realism.md`. **Что это открывает дальше:** #15 (purchase и форма заказа) и #14 (кластер: с широким событием склейка осколков исчезает, ключ шардирования решается там) разблокированы; новые приёмы стенда — ARRAY JOIN, словари, сенсоры/Datasets, кросс-источниковый DQ; кандидат — версии записи через Sign (механика CollapsingMergeTree из потока Метрики Про).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: ddmitry/clickstream-ch-kafka-superset-demo#18