Каждый день в отчете последние 2 часа выглядят как ноль событий, но на следующий день эти часы «дозаполняются». Какое объяснение наиболее вероятно?
AЭто
time shift, потому что время всегда сдвигается на 2 часа ровноBЭто
late arrivals из-за батчевой доставки или задержки ingestion, и события приходят с лагом по ingest_timeCЭто
duplicates, потому что нули всегда означают дубликатыDЭто реальный бизнес-эффект, потому что пользователи прекращают активность строго за 2 часа до полуночи
Правильный ответ. Регулярный «провал хвоста» дня чаще всего означает
late arrivals, а не изменение поведения пользователей.Разбор
Если данные догружаются позже, то отчеты на свежем срезе будут недосчитывать последние часы. Сравните event_time и ingest_time, чтобы оценить лаг доставки и настроить watermark или задержку публикации витрины. Важно учитывать это в sanity check, чтобы не принимать задержку данных за бизнес-падение.
Проверь себя · 1/3разбор после ответа
Какой
sanity check наиболее полезен, чтобы поймать «тихую» неполную загрузку дневной partition, когда данные частично не приехали?Ещё вопросы по теме «Качество данных и инварианты»
- В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это `missing data` или реальный бизнес-эффект?
- Какой `invariant` наиболее уместно добавить в ежедневный отчет по воронке e-commerce, чтобы ловить ошибки данных?
- Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках `reconciliation`?
- Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
- Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за 2 дня почти не изменилась. Какой `sanity check` лучше всего указывает на `time shift`?
- Все вопросы по «Качество данных и инварианты» →