Как отслеживать полноту загрузки данных

Что проверяют

Понимаете ли вы, что успешно завершившийся DAG не означает полные данные. Интервьюер хочет услышать конкретные проверки, с чем вы сравниваете и что делаете с запоздавшими данными. Следом часто спрашивают, как отличить реальное падение трафика от потери данных.

Как отвечать

Опишите слои проверок:

• сверка количества: число строк в источнике и в хранилище, но по партициям (день, час, источник), а не одной цифрой на всю таблицу. Результат пишется в аудит-таблицу: load_id, партиция, source_count, target_count, статус;
• контрольные суммы: сумма денежной колонки, число уникальных ключей, хэш от отсортированных ключей партиции. Счётчик строк не видит, когда потери перекрыты дублями;
• полнота партиций: все ли часы за сутки на месте, нет ли дыр;
• свежесть: max(event_time) и отставание от текущего времени. В dbt это dbt source freshness с loaded_at_field, для стриминга отставание потребителей Kafka или позиция CDC;
• исторический объём: сравнение с тем же днём прошлой недели или со скользящим средним, порог с учётом сезонности. Так ловятся тихие потери, когда источник сам отдал меньше и сверка с ним совпала;
• поздние данные: разделять время события и время загрузки, перепроверять партицию через N часов, догружать окно назад;
• инструменты: тесты dbt (not_null, unique, relationships), Great Expectations или Soda, проверки отдельными задачами Airflow, которые валят DAG и шлют алерт.

Хорошо сказать, кто получает алерт и что происходит дальше: блокируются ли витрины ниже по потоку, пока проверка красная.

Где спотыкаются

Доверяют статусу задачи. Загрузка нуля строк тоже завершается успешно.

Сравнивают общий счётчик за всё время. Потеря одного дня тонет в миллионах строк, а дубли в другой партиции её компенсируют.

Путают часовые пояса: источник режет сутки по местному времени, хранилище по UTC, и сверка по дню стабильно расходится на несколько процентов, к чему все привыкают и перестают смотреть.