Как проверять, что данные из источника дошли до хранилища

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

Умеете ли вы доказать полноту и корректность загрузки цифрами, а не зелёным статусом задачи в оркестраторе. Следом спрашивают, как сверять источник, который меняется во время загрузки, и что делать с опоздавшими данными.

Как отвечать

Сначала разведите два вопроса: отработал ли пайплайн и дошли ли данные. Успешный таск в Airflow говорит только о первом, загрузка нуля строк тоже «успешна».

Каркас сверки (reconciliation):

• количество: число строк в источнике и в хранилище за одно окно, по партициям или дням. Окно фиксируйте по водяной метке (updated_at или позиция в журнале при CDC), иначе живая таблица и загруженный срез всегда разойдутся;
• контрольные суммы: сумма денежных колонок, минимум и максимум ключей и дат, число уникальных ключей. Количество совпало, а сумма нет: это искажение, а не потеря;
• поштучная сверка: анти-джойн по ключам (LEFT JOIN ... WHERE t.id IS NULL) показывает конкретные пропавшие строки; на больших объёмах сравнивают хеши строк или хеши по бакетам ключей;
• качество: уникальность ключа (дубли после повторной загрузки), not null на обязательных полях, ссылочная целостность. В dbt это тесты unique, not_null, relationships, свежесть источников проверяет dbt source freshness; для сложных правил есть Great Expectations и Soda;
• свежесть: разрыв между максимальной датой в источнике и в хранилище, алерт при превышении порога.

Загрузку делайте идемпотентной (MERGE или upsert по ключу), тогда повтор после сбоя не создаёт дублей. Опоздавшие данные закрывают перезагрузкой нескольких последних окон.

Результаты сверок пишите в отдельную таблицу и выводите на дашборд: так виден не только сбой, но и медленный дрейф.

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

Считают статус задачи доказательством. Таск прошёл, а источник отдал пустой ответ из-за истёкшего токена, и в хранилище пусто.

Сверяют только количество строк. Сдвиг часового пояса или обрезка десятичных знаков его не меняют, а отчёты уже врут.

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