- Зачем:
- переработку steady-stream генератора нужно передать агентам как набор
проверяемых вертикальных задач, а не как один крупный rewrite.
- Что:
- создан локальный набор из семи ready-for-agent задач для реализации новой
иерархической модели генератора.
- добавлен handoff с текущим состоянием обсуждения, рекомендуемым следующим
шагом через TDD и примером команды /goal для запуска задачи 01.
- Проверка:
- git diff HEAD~1 --stat.
- Зачем:
- ответы и документы агентов должны быть читаемы неспециалистом,
без англицизмов и непереведённых слов.
- Что:
- в AGENTS.md (раздел «Обязательные правила») добавлено требование к
языку: понятный русский, устоявшиеся английские термины допустимы,
сложные темы объяснять доступно.
- Проверка:
- git diff AGENTS.md; правило видно в начале раздела обязательных правил.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Зачем:
- закрыть Open questions спеки формы доработки перед передачей на
реализацию; адверсариальное ревью показало, что прежние ориентиры
(популяция/паузы/интенсивность) взаимно несовместимы, а документы
опираются на неверный факт о сиде («1..7 событий на визит»).
- Что:
- добавлена docs/specs/2026-06-10-generator-math-model.md: марковская
цепочка по страницам, формула связи «популяция-интенсивность-пауза»
(λ по умолчанию 30/мин), кулдаун возврата, правило 30 минут на рестарт,
критерии приёмки.
- в CONTEXT.md добавлен профиль сид-датасета (полный замер: длины визитов
1..27, медиана 10, конверсия 25%, петли и события после /confirmation)
и исправлено ложное «разброс времени внутри click_id <= 1 мин».
- исправлен факт «1..7 событий» в KNOWN_ISSUES.md и ADR-0004; критерии
Validation спеки формы доработки приведены к фактам сида.
- Проверка:
- перекрёстные ссылки между спеками/ADR/CONTEXT.md открываются; цифры
профиля сида воспроизводятся скриптом подсчёта по полным data/*.jsonl.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Зачем:
- продолжить работу над генератором в новой сессии без потери контекста.
- Что:
- .scratch/handoffs/2026-06-09-generator-rework.md: где остановились,
ссылки на ADR/спеку, следующий шаг, suggested skills, состояние git.
- Проверка:
- прочитать .scratch/handoffs/2026-06-09-generator-rework.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Зачем:
- при возврате к генератору не переоткрывать выбор «генератор vs реплей»
и иметь готовую рамку требований под реализацию steady-stream.
- Что:
- ADR-0004: steady-stream питается синтетическим иерархическим генератором,
не реплеем сида (обоснование + отклонённые варианты C/B).
- спека docs/specs/2026-06-09: требования к иерархической модели сущностей
и критерии приёмки; математика делегирована follow-up-спеке.
- CONTEXT.md: термины «популяция пользователей», «возвращающийся пользователь».
- Проверка:
- прочитать ADR-0004 и спеку; сверить термины в CONTEXT.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Зачем:
- генератор не влит и неочевидно почему; при возврате к нему легко
переоткрывать заново вывод, что click_id на событие ломает семантику визита.
- Что:
- добавлен KNOWN_ISSUES.md: модель интенсивности ок, модель сущностей неверна,
план перехода на иерархию пользователь -> сессия -> событие.
- в шапку README.md добавлено предупреждение со ссылкой на KNOWN_ISSUES.md.
- Проверка:
- прочитать generator/KNOWN_ISSUES.md и сверить с generate_batch() в generator.py.
- Зачем:
- нужно зафиксировать архитектуру перехода от full refresh к инкрементальной загрузке
- план служит референсом для реализации и code review
- Что:
- добавлен plans/incremental-etl-v2.md с полным описанием:
* архитектура watermark (event_ts + lookback 5min)
* DDL для meta.etl_watermarks_history с TTL 30 дней
* SQL шаблоны для всех слоев (ODS, DDS, DM)
* структура DAG с параллельной загрузкой ODS
* функции get_watermark и save_watermark
* алерты Grafana для late arrivals
* демонстрация late arrivals через комментарии и логи
* сценарии тестирования
* оценка трудозатрат (15-16 часов)
- Проверка:
- файл создан: plans/incremental-etl-v2.md
- структура соответствует принятой архитектуре
- все параметры согласованы (TTL, lookback, параллельность)
- Зачем:
- нужна визуализация метрик generator в реальном времени
- Prometheus job уже настроен, не хватает Grafana dashboard
- Что:
- добавлен provisioning-файл dashboards/generator-overview.json
- 6 разделов: Overview, Events by Topic, Errors, Tick Statistics, Status, Info
- Overview: Total Events/min (все 4 топика), Tick Duration (p50/p99)
- Events by Topic: bar chart Events per Hour, Events Rate, Total Events
- Errors: Total Errors, Error Rate, Errors by Topic (с 'or on() vector(0)')
- Tick Statistics: Duration Distribution, Hour Factor (text), Tick Interval (text)
- Status: Generator Status (threshold 120s), Generator Health (heartbeat), Time Since Last Tick
- Info: команды и предупреждения о хардкоде GEN_TICK_SECONDS=5s
- исправлены панели ошибок с 'or on() vector(0)' для корректного отображения 0
- заменен heatmap на bar chart для стабильности
- добавлены пояснения про Events/min = сумма 4 связанных топиков
- Hour Factor синхронизирован с кодом генератора (00-05/09-18)
- Generator Health: переименовано из State Management с value mappings
- обновлены docs/OPERATIONS.md и generator/README.md
- удален устаревший plans/generator-monitoring-plan.md
- Проверка:
- дашборд открывается на http://localhost:3000/d/generator-overview
- все панели отображают данные корректно (протестировано через Playwright)
- ошибки показывают 0 вместо No data
- Events/min корректно отображает сумму всех 4 топиков (~800-1000/min)
- Зачем:
- упростить и сделать безопаснее сериализацию состояния генератора
- повысить устойчивость старта при временной недоступности Kafka
- Что:
- заменена сериализация rng state на JSON-safe формат без pickle/base64
- добавлено восстановление tuple-структуры rng state после json
- добавлен общий retry с exponential backoff для ensure_topics
- обновлена документация по continuity и ограничениям после рестарта
- расширены тесты state-сценариев и retry-логики
- Проверка:
- make generator-test
- 50 passed
- Зачем:
- генератор должен продолжать работу с места остановки после падения/рестарта
- нужно сохранять continuity тиков и состояние RNG для воспроизводимости
- Что:
- добавлен GeneratorState dataclass (tick, rng_state, last_batch_id, timestamp)
- добавлен KafkaStateManager для работы с compact topic generator_state
- топик создаётся с cleanup.policy=compact (хранится только последнее значение)
- интеграция в GeneratorService: восстановление при старте, сохранение после тика
- новые env: GEN_STATE_ENABLED (по умолчанию true), GEN_STATE_RESET (по умолчанию false)
- добавлены тесты test_state.py
- обновлена документация README.md
- Проверка:
- make generator-test (45 тестов проходят)
- docker compose restart generator - продолжает с сохранённого tick
- GEN_STATE_RESET=true - начинает с tick=1
- Изолированы ошибки history-канала: best-effort с логированием, не валят тик
- Добавлено явное создание топика generator_batch_history при старте
- Добавлена защита от пустого словаря (ValueError при загрузке)
- Обновлена документация о структуре тестов
- Исправлены тесты на пустой словарь
Ревью: изоляция ошибок history, явное создание топика, защита от пустых данных
- Удалён класс InMemoryBatchHistory и вся fallback-логика
- Упрощён KafkaBatchHistory: убраны _initialized, get_stats(), обработка ошибок
- Обновлена документация (generator/README.md, docs/OPERATIONS.md)
- Упрощены тесты, удалены тесты для удалённого функционала
- Код стал честнее: без Kafka генератор падает при старте
Ревьюер: Prometheus даёт достаточно visibility, fallback избыточен
- Зачем:
- ревью rev5: ClickHouse-интеграция была проблемной (порт 9000 native vs HTTP,
неработающий fallback, отсутствие DDL для базы meta)
- архитектурно чище: генератор остаётся pure Kafka producer,
история доступна для аналитики через стандартный ingestion
- Что:
- удален ClickHouseBatchHistory, clickhouse-connect зависимость
- добавлен KafkaBatchHistory с записью в топик generator_batch_history
- добавлен BatchRecord.to_dict() для JSON-сериализации
- добавлен рабочий fallback: Kafka → InMemory при недоступности
- удален pytest-asyncio (не использовался)
- добавлены тесты test_kafka_history.py (15 тестов) и test_service.py (6 тестов)
- обновлена документация: топик вместо таблицы ClickHouse
- Проверка:
- make generator-test: 44/44 тестов пройдено
- docker-compose валиден, генератор не зависит от clickhouse
- Зачем:
- были только standalone скрипты без системы запуска
- нужна стандартная система тестирования для CI/CD
- Что:
- добавлен pytest и pytest-asyncio в requirements.txt
- создана директория tests/ с conftest.py (fixtures)
- разделены тесты по модулям: test_config, test_generation, test_history
- добавлены команды в Makefile: generator-test, generator-test-build, generator-test-cov
- удалены устаревшие test_local.py и test_comprehensive.py
- обновлена документация в README.md
- Проверка:
- make generator-test — 23/23 тестов пройдено
- Зачем:
- нужен постоянный поток данных для демонстрации работы стека
- текущий batch-загрузчик не позволяет показать streaming-сценарии
- Что:
- добавлен сервис generator с режимом steady (Poisson-интенсивность)
- генератор публикует в 4 топика: browser/location/device/geo_events
- сохраняются связи event_id и click_id между событиями
- сборка через uv для скорости и компактности образа
- добавлены команды generator-* в Makefile
- комплексные тесты: валидация, статистика, формат сообщений
- Проверка:
- `docker run --rm -v $(pwd)/..:/workspace -w /workspace/generator generator:test python test_comprehensive.py` — 8/8 тестов
- `make generator-up` — 3 тика без ошибок, отправлено 2904 сообщения
- Зачем:
- зафиксировать решение об observability генератора на уровне MVP-плана
- Что:
- добавлены требования по /metrics, scrape_config и target generator:9109
- добавлен env-параметр GEN_METRICS_PORT
- обновлены шаг внедрения и критерии успеха
- Проверка:
- проверен diff только для plans/generator_demo_stream_plan.md
- Зачем:
- убрать рассинхрон между кратким ТЗ, архитектурой и планом генератора
- Что:
- сокращен docs/DE-task.md до формата краткого ТЗ проекта
- обновлены docs/ARCHITECTURE.md и README.md: bootstrap через kafka_load и steady-stream через generator-service
- обновлен plans/generator_demo_stream_plan.md: режим steady-stream и тик-публикация
- Проверка:
- просмотрен git diff по измененным файлам
- в коммит включены только мои документационные изменения
- Зачем:
- зафиксировать реалистичный MVP без переусложнения
- Что:
- оставлен один режим steady для автономного генератора
- добавлена минимальная статистическая модель потока на базе Poisson
- уточнены минимальные метрики, история batch и короткий roadmap внедрения
- Проверка:
- проверен diff и итоговое содержимое plans/generator_demo_stream_plan.md
- Зачем:
- фича готова: продвинутый курс (уроки 0–6), редизайн Superset, гейт целостности
DDS, мониторинг и выверенные по коду профильные доки. Codex работу завершил.
- Что:
- --no-ff merge ветки docs/advanced-clickstream-course.
- артефакты .scratch/ (handoff'ы, аудит) намеренно исключены из дерева main.
- Проверка:
- git ls-tree -r HEAD не содержит .scratch; git show --summary HEAD — два родителя.
- Зачем:
- следующей сессии нужна точка опоры: что сделано, какой канон у слоёв и какие
хвосты остались вне скоупа.
- Что:
- добавлен .scratch/handoffs/2026-06-06-docs-accuracy-done.md.
- зафиксированы рамка путей (Airflow — основной, scripts/make — запасной),
канон по урокам 2–3 и открытые хвосты (лицензия, непроверенные уроки 0,1,4–6).
- Проверка:
- git show --stat HEAD; ссылки на findings.md и коммит 92e9c4b актуальны.
- Зачем:
- при переработке README выяснилось, что профильные доки местами
отстали от кода; находки нужно сохранить как отдельную задачу, чтобы
не потерять и чинить отдельным проходом.
- Что:
- добавлен .scratch/docs-accuracy-audit/findings.md со сверенными с
кодом расхождениями ARCHITECTURE, OPERATIONS, REPO_MAP,
SUPERSET_DASHBOARD (с привязкой к файлам и строкам).
- находки разнесены по серьёзности и снабжены порядком починки.
- Проверка:
- открыть .scratch/docs-accuracy-audit/findings.md; сверить 🔴-пункты
с указанными строками кода.
- Зачем:
- стенд теперь учебный (для менти и для экспериментов), рекрутерская
рамка DE-задания неактуальна и сбивала читателя; README дублировал
профильные доки и расходился с ними.
- Что:
- README сделан тонким указателем на три двери: курс, быстрый старт,
устройство стенда; объём сокращён с 361 до 96 строк.
- быстрый старт переведён на основной Airflow-путь (ddl_init →
kafka_load → etl_pipeline) вместо legacy make-пути.
- срезаны дубли (DBeaver, структура дашборда, мониторинг, troubleshooting,
Makefile, дерево проекта, «Статус/В планах») с уводом в OPERATIONS,
ARCHITECTURE, REPO_MAP, SUPERSET_DASHBOARD.
- исправлен URL дашборда Superset на slug ecommerce-analytics;
убран фейковый бейдж лицензии.
- Проверка:
- открыть README.md, пройти быстрый старт, проверить рендер mermaid и
рабочие ссылки на профильные доки.
- Зачем:
- следующая сессия продолжает работу над документацией с фокусом на
корневой README; нужен контекст (модель курса, голос, подходы), а не
чек-лист задач.
- Что:
- добавлен .scratch/handoffs/2026-06-06-root-readme-polish.md: модель
курса, линза mentee-first, рабочие подходы, состояние git и рабочего
дерева, направление по корневому README (без предписаний).
- Проверка:
- чистый .md, прогон стенда не нужен.
- Зачем:
- прежний README вёл читателя в авторские доки (PRD/LEARNING_PLAN/
LESSON_STANDARD), а менти нужна точка входа: с чего начать, как ходить
по урокам и как поднять стенд. Цель PRD — самодостаточный материал.
- Что:
- mentee-first структура: «что нужно до старта» (make up → ddl →
LIMIT=50 make data, совпадает с уроками и правилом малого среза),
индекс уроков 0–6 со ссылками и режимом, «как проходить».
- блок-крючок «сам / с ментором» в тон роадмапа + CTA в Telegram.
- авторские доки убраны в секцию «Под капотом курса».
- Проверка:
- все 11 внутренних ссылок резолвятся; ai-text-lint чист (house style сохранён).
- Зачем:
- нужно снять двусмысленность между native filters и click-to-filter в Superset dashboard.
- Что:
- описана фильтрация через левую панель Superset.
- уточнена область действия фильтров по совместимым charts и DM-витринам.
- зафиксировано, что click-to-filter между виджетами не включен.
- Проверка:
- git diff --check -- README.md docs/SUPERSET_DASHBOARD.md docs/course/lessons/06_superset_bi.md.
- Зачем:
- финализация подготовки уроков: пройти обязательный QA-шаг
(ai-text-lint по LESSON_STANDARD §2), привести PRD к факту и убрать
отработанные handoff'ы.
- Что:
- урок 4: убран AI-маркер S01 («не только… но и» → «и… и») по итогам
прогона ai-text-lint; остальные 6 уроков чисты от маркеров.
- PRD §7: закрыты устаревшие открытые вопросы (глубина урока 5, Superset),
оставлен только реальный пункт — ретроспектива после первого прогона.
- удалены 3 отработанных handoff'а в .scratch/handoffs/.
- Проверка:
- git show --stat HEAD; визуальная сверка PRD §7 и урока 4.
- Зачем:
- сквозной ревью курса нашёл расхождения учебного текста с реальным выводом
стенда и один баг в операторских доках — менти увидел бы не то, что в уроке.
- Что:
- урок 2: порядок строк «Статистики ODS» выровнен под фактический вывод
run_batch.sh (4 основных таблицы, затем 4 *_errors); снято «по строчкам».
- урок 3: добавлено пояснение, что check_date — это today() из витрины
(у менти будет своя дата, не как в примере).
- урок 5: «должно быть не в Alerting» → «в состоянии Normal (не Alerting)».
- OPERATIONS.md: несуществующий FULL=1 заменён на реальный knob LIMIT=50
(по умолчанию полный объём — подтверждено load_kafka_data.sh:27,128).
- Проверка:
- git diff показывает 4 файла, +9/-6; grep 'FULL=' по docs/ пуст.
- порядок таблицы сверен с run_batch.sh:111-118; today() — sql/dm/40_dds_to_dm.sql:105.
- Зачем:
- все 11 чекбоксов §3.1 по урокам 2–3 были `[ ]`, хотя правки давно
в коде/уроках; план вводил в заблуждение «работа не сделана».
- Что:
- проставлены `[x]` по урокам 2 и 3 после сверки с реальным кодом
(шапки «поток данных», DQ-split «зачем», чистка legacy-MV, демоут DM,
seed 1919, war-story kafka_ts, recap цепочки).
- в §4 добавлена строка статуса: уроки 0–6 написаны, контент собран.
- Проверка:
- grep '\[ \]' docs/course/LEARNING_PLAN.md # незакрытых пунктов §3.1 нет
- Зачем:
- урок 6 должен совпадать с текущей конфигурацией Superset и не вводить в заблуждение по metadata store.
- Что:
- URL дашборда в уроке переведен на стабильный slug ecommerce-analytics.
- сниппет Page Funnel помечен как фрагмент с ключевыми полями, а не полный params.
- устаревший комментарий про SQLite заменен на PostgreSQL metadata store.
- Проверка:
- python3 -m py_compile superset/init_superset.py superset/create_dashboard.py.
- git diff --check.
- Зачем:
- после замены DQ-чарта на row-lineage в списке «на какие вопросы отвечает
BI» остался повисший пункт «есть ли видимые проблемы качества данных» —
чарта, который на него отвечал, больше нет.
- Что:
- пункт переформулирован под актуальный чарт Rows by Layer
(«доходят ли строки до витрины без потерь по слоям конвейера»).
- Проверка:
- сквозная вычитка урока 6: состав чартов, имена и числа согласованы.
- Зачем:
- все события стенда укладываются в ~50 минут (20:51–21:41 28.11.2022),
поэтому часовая гранулярность давала всего 2 точки и прямую диагональ,
которая читалась как ошибка расчёта и ничему не учила менти.
- Что:
- time_grain_sqla переведён с PT1H на PT5M (~10 точек, реальная форма трафика).
- чарт переименован «Events by Hour» → «Events over Time» (идемпотентно через
previous_slice_names), т.к. «by Hour» противоречит 5-минутным бакетам.
- синхронизированы README, SUPERSET_DASHBOARD.md и урок 6.
- Проверка:
- python3 -m py_compile superset/create_dashboard.py.
- make superset-dashboard (идемпотентно, чарт ID 5 переименован, 10 чартов).
- визуально через playwright-cli: кривая ~11 точек 20:50–21:40, консоль чистая.
- Зачем:
- после смены чарта на row-lineage пользовательская дока, README и урок 6
описывали несуществующий «Data Quality Summary» и старый состав KPI;
термин «зерно (grain)» использовался без пояснения.
- Что:
- SUPERSET_DASHBOARD.md, README, урок 6 описывают «Rows by Layer (event)»,
выровнен состав KPI/чартов; термин «зерно» поясняется в уроке простыми
словами с якорем из данных (события 1000 / визиты 99).
- термин выровнен на «визит» по CONTEXT.md (click_id = визит/сессия).
- в спеку редизайна добавлена секция «Пересмотр после приёмки» как след решения.
- Проверка:
- grep по «Data Quality Summary»/«Row Count» вне handoffs пуст.
- визуальная вычитка изменённых разделов.
- Зачем:
- чарт «Data Quality Summary» суммировал total_rows по всем таблицам слоя,
складывал таблицы разного зерна (события 1000 + визиты 99 + error-таблицы 0)
и рисовал убывающую «воронку потерь» (stg≈4250→ods≈2198→dds≈1099), которой
в данных нет. На учебном стенде это активно вводит в заблуждение.
- Что:
- чарт переделан в row-lineage одного event-зерна и переименован в
«🧱 Rows by Layer (event)»; rename идемпотентный через previous_slice_names.
- чарт берёт по одной канонической таблице на слой
(browser_raw→browser_event→event→v_events_enriched), порядок слоёв задан
числовым префиксом в groupby + order_bars.
- в dm.dq_summary добавлена строка total_rows для слоя dm, чтобы цепочка
замыкалась до витрины.
- описание дашборда обновлено под новый смысл.
- Проверка:
- python3 -m py_compile superset/create_dashboard.py.
- make transform / прогон sql/dm/40_dds_to_dm.sql; в dq_summary есть строка dm.
- make superset-dashboard (идемпотентно, 10 чартов, дублей нет).
- визуально через playwright-cli: 4 столбца 1·stg→2·ods→3·dds→4·dm,
видимый шаг дедупликации 1050→1000, консоль без ошибок.
- Зачем:
- нужно убрать дублирующий KPI Unique Sessions и сделать эталонный dashboard честнее для учебного анализа.
- Что:
- обновлены KPI, добавлена Conversion to /confirmation и Page Funnel.
- добавлена идемпотентная миграция старых chart names без дублей.
- синхронизированы документация, урок 6 и спека редизайна.
- добавлен handoff для продолжения работы в новой сессии.
- Проверка:
- python3 -m py_compile superset/create_dashboard.py.
- make superset-dashboard.
- Superset metadata: dashboard_charts=10, obsolete_unique_sessions=0, page_funnel_type=funnel.
- Зачем:
- Codex силён в реализации, но визуальную приёмку дашборда не вытянет —
нужно явно оставить screenshot sign-off человеку/vision-агенту.
- Что:
- в handoff добавлен блок «Если задачу берёт Codex»: не визуальные само-проверки
его, визуальный sign-off — отдельно.
- Проверка:
- .scratch/handoffs/2026-06-06-...md содержит блок и не закрывает done по визуалу.
- Зачем:
- дашборд-эталон показывал две одинаковые KPI-плитки; нужен честный состав метрик
на полных данных, зафиксированный до реализации.
- Что:
- docs/specs/2026-06-06-...: KPI Events/Users/Avg per Visit/Conversion, Top Pages → Funnel, триаж чартов.
- .scratch/handoffs/2026-06-06-...: handoff для реализации в новой сессии.
- Проверка:
- числа спеки сверены с прямым запросом в ClickHouse на полном датасете.
- Зачем:
- зафиксировать доменный язык, чтобы метрики дашборда и урок 6 опирались на единые термины.
- Что:
- добавлен CONTEXT.md: пользователь/визит-сессия/событие, иерархия, почему на демо Users == Sessions.
- Проверка:
- термины сверены с sql/ddl/dds/30_dds.sql и sql/ddl/dm/40_dm.sql.
- Зачем:
- артефакты браузерной автоматизации не должны попадать в индекс.
- Что:
- добавлены .playwright-cli и .playwright-mcp в .gitignore.
- Проверка:
- git status не показывает .playwright-cli/ после прогона playwright-cli.
- Зачем:
- дашборд рендерился одной колонкой во всю ширину, а KPI показывали
значение последнего часового бакета (1/1/1) вместо итогов по срезу.
- Что:
- чарты разложены по строкам-контейнерам ROW (Superset layout v2):
KPI-полоса 4-в-ряд + аналитические блоки парами вместо плоского
списка CHART под GRID с игнорируемыми x/y.
- KPI переведены с big_number на big_number_total без granularity_sqla;
sync_query_context чистит granularity/time_grain для тотала.
- Проверка:
- make superset-dashboard; GET /api/v1/dashboard/1/datasets → 200;
position_json содержит 4 ROW; KPI показывают 50/26/26/1.92.
- Зачем:
- Superset dashboard открывался с ошибками datasources и неудобным layout, а курс не содержал готового урока по BI-витрине.
- Что:
- добавлен урок 6 про Superset поверх ClickHouse DM-витрин.
- исправлена раскладка dashboard и дефолтный фильтр даты для исторических демо-данных.
- добавлено восстановление metadata колонок датасетов при обновлении dashboard.
- Проверка:
- make superset-dashboard.
- /api/v1/dashboard/1/datasets и /superset/explore_json для chart 10 возвращают 200.
- python3 -m py_compile superset/create_dashboard.py; git diff --cached --check.
- Зачем:
- перечитка урока 3 свежим взглядом нашла баг в его эталонном пути: проверки
device_not_found/geo_not_found/location_not_found в DDS никогда не срабатывали,
а текст урока ошибочно утверждал, что метки ставятся
- Что:
- sql/dds/30_ods_to_dds.sql: добавлен SETTINGS join_use_nulls=1 в оба
INSERT...SELECT. Без него LEFT JOIN на несовпадении клал в assumeNotNull(click_id)
нулевой UUID (не NULL), и if(...IS NULL, ['*_not_found'], []) молча давал []
(мёртвый код). Тот же класс бага про типы/NULL, что kafka_ts в уроке 1
- docs/course/lessons/03_ods_to_dds.md: убраны ложные claim'ы про geo_not_found/
location_not_found, формулировки приведены к реальному поведению (клик без гео
остаётся с пустыми полями NULL; целостность событий — через orphan_events);
поправлена опечатка «список всех клиентов» → «всех кликов»
- Проверка:
- синтетический тест join_use_nulls=1: клик в device без geo → в ods_parse_errors
появляются geo_not_found и geo_country_missing (до фикса — пусто)
- LIMIT=50 make transform после фикса: dds.click=26, dds.event=50,
orphan_events=0, ни одной строки с непустым ods_parse_errors (вывод не изменился —
на чистом срезе несовпадений нет)
Dmitry Dementiev
ddadminandDmitry Dementiev