docs(internal): вынесен план работ из PRD в TODO.md
- Зачем: - PRD не должен быть трекером задач, у каждого документа своя роль - Что: - TODO.md реструктурирован: добавлен план подготовки курсовой (5 этапов с рекомендациями по инструментам), выполненные задачи перенесены в отдельную секцию - PRD.md: раздел «План работ» заменён ссылкой на TODO.md, убраны решённые вопросы - Проверка: - просмотр TODO.md и docs/internal/PRD.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,9 +1,93 @@
|
|||||||
# TODO (maintainers / mentors)
|
# TODO (maintainers / mentors)
|
||||||
|
|
||||||
Этот файл собирает идеи по доработке стенда, которые не критичны для текущих задач менти,
|
Этот файл собирает задачи по подготовке стенда к курсовой работе
|
||||||
но улучшат стабильность и удобство сопровождения.
|
и идеи по доработке, которые не критичны для текущих задач менти.
|
||||||
|
|
||||||
Статус: ниже есть как актуальные, так и уже выполненные пункты.
|
Контекст и стратегия: [docs/internal/PRD.md](docs/internal/PRD.md).
|
||||||
|
Дизайн задания: [docs/internal/assignment_design.md](docs/internal/assignment_design.md).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Подготовка курсовой
|
||||||
|
|
||||||
|
> Дедлайн: ~2-3 недели (первый студент может подойти к курсовой).
|
||||||
|
|
||||||
|
### Этап 1. Вынос CSV-пайплайна
|
||||||
|
|
||||||
|
**Инструмент:** Sonnet / Gemini / ChatGPT — механическая работа, перенос файлов.
|
||||||
|
|
||||||
|
- [ ] Перенести в [airflow-manual](https://github.com/dementev-dev/airflow-manual):
|
||||||
|
`csv_to_greenplum.py`, `csv_to_greenplum_dq.py`, `ddl_greenplum_base.py`,
|
||||||
|
`helpers/greenplum.py`, `sql/base/orders_ddl.sql`, связанные тесты
|
||||||
|
- [ ] Убрать CSV-зависимости из docker-compose / .env (`CSV_DIR`, `CSV_ROWS`)
|
||||||
|
- [ ] Обновить README (убрать упоминания CSV-пайплайна)
|
||||||
|
|
||||||
|
### Этап 1.5. Полировка эталона
|
||||||
|
|
||||||
|
**Инструмент:** Opus (глубокий анализ кода и контекста проекта)
|
||||||
|
+ ручное тестирование (make up, запуск DAG'ов, проверка данных).
|
||||||
|
|
||||||
|
- [ ] Протестировать полный ETL-цикл с нуля
|
||||||
|
(make up → bookings-init → STG → ODS → DDS → DM)
|
||||||
|
- [ ] Прогнать инкремент (bookings-generate-day → повторный запуск DAG'ов)
|
||||||
|
- [ ] Почистить код эталонного среза
|
||||||
|
- [ ] Актуализировать README и документацию
|
||||||
|
- [ ] Убедиться, что `make test` и `make lint` проходят
|
||||||
|
- [ ] Проверить, что стенд поднимается на чистой машине
|
||||||
|
|
||||||
|
### Этап 2. Подготовка main
|
||||||
|
|
||||||
|
**Инструмент:** Sonnet — удаление файлов и добавление заглушек
|
||||||
|
по списку из [assignment_design.md](docs/internal/assignment_design.md).
|
||||||
|
|
||||||
|
- [ ] Оставить только эталонный срез (sales_report + цепочка)
|
||||||
|
- [ ] Убрать реализации таблиц-заданий (airplanes, seats, routes в STG/ODS;
|
||||||
|
dim_airplanes, dim_passengers, dim_routes в DDS; 4 витрины DM)
|
||||||
|
- [ ] Добавить TODO-маркеры / заглушки в DAG'ах для студенческих тасков
|
||||||
|
- [ ] Обновить `ddl_gp.sql` (убрать `\i` для таблиц-заданий)
|
||||||
|
|
||||||
|
### Этап 3. ТЗ от аналитика
|
||||||
|
|
||||||
|
**Инструмент:** Opus — нужно глубокое понимание предметной области, маппингов
|
||||||
|
между слоями, SCD-паттернов и педагогического контекста.
|
||||||
|
|
||||||
|
- [ ] Создать `docs/assignment/analyst_spec.md`
|
||||||
|
- [ ] Для каждой таблицы-задания: имя, описание, поля, маппинг,
|
||||||
|
бизнес-правила, тип SCD, гранулярность, distribution key
|
||||||
|
- [ ] Для dim_routes (SCD2): пошаговый алгоритм текстом, формула hashdiff
|
||||||
|
- [ ] Рекомендуемый порядок выполнения
|
||||||
|
|
||||||
|
### Этап 4. Валидационный DAG
|
||||||
|
|
||||||
|
**Инструмент:** Sonnet (шаблонная работа, структура в assignment_design.md)
|
||||||
|
+ Opus для финальной вычитки.
|
||||||
|
|
||||||
|
- [ ] Создать `airflow/dags/bookings_validate.py`
|
||||||
|
- [ ] Создать SQL-скрипты в `sql/validate/`
|
||||||
|
- [ ] Таски по слоям: STG, ODS, DDS, DM
|
||||||
|
- [ ] Дружелюбные сообщения об ошибках с подсказками
|
||||||
|
|
||||||
|
### Этап 5. Ветка solution
|
||||||
|
|
||||||
|
**Инструмент:** Вручную / Sonnet — реализация уже есть в ветке
|
||||||
|
`chore/bookings-etl`, нужно собрать в ветку `solution`.
|
||||||
|
|
||||||
|
- [ ] Создать ветку `solution` от main (после подготовки)
|
||||||
|
- [ ] Добавить полные реализации всех таблиц-заданий
|
||||||
|
- [ ] Проверить, что всё работает end-to-end
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Прочее (бэклог)
|
||||||
|
|
||||||
|
- [ ] Протестировать устойчивость `bookings-db` после остановки контейнеров:
|
||||||
|
- прогнать сценарии `make stop` -> `make up` и `make down` -> `make up`;
|
||||||
|
- зафиксировать, ломается ли генератор/данные в `bookings-db`;
|
||||||
|
- при необходимости добавить шаги восстановления и обновить документацию.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Выполнено
|
||||||
|
|
||||||
- [x] Сделать REST API Airflow основным способом тестирования ETL вместо CLI-вызовов
|
- [x] Сделать REST API Airflow основным способом тестирования ETL вместо CLI-вызовов
|
||||||
через `docker compose exec ... airflow ...`:
|
через `docker compose exec ... airflow ...`:
|
||||||
@@ -11,11 +95,6 @@
|
|||||||
- оставить CLI как резервный вариант для локальной отладки;
|
- оставить CLI как резервный вариант для локальной отладки;
|
||||||
- проверить, что шаги тестирования воспроизводимы без входа в контейнер Airflow.
|
- проверить, что шаги тестирования воспроизводимы без входа в контейнер Airflow.
|
||||||
|
|
||||||
- [ ] Протестировать устойчивость `bookings-db` после остановки контейнеров:
|
|
||||||
- прогнать сценарии `make stop` -> `make up` и `make down` -> `make up`;
|
|
||||||
- зафиксировать, ломается ли генератор/данные в `bookings-db`;
|
|
||||||
- при необходимости добавить шаги восстановления и обновить документацию.
|
|
||||||
|
|
||||||
- [x] Собрать свой образ Airflow поверх `apache/airflow:2.9.2`:
|
- [x] Собрать свой образ Airflow поверх `apache/airflow:2.9.2`:
|
||||||
- вынести установку Python‑зависимостей из runtime (`pip install ...` при старте контейнеров)
|
- вынести установку Python‑зависимостей из runtime (`pip install ...` при старте контейнеров)
|
||||||
в отдельный `Dockerfile`;
|
в отдельный `Dockerfile`;
|
||||||
@@ -27,9 +106,9 @@
|
|||||||
для docker‑стенда:
|
для docker‑стенда:
|
||||||
- проверить, какие параметры достаточно поменять в env/конфиге (`AIRFLOW__CORE__EXECUTOR`)
|
- проверить, какие параметры достаточно поменять в env/конфиге (`AIRFLOW__CORE__EXECUTOR`)
|
||||||
для образа `apache/airflow:2.9.2`;
|
для образа `apache/airflow:2.9.2`;
|
||||||
- убедиться, что примерные DAG’и (`csv_to_greenplum`, `bookings_to_gp_stage`) ведут себя
|
- убедиться, что примерные DAG'и (`csv_to_greenplum`, `bookings_to_gp_stage`) ведут себя
|
||||||
предсказуемо в режиме параллельного исполнения;
|
предсказуемо в режиме параллельного исполнения;
|
||||||
- при необходимости скорректировать тесты и документацию (README/TESTING) с учётом нового executor’а.
|
- при необходимости скорректировать тесты и документацию (README/TESTING) с учётом нового executor'а.
|
||||||
|
|
||||||
- [x] Разобрать и стабилизировать интеграцию с Greenplum/PXF:
|
- [x] Разобрать и стабилизировать интеграцию с Greenplum/PXF:
|
||||||
- убедиться, что PXF в контейнере `greenplum` всегда корректно инициализируется
|
- убедиться, что PXF в контейнере `greenplum` всегда корректно инициализируется
|
||||||
|
|||||||
+4
-21
@@ -233,29 +233,12 @@ solution (полное решение)
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 10. Таймлайн
|
## 10. План работ
|
||||||
|
|
||||||
| Когда | Что |
|
План с чекбоксами и рекомендациями по инструментам: [TODO.md](../../TODO.md).
|
||||||
|------------------|------------------------------------------------------------|
|
|
||||||
| Ближайшие 2-3 нед. | Первый студент может подойти к курсовой |
|
|
||||||
| До этого момента | Подготовить: ТЗ, стартовое состояние main, ветку solution |
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 11. Открытые вопросы (TODO)
|
## 11. Открытые вопросы
|
||||||
|
|
||||||
1. ~~**Выбор эталонного среза**~~ — **РЕШЕНО.** См. [assignment_design.md](assignment_design.md).
|
1. **Название** — рабочее: «Greenplum Bookings DWH». Финализировать.
|
||||||
|
|
||||||
2. ~~**Формат DQ для самоконтроля**~~ — **РЕШЕНО.** Валидационный DAG.
|
|
||||||
См. [assignment_design.md](assignment_design.md).
|
|
||||||
|
|
||||||
3. **Вынос CSV-пайплайна** — перенести `csv_to_greenplum.py`,
|
|
||||||
`csv_to_greenplum_dq.py`, `ddl_greenplum_base.py`, `helpers/greenplum.py`,
|
|
||||||
`sql/base/orders_ddl.sql` и связанные тесты в репозиторий
|
|
||||||
[airflow-manual](https://github.com/dementev-dev/airflow-manual).
|
|
||||||
Решение принято, нужно выполнить.
|
|
||||||
|
|
||||||
4. **Подготовка main** — какие изменения внести в main для стартового
|
|
||||||
состояния (убрать лишние реализации, добавить TODO-маркеры)?
|
|
||||||
|
|
||||||
5. **Название** — рабочее: «Greenplum Bookings DWH». Финализировать.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user