- Зачем: - формализация проверки всей цепочки ETL (STG -> ODS -> DDS -> DM). - Что: - создан docs/e2e-etl-test-protocol.md и sql/truncate_gp.sql. - в Makefile добавлена команда dwh-truncate. - start_date во всех DAG изменен на 2017-01-01. - Проверка: - выполнение make dwh-truncate и прогон DAG.
4.6 KiB
4.6 KiB
Протокол сквозного (E2E) тестирования ETL
Этот документ описывает процедуру полной проверки цепочки ETL: STG -> ODS -> DDS -> DM.
Цель теста — убедиться в корректности инкрементальной загрузки, работы паттерна Temporary Table и механизмов HWM.
1. Подготовка окружения
Убедитесь, что все сервисы запущены и DDL применен.
make up
make bookings-init
make ddl-gp
Важно: Настройка дат
Для корректного тестирования исторических данных из demodb (начинаются с 2017 года), убедитесь, что в DAG-файлах start_date установлен в 2017-01-01.
2. Очистка данных (Reset)
Перед началом теста необходимо полностью очистить все слои DWH.
make dwh-truncate
3. Этап 1: Загрузка за первый день (2017-01-01)
Выполните последовательный запуск всех DAG для первой порции данных.
# Загрузка в STG (создает первый батч в источнике)
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_stage 2017-01-01
# Загрузка в ODS (Initial Load)
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_ods 2017-01-01
# Загрузка в DDS (Initial Load)
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_dds 2017-01-01
# Загрузка в DM (Initial Load витрины)
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_dm 2017-01-01
Ожидаемые результаты (Day 1)
Проверьте наполнение таблиц:
stg.bookingsиods.bookingsдолжны иметь одинаковое количество строк (>0).dm.sales_reportдолжна содержать агрегированные данные за первый день.
4. Этап 2: Проверка инкремента (2017-01-02)
Эмулируйте появление данных за второй день и проверьте дозагрузку.
# Генерация данных за 2-й день в базе-источнике
make bookings-generate-day
# Повторный запуск цепочки ETL
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_stage 2017-01-02
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_ods 2017-01-02
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_dds 2017-01-02
docker compose exec airflow-scheduler airflow dags test bookings_to_gp_dm 2017-01-02
5. Финальная верификация (Критерии успеха)
Выполните SQL-запрос для сверки данных:
make gp-psql -c "
SELECT 'STG' as layer, COUNT(*) FROM stg.bookings
UNION ALL
SELECT 'ODS' as layer, COUNT(*) FROM ods.bookings
UNION ALL
SELECT 'DDS' as layer, COUNT(*) FROM dds.fact_flight_sales
UNION ALL
SELECT 'DM ' as layer, COUNT(*) FROM dm.sales_report;
"
Критерии корректности:
- STG == ODS: Количество строк в
stg.bookingsиods.bookingsсовпадает (т.к. это SCD1 UPSERT). - Инкремент STG: Количество строк в
stg.bookingsпосле Day 2 больше, чем после Day 1. - Инкремент ODS (Temporary Table): В ODS нет дублей.
SELECT book_ref FROM ods.bookings GROUP BY book_ref HAVING COUNT(*) > 1должен вернуть 0 строк. - HWM в DM: Витрина
sales_reportсодержит данные за оба дня. ЗначениеCOUNT(*)после Day 2 должно вырасти по сравнению с Day 1. - Lineage: Поля
_load_idи_load_tsво всех слоях содержат метки соответствующих запусков.
Типичные ошибки
- Пустые таблицы: Проверьте, что в
bookings-dbесть данные (SELECT COUNT(*) FROM bookings.bookings). Если 0 — сделайтеmake bookings-init. - Пропуски в ODS: Убедитесь, что
stg_batch_idв ODS корректно вычисляется (задачаresolve_stg_batch_id). - Дубли в DDS: Проверьте логику генерации SK в
dds/*_load.sql.