ddadmin
35144e49f6
Руководства STG/ODS/DDS/DM сверены с действующими SQL и DAG, ожидания учебных заглушек связаны с ТЗ. Самопроверка заданий отделена от проверок разработки и исторических планов. Для dim_routes закреплено обновление описательных полей только у открытых версий. SQL, DAG, DDL и настройки стенда не менялись. Проверки: make lint; make test (4 passed, 14 skipped); карта; 292 локальные ссылки; маршрут чтения и карта в Chromium. Живой ETL не запускался.
69 lines
5.1 KiB
Markdown
69 lines
5.1 KiB
Markdown
# Классы DQ-проверок
|
||
|
||
DQ-проверка должна отвечать на конкретный вопрос. В этом проекте есть три
|
||
класса. Один `*_dq.sql` может содержать проверки нескольких классов.
|
||
Сверяйте их с полями и правилами своего объекта в [ТЗ](../assignment/analyst_spec.md).
|
||
Как запустить DQ и проверить задание, описано в
|
||
[инструкции самопроверки](../assignment/README.md#запуск-и-проверка).
|
||
На `main` учебные DQ содержат `SELECT 1;` и начнут проверять данные
|
||
после вашей реализации.
|
||
|
||
## 1. Универсальные структурные проверки
|
||
|
||
Они проверяют форму таблицы: обязательные ключи заполнены, ключ уникален, а
|
||
таблица не пуста там, где по контракту ожидаются строки. Так можно быстро поймать
|
||
сломанное зерно или незавершённую загрузку без знания бизнес-смысла данных.
|
||
|
||
Реальные примеры:
|
||
|
||
- [`sql/dds/dim_airports_dq.sql`](../../sql/dds/dim_airports_dq.sql) требует
|
||
непустую таблицу, проверяет уникальность `airport_sk` и `airport_bk`, а также
|
||
обязательные поля.
|
||
- [`sql/ods/bookings_dq.sql`](../../sql/ods/bookings_dq.sql) ищет дубли
|
||
`book_ref` и `NULL` или пустые значения в обязательных полях. Пустой
|
||
инкрементальный батч здесь допустим.
|
||
- [`sql/ods/tickets_dq.sql`](../../sql/ods/tickets_dq.sql) проверяет уникальность
|
||
`ticket_no`, обязательные поля и отсутствие билетов без `bookings.book_ref`.
|
||
|
||
## 2. Проверки бизнес-правил
|
||
|
||
Они проверяют ограничения предметной области, которых не видно из структуры
|
||
таблицы. Такая проверка нужна, чтобы заметить правдоподобную по типам, но
|
||
невозможную по смыслу строку.
|
||
|
||
В [`sql/dm/sales_report_dq.sql`](../../sql/dm/sales_report_dq.sql) для дат
|
||
текущего запуска проверяется, что `tickets_sold >= passengers_boarded`,
|
||
`boarding_rate` лежит между `0` и `1`, а `total_revenue` неотрицательна.
|
||
|
||
## 3. Межслойные сверки
|
||
|
||
Они отвечают на вопрос: согласован ли слой N+1 со слоем N для нужного батча?
|
||
Сверка находит потерянные или лишние строки на границе загрузки.
|
||
|
||
Реальные примеры используют разные способы сверки:
|
||
|
||
- [`sql/ods/airports_dq.sql`](../../sql/ods/airports_dq.sql) сравнивает множества
|
||
`airport_code`: ищет пропущенные и лишние ключи относительно текущего STG-батча.
|
||
Это сверка ключей, а не простое сравнение числа строк.
|
||
- [`sql/stg/airplanes_dq.sql`](../../sql/stg/airplanes_dq.sql) сравнивает число
|
||
строк во внешней `stg.airplanes_ext` и в текущем батче `stg.airplanes`.
|
||
- [`sql/dds/fact_flight_sales_dq.sql`](../../sql/dds/fact_flight_sales_dq.sql)
|
||
требует равенства числа строк факта и `ods.segments`, потому что зерно факта —
|
||
один сегмент билета.
|
||
|
||
## `NULL` — не всегда ошибка
|
||
|
||
В [`fact_flight_sales_load.sql`](../../sql/dds/fact_flight_sales_load.sql)
|
||
измерения присоединяются через `LEFT JOIN`. Факт может прийти раньше измерения,
|
||
поэтому `route_sk`, `airplane_sk` или `passenger_sk` временно бывают `NULL`. На
|
||
ветке `main` это также ожидаемо, пока студент не реализовал эти измерения. Такой
|
||
`NULL` сохраняет строку факта и не должен сам по себе останавливать пайплайн.
|
||
|
||
`seat_no` тоже может быть `NULL`: у билета уже есть сегмент, но записи
|
||
`boarding_passes` ещё нет. Обязательный ключ, напротив, должен быть заполнен.
|
||
Например, `NULL` в `airport_sk` измерения или в `(ticket_no, flight_id)` факта
|
||
нарушает контракт таблицы.
|
||
|
||
Архитектурное решение о том, где живут DQ-проверки, зафиксировано в разделе
|
||
[«Ключевые договорённости»](../design/db_schema.md#ключевые-договорённости).
|