Согласовать руководства загрузок и справочники с учебным маршрутом #4

Closed
opened 2026-09-20 19:07:54 +03:00 by ddmitry · 1 comment
Owner

Part of #1
Blocked by: #3

Учебная цель

При переходе из карты или задания к подробностям менти получает актуальное объяснение и может отличить инструкцию для работающего стенда от старого плана разработки.

Что сделать

  1. Проверить четыре руководства docs/bookings_to_gp_{stage,ods,dds,dm}.md на соответствие текущим SQL/DAG и требованиям учебных заглушек. Сосредоточить их на предпосылках запуска, действиях загрузки, результате и поиске ошибок; объяснения структуры связать с картой.
  2. Согласовать docs/dag_execution_order.md с README и руководствами загрузок. Движение данных, порядок задач и зерно таблиц описывать точно.
  3. Разобрать документы docs/design/bookings_*_design.md: отделить полезные актуальные объяснения от планов создания уже существующих файлов. Старые планы явно обозначить как историю разработки и убрать из основного маршрута менти. Содержательные материалы не удалять без определения места, где они остаются доступны.
  4. Проверить роли TESTING.md, docs/reference/qa-plan.md, docs/reference/dq_taxonomy.md и docs/design/naming_conventions.md в навигации. Ученик должен находить проверку своего задания отдельно от проверки разработки и глубокой диагностики стенда.
  5. Устранить повторяющиеся несовместимые описания на пути карта → руководство → SQL/ТЗ. Для действующего кода сверяться с реализацией; для заглушек противоречие требований требует явного решения, которое затем отражается во всех затронутых местах.

Уже найденные места для проверки

  • docs/design/bookings_ods_design.md показывает загрузку ods.airports через UPDATE/INSERT; действующий sql/ods/airports_load.sql выполняет TRUNCATE/INSERT.
  • В docs/bookings_to_gp_dds.md обновление описательных полей dim_routes распространяется на все версии, а в analyst_spec.md — на открытые версии. На main загрузчик является заглушкой: корректный договор нельзя определить из SELECT 1;.
  • docs/bookings_to_gp_dds.md называет загрузку календаря полным пересозданием, а дизайн-документ описывает заполнение один раз. Проверить действующий SQL.
  • docs/dag_execution_order.md говорит о загрузке новых рейсов в факт, тогда как зерно факта — пара (ticket_no, flight_id).

Границы

Работа ограничена документами, к которым ведет учебный маршрут, и необходимыми правками ссылок. Не превращать ее в переписывание всей истории проекта. Содержание программы, SQL, DAG, DDL, конфигурация и данные стенда не меняются.

Критерии готовности

  • На основном пути чтения отсутствуют неотмеченные старые планы разработки, представленные как актуальные инструкции.
  • Руководства загрузок различают действующую реализацию и ожидаемое поведение учебных заглушек.
  • Найденные расхождения проверены; для каждого зафиксировано исправление либо согласованное решение по требованиям.
  • У каждого существенного правила есть основной документ, а остальные места ссылаются на него без несовместимых копий.
  • Из заданий легко найти их самопроверку; тесты разработки и глубокая диагностика вынесены из обязательного первого чтения.
  • Проверены внутренние ссылки, имена таблиц и файлов, команды из измененных инструкций и отсутствие изменений SQL/DAG.
  • Повторно пройден целиком маршрут README → структура/карта → разбор SQL → первое задание → проверка результата; указано, какие шаги проверены чтением, а какие выполнены на стенде.

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

Результаты двух предыдущих задач; индекс документации, четыре руководства загрузок, порядок запуска, ТЗ, действующие SQL/DAG, docs/design/bookings_*_design.md.

Part of #1 Blocked by: #3 ## Учебная цель При переходе из карты или задания к подробностям менти получает актуальное объяснение и может отличить инструкцию для работающего стенда от старого плана разработки. ## Что сделать 1. Проверить четыре руководства `docs/bookings_to_gp_{stage,ods,dds,dm}.md` на соответствие текущим SQL/DAG и требованиям учебных заглушек. Сосредоточить их на предпосылках запуска, действиях загрузки, результате и поиске ошибок; объяснения структуры связать с картой. 2. Согласовать `docs/dag_execution_order.md` с README и руководствами загрузок. Движение данных, порядок задач и зерно таблиц описывать точно. 3. Разобрать документы `docs/design/bookings_*_design.md`: отделить полезные актуальные объяснения от планов создания уже существующих файлов. Старые планы явно обозначить как историю разработки и убрать из основного маршрута менти. Содержательные материалы не удалять без определения места, где они остаются доступны. 4. Проверить роли `TESTING.md`, `docs/reference/qa-plan.md`, `docs/reference/dq_taxonomy.md` и `docs/design/naming_conventions.md` в навигации. Ученик должен находить проверку своего задания отдельно от проверки разработки и глубокой диагностики стенда. 5. Устранить повторяющиеся несовместимые описания на пути карта → руководство → SQL/ТЗ. Для действующего кода сверяться с реализацией; для заглушек противоречие требований требует явного решения, которое затем отражается во всех затронутых местах. ## Уже найденные места для проверки - `docs/design/bookings_ods_design.md` показывает загрузку `ods.airports` через UPDATE/INSERT; действующий `sql/ods/airports_load.sql` выполняет TRUNCATE/INSERT. - В `docs/bookings_to_gp_dds.md` обновление описательных полей `dim_routes` распространяется на все версии, а в `analyst_spec.md` — на открытые версии. На `main` загрузчик является заглушкой: корректный договор нельзя определить из `SELECT 1;`. - `docs/bookings_to_gp_dds.md` называет загрузку календаря полным пересозданием, а дизайн-документ описывает заполнение один раз. Проверить действующий SQL. - `docs/dag_execution_order.md` говорит о загрузке новых рейсов в факт, тогда как зерно факта — пара `(ticket_no, flight_id)`. ## Границы Работа ограничена документами, к которым ведет учебный маршрут, и необходимыми правками ссылок. Не превращать ее в переписывание всей истории проекта. Содержание программы, SQL, DAG, DDL, конфигурация и данные стенда не меняются. ## Критерии готовности - [x] На основном пути чтения отсутствуют неотмеченные старые планы разработки, представленные как актуальные инструкции. - [x] Руководства загрузок различают действующую реализацию и ожидаемое поведение учебных заглушек. - [x] Найденные расхождения проверены; для каждого зафиксировано исправление либо согласованное решение по требованиям. - [x] У каждого существенного правила есть основной документ, а остальные места ссылаются на него без несовместимых копий. - [x] Из заданий легко найти их самопроверку; тесты разработки и глубокая диагностика вынесены из обязательного первого чтения. - [x] Проверены внутренние ссылки, имена таблиц и файлов, команды из измененных инструкций и отсутствие изменений SQL/DAG. - [x] Повторно пройден целиком маршрут README → структура/карта → разбор SQL → первое задание → проверка результата; указано, какие шаги проверены чтением, а какие выполнены на стенде. ## Сначала прочитать Результаты двух предыдущих задач; [индекс документации](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/README.md), четыре руководства загрузок, [порядок запуска](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/dag_execution_order.md), [ТЗ](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md), действующие SQL/DAG, `docs/design/bookings_*_design.md`.
ddmitry added the needs-triage label 2026-09-20 19:07:54 +03:00
Author
Owner

Выполнено и принято: PR #7 влит в main, коммит слияния 351dbbb.

Результат

  • Руководства STG/ODS/DDS/DM описывают подготовку, действия загрузки, результат и поиск ошибок. Указано, какие загрузки и DQ уже работают, а какие нужно реализовать по ТЗ.
  • Снимки ODS описаны как TRUNCATE + INSERT; транзакционные загрузки сохраняют метки STG и отбирают дельту по HWM. Порядок задач соответствует main.
  • Календарь заполняется только при пустой таблице. Зерно факта — (ticket_no, flight_id), число строк проверяется на точное равенство с ods.segments.
  • Для dim_routes закреплено обновление описательных полей только у открытых версий. Закрытые версии сохраняют значения на момент закрытия. ТЗ, руководство и карта согласованы.
  • Самопроверка остается рядом с заданием. Проверки разработки и глубокая диагностика доступны отдельно; дизайн-планы и QA-план сохранены как история по прежним адресам.

Проверки

make lint, git diff --check и проверка сборки карты прошли. make test: 4 passed, 14 skipped — 13 smoke-тестов пропущены условием доступности Airflow в тестовом окружении, один интеграционный требует отдельного запуска.

Проверены 292 локальные ссылки в 19 документах, якоря, 40 адресов карты, имена задач, таблиц и Make-таргетов. Сборщик карты проверил 39 объектов, 90 связей и 215 ссылок. Содержимое пяти исторических документов сохранено, что подтверждено сравнением с исходной веткой.

Чтением и в Chromium через Playwright пройден маршрут README → структура/карта → разбор готового SQL → первое задание → ТЗ → самопроверка. В браузере использовались локально отрисованные Markdown и интерактивная карта; проверены сегменты билета, две роли аэропорта, модели и места, выбор связей, переключение вида и сброс. Ошибок JavaScript нет.

Граница проверки: живые загрузки Airflow/Greenplum и bookings_validate не запускались; в рабочей копии нет .env. Проверка документации и интерфейса не подменяет прогон ETL.

Изменены только 17 Markdown-файлов; SQL, DAG, DDL, конфигурация и данные стенда не менялись. Все семь критериев этой задачи выполнены.

Выполнено и принято: [PR #7](https://git.dementev.space/ddmitry/airflow-greenplum/pulls/7) влит в `main`, коммит слияния `351dbbb`. ### Результат - Руководства STG/ODS/DDS/DM описывают подготовку, действия загрузки, результат и поиск ошибок. Указано, какие загрузки и DQ уже работают, а какие нужно реализовать по ТЗ. - Снимки ODS описаны как `TRUNCATE + INSERT`; транзакционные загрузки сохраняют метки STG и отбирают дельту по HWM. Порядок задач соответствует `main`. - Календарь заполняется только при пустой таблице. Зерно факта — `(ticket_no, flight_id)`, число строк проверяется на точное равенство с `ods.segments`. - Для `dim_routes` закреплено обновление описательных полей только у открытых версий. Закрытые версии сохраняют значения на момент закрытия. ТЗ, руководство и карта согласованы. - Самопроверка остается рядом с заданием. Проверки разработки и глубокая диагностика доступны отдельно; дизайн-планы и QA-план сохранены как история по прежним адресам. ### Проверки `make lint`, `git diff --check` и проверка сборки карты прошли. `make test`: **4 passed, 14 skipped** — 13 smoke-тестов пропущены условием доступности Airflow в тестовом окружении, один интеграционный требует отдельного запуска. Проверены 292 локальные ссылки в 19 документах, якоря, 40 адресов карты, имена задач, таблиц и Make-таргетов. Сборщик карты проверил 39 объектов, 90 связей и 215 ссылок. Содержимое пяти исторических документов сохранено, что подтверждено сравнением с исходной веткой. Чтением и в Chromium через Playwright пройден маршрут README → структура/карта → разбор готового SQL → первое задание → ТЗ → самопроверка. В браузере использовались локально отрисованные Markdown и интерактивная карта; проверены сегменты билета, две роли аэропорта, модели и места, выбор связей, переключение вида и сброс. Ошибок JavaScript нет. **Граница проверки:** живые загрузки Airflow/Greenplum и `bookings_validate` не запускались; в рабочей копии нет `.env`. Проверка документации и интерфейса не подменяет прогон ETL. Изменены только 17 Markdown-файлов; SQL, DAG, DDL, конфигурация и данные стенда не менялись. Все семь критериев этой задачи выполнены.
Sign in to join this conversation.