Руководства STG/ODS/DDS/DM сверены с действующими SQL и DAG, ожидания учебных заглушек связаны с ТЗ. Самопроверка заданий отделена от проверок разработки и исторических планов. Для dim_routes закреплено обновление описательных полей только у открытых версий. SQL, DAG, DDL и настройки стенда не менялись. Проверки: make lint; make test (4 passed, 14 skipped); карта; 292 локальные ссылки; маршрут чтения и карта в Chromium. Живой ETL не запускался.
7.1 KiB
Проверка изменений репозитория
Этот документ предназначен для работы над кодом, документацией и стендом.
Если вы выполняете учебное задание, начните с
его самопроверки: там объяснены
*_dq.sql, группы bookings_validate и порядок восстановления после SCD2-теста.
Локальные проверки
Из корня репозитория:
uv sync
make lint
make test
make lint проверяет Black и isort для airflow/ и tests/.
make fmt исправляет форматирование в этих каталогах.
Тесты находятся в трех файлах:
- test_ods_sql_contract.py проверяет контракты SQL справочников ODS по исходным файлам.
- test_dags_smoke.py проверяет структуру DAG.
Если импорт
airflowне предоставляетDAG, проверки пропускаются. Смотрите причины пропусков:uv run pytest -q -rs. - test_ods_snapshot_integration.py по умолчанию пропускается; отдельный запуск описан ниже.
Успешный pytest с пропущенными smoke-тестами не подтверждает работоспособность DAG в Airflow. Число выполненных и пропущенных тестов указывайте в отчете.
Для документации проверьте относительные ссылки и якоря, имена файлов, таблиц и задач. Для карты выполните:
uv run docs/design/architecture-map/render.py --check
git diff --check
Сборщик сверяет карту с DDL, загрузками и ссылками. Действия в браузере проверяются отдельно по чек-листу карты.
Проверка на стенде
Подготовьте стенд по README и проверьте его состояние:
make up
docker compose ps
Порты берутся из .env: AIRFLOW_WEB_PORT, GP_HOST_PORT, BOOKINGS_DB_PORT.
Для локальных подключений используйте их, а для Greenplum внутри Docker-сети
применяется GP_PORT (по умолчанию 5432).
Загрузки используют Airflow Connections из Compose;
подробности находятся в справочнике стенда.
Если изменились Dockerfile.airflow или airflow/requirements.txt, перед
make up выполните make build. Инициализация Bookings нужна при создании
стенда: make bookings-init пересоздает исходную базу из seed-дампа.
Не используйте ее для обычной проверки SQL на существующих данных.
Выполните DDL и загрузки по порядку DAG.
В Airflow откройте Graph и Log задач измененного слоя; в Greenplum
(make gp-psql) выполните проверки из его руководства:
STG,
ODS,
DDS,
DM.
Для проверки чтения через PXF используйте действующую внешнюю таблицу:
SELECT COUNT(*) FROM stg.bookings_ext;
SELECT * FROM stg.bookings_ext LIMIT 5;
Сравнить источник можно через make bookings-psql.
При ошибке соединения начните с docker compose ps и логов нужного сервиса,
затем проверьте настройки из docs/stack.md.
Дополнительные прогоны
Интеграционный тест снимка ODS требует работающего Greenplum и базы gp_dwh:
RUN_ODS_INTEGRATION=1 uv run pytest -q tests/test_ods_snapshot_integration.py
Он создает, затем удаляет служебные таблицы
public.it_stg_airports_ods и public.it_ods_airports_ods.
Используйте тестовый стенд, где эти имена не заняты нужными данными.
Тест проверяет замену снимка, преобразование названий и DQ готового airports;
задания airplanes и seats он не проверяет.
make e2e-etl запускает DDL и два прохода STG → ODS → DDS → DM через API Airflow.
Скрипт использует localhost:8080; при другом AIRFLOW_WEB_PORT проходите
цепочку вручную. Каждый STG добавляет учебный день. Финальные SQL выводят
счетчики, но не превращают все неверные значения в ошибку завершения скрипта:
результаты нужно прочитать с учетом заглушек main.
make e2e-smoke начинает с make clean и удаляет все Docker-тома стенда,
затем инициализирует Bookings и выполняет E2E. Запускайте его только там,
где данные можно потерять. Обычный make down сохраняет тома;
make stop, затем make up подходят для перезапуска с сохранением данных.
Исторический QA-план сохраняет многодневные, негативные и граничные сценарии полной реализации. Это материал для подготовки отдельной диагностики: перед выполнением сверяйте его SQL с текущей веткой и учитывайте операции очистки данных.
Что указать в отчете
Укажите коммит, команды и результаты, включая пропуски тестов. Разделите чтение исходников, проверки ссылок, действия в браузере и реальные загрузки. Для запуска на стенде сохраните Run ID и логи проверенных задач. Если ETL или интерфейс не проверялись, укажите это прямо.