Какую проверку лучше добавить как invariant, чтобы защититься от повторной загрузки одного и того же дня и появления duplicates в витрине?
AПроверять, что среднее значение метрики выглядит похоже на прошлую неделю
BПроверять уникальность
primary key в каждой partition, например count_distinct(primary_key) = row count, и требовать idempotency загрузкиCПроверять, что максимальное значение метрики не слишком большое
DПроверять, что на дашборде нет резких углов на графике
Правильный ответ. Инвариант на уникальность
primary key в partition вместе с idempotency предотвращает размножение фактов при повторных загрузках.Разбор
Если загрузка неидемпотентна, reprocessing может добавлять те же строки повторно. Проверка вида count_distinct(primary_key) = row count ловит нарушение уникальности сразу после загрузки. Это надежнее визуальных проверок и помогает строить устойчивые пайплайны и отчеты.
Проверь себя · 1/3разбор после ответа
В отчете одновременно упали почти все метрики:
sessions, events, revenue, и падение начинается ровно с 14:00. Какое наблюдение лучше всего подтверждает гипотезу missing data?Ещё вопросы по теме «Качество данных и инварианты»
- В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это `missing data` или реальный бизнес-эффект?
- Какой `invariant` наиболее уместно добавить в ежедневный отчет по воронке e-commerce, чтобы ловить ошибки данных?
- Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках `reconciliation`?
- Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
- Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за 2 дня почти не изменилась. Какой `sanity check` лучше всего указывает на `time shift`?
- Все вопросы по «Качество данных и инварианты» →