Качество данных и инварианты: вопросы для собеседования (часть 3)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 11–15 из 20
11Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за два дня почти не изменилась. Какая проверка лучше всего указывает на сдвиг времени?
AПосмотреть распределение событий по часам и проверить, не изменился ли часовой пояс при обработке поля `event_time`
BСравнить недельное среднее значение метрики и принять решение по нему, не разбираясь в колебаниях между соседними днями недели
CСравнить дизайн дашборда с прошлой версией: цвета линий, подписи осей и порядок легенды, не сверяя распределение событий по часам
DУдалить данные за понедельник из расчёта и пересчитать вторник без учёта недостающих наблюдений за день, отбросив сырые логи
Ответ: Для поиска сдвига времени смотрят почасовую картину и соответствие часового пояса при разборе времени.
Сдвиг границы дня приводит к переносу части событий между соседними датами, поэтому один день падает, а следующий растёт. Проверка распределения по часам часто показывает «перекос» около полуночи. Полезно сравнить `event_time` и `ingest_time`, чтобы понять, это сдвиг времени или задержка доставки данных.
Подробный разбор → 12Фронтенд-счётчик показывает 10 тысяч успешных оплат, а бэкенд-таблица заказов — 8 тысяч за тот же день. Какой следующий шаг в сверке данных наиболее полезен?
AСчитать фронтенд-счётчик источником истины и игнорировать данные бэкенда: значения на экране пользователя точнее внутренних таблиц
BСчитать бэкенд-таблицу источником истины и игнорировать фронтенд: серверные таблицы заказов выше по приоритету в сверке источников
CСопоставить записи по `order_id` и разложить расхождение по стадиям воронки: запрос, платёж, колбэк, финализация заказа
DВзять среднее арифметическое 10 тысяч и 8 тысяч как компромиссное число успешных оплат за день для итогового отчёта по дню
Ответ: Сверку лучше делать на уровне идентификаторов и этапов процесса, а не сравнивать только агрегаты.
Сопоставление по `order_id` показывает, какие заказы видны на фронте, но не дошли до финализации на бэкенде, и наоборот. Разложение по стадиям выявляет, где именно теряются события: в логировании, в очереди, в обработчике или в витрине. Это позволяет быстро отличить проблему данных от реального сбоя бизнес-процесса оплаты. Слепое доверие одному источнику или усреднение чисел маскирует баг, а не исправляет его.
Подробный разбор → 13Какое наблюдение сильнее всего говорит, что падение конверсии связано с реальным бизнес-эффектом, а не с пропусками в данных?
AПадение видно только в одном дашборде, а в сырых данных и смежных отчётах метрика держится на прежнем уровне без изменений
BПадение совпало с массовой просадкой полноты загрузки и появлением задержек по всем витринам и каналам данных в продукте
CОдновременно вырос процент `NULL` в ключевых полях таблицы событий, что сопровождает просадку основной метрики продукта
DПадение подтверждается биллингом и поддержкой как независимыми источниками, а число строк и `max(event_time)` в норме
Ответ: Подтверждение эффекта независимыми источниками при нормальных результатах проверки адекватности чаще указывает на реальный бизнес-эффект.
Если число строк и `max(event_time)` выглядят нормально, меньше шансов, что проблема в неполноте данных. Когда эффект одновременно виден в независимых системах, например в биллинге, и сопровождается сигналами из поддержки, это усиливает гипотезу бизнес-изменения. Падение в одном дашборде или в одной версии `ETL` чаще указывает на проблему с данными. Рост доли `NULL` в ключевых полях, наоборот, явный признак сбоя загрузки, а не бизнес-эффекта.
Подробный разбор → 14После обогащения отчёта справочником число строк стало сильно больше, а `DAU` в отчёте превысил `DAU` в исходной витрине событий. Что наиболее вероятно произошло?
AПользователей действительно стало больше именно после обогащения справочником, поэтому `DAU` ожидаемо вырос относительно исходной витрины событий
BНарушена уникальность ключа в справочнике: при `JOIN` каждая строка факта размножается, поэтому `DAU` искусственно превышает значение исходной витрины
CСработала сезонность, из-за которой `DAU` удваивается при добавлении справочника к исходной витрине событий любой структуры
DСправочник всегда делает метрики более точными, поэтому рост числа строк и `DAU` после `JOIN` со справочником ожидаем
Ответ: Рост числа строк после `JOIN` часто означает связь «один ко многим» и появление дубликатов из-за неуникального ключа справочника.
Если справочник содержит несколько строк на один ключ, то при `JOIN` каждая факт-строка размножается. Это ломает сопоставимость метрик до и после обогащения и может раздувать `DAU`. Проверьте уникальность ключа в справочнике и сделайте сверку числа строк до и после `JOIN`. Сезонность или «справочник всегда уточняет метрики» не объясняют рост `DAU` выше значения исходной витрины событий.
Подробный разбор → 15Вчера количество событий `checkout` стало ноль, но появилось новое событие `checkout_v2` с похожими полями. Какое действие наиболее корректно?
AСделать вывод, что пользователи перестали оформлять заказы, и сразу эскалировать падение `checkout` в команду продукта
BПроверить изменения в инструментировании событий и логировании, обновить маппинг схемы и сделать сверку между `checkout` и `checkout_v2`
CПрименить «поправочный коэффициент» к старому событию `checkout` и продолжить отчёт без проверки покрытия и без сверки данных
DУдалить новое событие `checkout_v2`, потому что новые события всегда зашумляют исторические тренды и мешают регулярной отчётности
Ответ: Когда меняется название или схема события, нужно обновлять маппинг и делать сверку, прежде чем интерпретировать тренд.
Нулевое значение старого события вместе с появлением нового часто означает смену инструментирования, а не бизнес-обвал. Сопоставьте события по ключам процесса, например `order_id`, и проверьте покрытие: какой процент старых случаев теперь живёт в `checkout_v2`. После сверки обновите правила подсчёта и только затем пересматривайте выводы по воронке. Сразу делать выводы о падении заказов, удалять новое событие или применять поправочный коэффициент без проверки — рискованно.
Подробный разбор →