Backfill после 6-часового даунтайма источника задвоил выручку в витрине

Ситуация: Источник платежей лежал 6 часов, пайплайн пропустил 3 окна загрузки. После ручного backfill дневная выручка в витрине стала на 31% выше боевой: часть строк задвоилась, часть смешалась со свежими данными.

Нужно безопасно восстановить пропущенные данные без двойного счёта, проверить идемпотентность загрузки и зафиксировать процесс backfill, который не ломает уже корректные партиции. Загрузка идёт почасовыми батчами в payments_stg, затем merge в payments_fact.

Доступные данные

• payments_stg: payment_id, user_id, amount, paid_at, load_batch_id, loaded_at
• payments_fact: payment_id, user_id, amount, paid_at, dt, surrogate_load_id
• load_batches: batch_id, window_start, window_end, status, rows_loaded, is_backfill
• source_payments: payment_id, user_id, amount, paid_at, updated_at
• mart_revenue_hourly: dt, hr, payments_cnt, revenue, built_at

Задачи

• Найти дубли в payments_fact по payment_id и определить, какие пришли из backfill-батчей (is_backfill).
• Сверить число платежей и сумму по источнику vs витрина по затронутым часам, локализовать окна задвоения.
• Проверить идемпотентность: загрузка использует append вместо merge/upsert по ключу — отсюда дубли при повторном проигрывании окна.
• Спроектировать безопасный backfill: дедуп по payment_id, перекрытие окон с overlap, перестроение только затронутых партиций.
• Описать guardrails: уникальный констрейнт, reconciliation-проверка до публикации, idempotent merge-ключ.

Все кейсы для подготовки → ← Все кейсы