Какую проверку лучше добавить как защитный инвариант, чтобы защититься от повторной загрузки одного и того же дня и появления дублей в витрине?

AПроверять, что avg(metric) за день выглядит похоже на прошлую неделю и не сильно отклоняется от привычного диапазона значений по выборке.
BПроверять уникальность первичного ключа в каждой партиции условием count_distinct(primary_key) = count(*) и требовать идемпотентности загрузки.
CПроверять, что max(metric) не превышает заранее заданный порог и в данных не появляется аномально больших чисел за обработанный день.
DПроверять визуально, что на дашборде нет резких углов на графике metric и линия выглядит непрерывной без подозрительных скачков вверх.
Правильный ответ. Инвариант на уникальность первичного ключа в партиции вместе с идемпотентностью загрузки предотвращает размножение фактов при повторных запусках.

Разбор

Если загрузка не идемпотентна, повторный запуск может добавлять те же строки заново. Условие count_distinct(primary_key) = count(*) ловит нарушение уникальности сразу после загрузки, до того как ошибка попадёт в отчёты. Это надёжнее визуальных проверок и проверок диапазона, потому что прямо описывает требование к данным. Такие инварианты помогают строить устойчивые пайплайны и доверять цифрам в витрине.

Проверь себя · 1/2разбор после ответа
Каждый день в отчёте последние 2 часа выглядят как ноль событий, но на следующий день эти часы «дозаполняются». Какое объяснение наиболее вероятно?
Открыть Карьерник в Telegram

Ещё вопросы по теме «Качество данных и инварианты»