ddmitry/clickstream-data-platform
1
0 Fork 0
Code Issues 5 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Сократить и объяснить холодный запуск стенда #110

New Issue
Closed
opened 2026-08-20 19:11:05 +03:00 by ddmitry · 2 comments
ddmitry commented 2026-08-20 19:11:05 +03:00
Owner
Copy link
Copy source

Цель

Сделать холодный make up приемлемым входом в учебный стенд: сократить время
до готовности и показывать пользователю, какой этап он ждёт.

Ручная приёмка #96 заняла 9 м 12 с. Предыдущий инструментальный прогон на той
же ветке занял 8 м 18 с. Разовая цена допустима, но почти десятиминутное
непрозрачное ожидание мешает начать лабораторную работу.

Сначала выяснить

  • разложить холодный запуск по этапам: сборка образов, инициализация служб,
    генерация событий, отправка слепков, готовность обработчика DAG и приём заказов;
  • отделить обязательную работу от последовательности, которую можно безопасно
    сократить или распараллелить;
  • согласовать бюджет холодного запуска и достаточную индикацию прогресса.

Критерии приёмки

  • Есть воспроизводимый замер длительности каждого крупного этапа холодного make up.
  • Зафиксирован целевой бюджет времени до полностью готового стенда.
  • Пользователь по выводу make up видит текущий этап, а не молчаливое ожидание.
  • Холодный запуск укладывается в согласованный бюджет на контрольной машине.
  • По завершении по-прежнему готовы события, стартовые заказы и пользовательские интерфейсы.
  • Обновлены замеры и описание цены запуска в docs/architecture/testing.md.

Границы

  • Не объявлять стенд готовым, пока данные стартового мира не приняты.
  • Не ослаблять проверки здоровья ради меньшего числа в замере.
  • Не добавлять постоянные наблюдатели и счётчики доставки.
  • Не смешивать оптимизацию запуска с изменением модели мира или данных.

Сначала прочитать

  • Makefile;
  • compose.yaml;
  • scripts/wait-for-world.sh;
  • scripts/ingest-starting-orders.sh;
  • docs/architecture/testing.md.

Проверка

  • make clean
  • /usr/bin/time -p make up
  • make smoke
  • make check-clickhouse
  • make check-services
## Цель Сделать холодный `make up` приемлемым входом в учебный стенд: сократить время до готовности и показывать пользователю, какой этап он ждёт. Ручная приёмка #96 заняла 9 м 12 с. Предыдущий инструментальный прогон на той же ветке занял 8 м 18 с. Разовая цена допустима, но почти десятиминутное непрозрачное ожидание мешает начать лабораторную работу. ## Сначала выяснить - разложить холодный запуск по этапам: сборка образов, инициализация служб, генерация событий, отправка слепков, готовность обработчика DAG и приём заказов; - отделить обязательную работу от последовательности, которую можно безопасно сократить или распараллелить; - согласовать бюджет холодного запуска и достаточную индикацию прогресса. ## Критерии приёмки - [ ] Есть воспроизводимый замер длительности каждого крупного этапа холодного `make up`. - [ ] Зафиксирован целевой бюджет времени до полностью готового стенда. - [ ] Пользователь по выводу `make up` видит текущий этап, а не молчаливое ожидание. - [ ] Холодный запуск укладывается в согласованный бюджет на контрольной машине. - [ ] По завершении по-прежнему готовы события, стартовые заказы и пользовательские интерфейсы. - [ ] Обновлены замеры и описание цены запуска в `docs/architecture/testing.md`. ## Границы - Не объявлять стенд готовым, пока данные стартового мира не приняты. - Не ослаблять проверки здоровья ради меньшего числа в замере. - Не добавлять постоянные наблюдатели и счётчики доставки. - Не смешивать оптимизацию запуска с изменением модели мира или данных. ## Сначала прочитать - `Makefile`; - `compose.yaml`; - `scripts/wait-for-world.sh`; - `scripts/ingest-starting-orders.sh`; - `docs/architecture/testing.md`. ## Проверка - `make clean` - `/usr/bin/time -p make up` - `make smoke` - `make check-clickhouse` - `make check-services`
ddmitry added the needs-triage label 2026-08-20 19:11:05 +03:00
ddmitry changed title from Сократить и объяснить холодный запуск стенда to Отделить пересборку хранилища от полного сброса стенда 2026-08-21 15:51:01 +03:00
ddmitry added ready-for-human and removed needs-triage labels 2026-08-21 15:51:35 +03:00
ddmitry changed title from Отделить пересборку хранилища от полного сброса стенда to Перенести жизненный цикл мира из Compose в Airflow 2026-08-21 16:35:10 +03:00
ddmitry added ready-for-agent and removed ready-for-human labels 2026-08-21 16:35:21 +03:00
ddmitry changed title from Перенести жизненный цикл мира из Compose в Airflow to Сократить и объяснить холодный запуск стенда 2026-08-21 17:48:30 +03:00
ddmitry commented 2026-08-21 17:48:41 +03:00
Author
Owner
Copy link
Copy source

Закрываем исходную задачу без реализации. Разовый холодный запуск за 8–10 минут на контрольном старом ноутбуке допустим, если остаётся редкой операцией. Проблемой его делало частое применение make clean в обычной разработке, а не сама цена полного создания стенда.

make clean сохраняет отдельный смысл: удалить всё постоянное состояние стенда. Оптимизировать этот редкий путь ради повседневной работы не будем. Узкое пересоздание только прикладной схемы, данных мира и состояния генератора вынесено в #119; им управляет Airflow без удаления инфраструктурных томов.

Закрываем исходную задачу без реализации. Разовый холодный запуск за 8–10 минут на контрольном старом ноутбуке допустим, если остаётся редкой операцией. Проблемой его делало частое применение `make clean` в обычной разработке, а не сама цена полного создания стенда. `make clean` сохраняет отдельный смысл: удалить всё постоянное состояние стенда. Оптимизировать этот редкий путь ради повседневной работы не будем. Узкое пересоздание только прикладной схемы, данных мира и состояния генератора вынесено в #119; им управляет Airflow без удаления инфраструктурных томов.
ddmitry added wontfix and removed ready-for-agent labels 2026-08-21 17:48:51 +03:00
ddmitry commented 2026-08-21 18:01:29 +03:00
Author
Owner
Copy link
Copy source

Сохраняю историю развилок — она пригодится в #119.

  1. Исходно предлагалось ускорить сам полный холодный запуск и показывать прогресс. Отклонено: полный сброс редок, ускорять его — лечить не ту причину.

  2. Дальше — адресная очистка отдельных объектов, партиций, баз. Это остаётся правилом по умолчанию при обычной разработке.

  3. Тактический крайний вариант — make rebuild-storage в shell: удаляет только прикладные БД ClickHouse (dm, dds, ods, stg, dic), заново вызывает одноразовые Compose-службы DDL, генератора и слепков, ждёт оба источника и ставит позицию мира в 8. Живой замер: 2 м 25 с, 401 185 событий, 6656 версий заказов; позиция 11 → 8, в ODS только стартовые даты, службы и тома не пересозданы. Прототип доказал, что десять минут платить не нужно, но вскрыл дефект: старые сообщения и офсеты Kafka оставались на месте, а управление миром было размазано между Compose, shell и Airflow.

  4. Рассматривался один разрушительный DAG — и для первого запуска, и для пересоздания. Отклонено: make up не должен разрушать существующий мир.

  5. Принято для #119: world_initialize идемпотентен и на готовом мире не делает ничего; world_recreate ставит world_position = -1, чистит прикладные БД, топики и офсеты, ставит 0 и ждущим вызовом делегирует world_initialize. Отдельный сторож или переменная отвергнуты: состояния -1, 0 и 8+ уже выражаются через world_position. За Compose остаётся инфраструктура, Airflow получает весь жизненный цикл прикладного мира.

Shell-прототип в #119 как реализация не переносится — переносятся его замер и правило: чистить самым узким достаточным способом.

Сохраняю историю развилок — она пригодится в #119. 1. Исходно предлагалось ускорить сам полный холодный запуск и показывать прогресс. Отклонено: полный сброс редок, ускорять его — лечить не ту причину. 2. Дальше — адресная очистка отдельных объектов, партиций, баз. Это остаётся правилом по умолчанию при обычной разработке. 3. Тактический крайний вариант — `make rebuild-storage` в shell: удаляет только прикладные БД ClickHouse (`dm`, `dds`, `ods`, `stg`, `dic`), заново вызывает одноразовые Compose-службы DDL, генератора и слепков, ждёт оба источника и ставит позицию мира в 8. Живой замер: 2 м 25 с, 401 185 событий, 6656 версий заказов; позиция 11 → 8, в ODS только стартовые даты, службы и тома не пересозданы. Прототип доказал, что десять минут платить не нужно, но вскрыл дефект: старые сообщения и офсеты Kafka оставались на месте, а управление миром было размазано между Compose, shell и Airflow. 4. Рассматривался один разрушительный DAG — и для первого запуска, и для пересоздания. Отклонено: `make up` не должен разрушать существующий мир. 5. Принято для #119: `world_initialize` идемпотентен и на готовом мире не делает ничего; `world_recreate` ставит `world_position = -1`, чистит прикладные БД, топики и офсеты, ставит 0 и ждущим вызовом делегирует `world_initialize`. Отдельный сторож или переменная отвергнуты: состояния -1, 0 и 8+ уже выражаются через `world_position`. За Compose остаётся инфраструктура, Airflow получает весь жизненный цикл прикладного мира. Shell-прототип в #119 как реализация не переносится — переносятся его замер и правило: чистить самым узким достаточным способом.
Sign in to join this conversation.
No Branch/Tag Specified
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 wontfix
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-data-platform#110