Вопросы по теме «Качество данных и инварианты»
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1В ежедневном дашборде `DAU` и количество событий резко упали начиная с 02:00 и остаются низкими до конца дня. Что проверить первым, чтобы быстро понять, это `missing data` или реальный бизнес-эффект?
AСделать `sanity check` полноты: сравнить почасовой `row count` и `max(event_time)` с предыдущими днями
BСразу написать в поддержку и попросить объяснить падение
CНемедленно откатить все релизы за последние сутки без анализа данных
DСменить метрику в дашборде на другую, чтобы график выглядел стабильнее
Ответ: Первым делом делают базовый `sanity check` на полноту логов и корректность временных меток.
Резкий обрыв ровно с конкретного часа часто указывает на сбой `logging` или ingestion. Проверка `row count` по часам и `max(event_time)` быстро показывает, что данные перестали поступать или начали отставать. Если в сырых данных тоже виден провал, это сильный сигнал `missing data`, а не бизнес-изменений.
2Какой `invariant` наиболее уместно добавить в ежедневный отчет по воронке e-commerce, чтобы ловить ошибки данных?
AСредний чек должен быть одинаковым каждый день
B`orders` ≤ `checkouts` ≤ `add_to_cart` ≤ `product_views` по одному и тому же окну времени
CДоля iOS-трафика должна всегда быть ровно 50 процентов
DВыручка должна быть целым числом без копеек
Ответ: Логические отношения между шагами воронки — сильный `invariant` для поиска багов.
Количество пользователей или событий на более позднем шаге не должно превышать предыдущий шаг, если определения согласованы. Нарушение такого `invariant` часто означает `duplicates`, неверную дедупликацию или смешение окон времени. Это быстрый способ поймать ошибки еще до интерпретации результата эксперимента или отчета.
3В отчете одновременно упали почти все метрики: `sessions`, `events`, `revenue`, и падение начинается ровно с 14:00. Какое наблюдение лучше всего подтверждает гипотезу `missing data`?
AПадение совпало с выходными, значит это точно сезонность
BПадение есть только у одного канала трафика, а остальные стабильны
CВ сырых данных почасовой `row count` резко становится близким к нулю после 14:00 и не восстанавливается
DСредний чек вырос, значит данные точно корректны
Ответ: Резкий «обрыв» `row count` в сырых логах в конкретный час — характерный признак `missing data`.
Системные сбои ingestion или `pipeline` часто дают ступеньку в определенный момент времени. Сравните `row count` и `max(event_time)` по часам с контрольными днями и проверьте мониторинги доставки. Если провал есть в сырых данных, дальнейшая статистика по бизнес-эффектам до восстановления данных будет некорректной.
4Вы подозреваете `duplicates` в событиях из-за ретраев. Какой `sanity check` самый прямой?
AПосчитать долю повторов `event_id`: `count(event_id) / count_distinct(event_id)` и проверить, выросла ли она
BПосмотреть только сумму выручки и игнорировать количество событий
CСравнить только недельное среднее и не анализировать распределения
DПерезаписать таблицу без проверки уникальности, чтобы «обновить данные»
Ответ: Проверка уникальности `event_id` напрямую ловит `duplicates` и дает понятный сигнал качества.
Если `event_id` должен быть уникальным, то отношение `count(event_id) / count_distinct(event_id)` должно быть близко к 1. Рост этого показателя означает массовые повторы, часто из-за ретраев или повторной обработки. Далее полезно посмотреть, одинаков ли payload у дублей и есть ли кластеры по `ingest_time`.
5Какой `sanity check` наиболее полезен, чтобы поймать «тихую» неполную загрузку дневной `partition`, когда данные частично не приехали?
AПроверять `row count > 0` и что `max(event_time)` попадает в ожидаемый конец дня для каждой `partition`
BПроверять только среднее значение метрики за неделю и игнорировать дни
CПроверять, что график выглядит гладким на дашборде без числовых проверок
DВыбирать случайные 10 строк и считать, что этого достаточно для качества
Ответ: Проверки `row count` и `max(event_time)` на уровне `partition` помогают быстро выявить неполноту загрузки.
Частичная загрузка может не обнулить данные полностью, но сдвинет объем и конец временного окна. Если `max(event_time)` неожиданно ранний, это сигнал, что хвост дня не приехал, а если `row count` резко меньше нормы, вероятно `missing data`. Такие `sanity check` хорошо автоматизируются и дают быстрые алерты.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram