Качество данных и инварианты: вопросы для собеседования (часть 3)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 11–15 из 20
11Метрики за понедельник резко просели, а за вторник резко выросли, при этом сумма за 2 дня почти не изменилась. Какой `sanity check` лучше всего указывает на `time shift`?
AПосмотреть распределение событий по часу и проверить, не изменился `time zone` в обработке `event_time`
BСравнить только недельное среднее и игнорировать дневные колебания
CПроверить, не поменяли ли дизайнеры цвета на графике
DУдалить данные за понедельник и пересчитать вторник
Ответ: Для поиска `time shift` смотрят почасовую картину и соответствие `time zone` при парсинге времени.
Сдвиг границы дня приводит к переносу части событий между соседними датами, поэтому один день падает, а следующий растет. Проверка распределения по часам часто показывает «перекос» около полуночи. Полезно сравнить `event_time` и `ingest_time`, чтобы понять, это сдвиг времени или задержка доставки.
12Фронтенд-счетчик показывает 10k успешных оплат, а бэкенд-таблица заказов — 8k за тот же день. Какой следующий шаг в `reconciliation` наиболее полезен?
AСразу решить, что фронтенд всегда прав, и игнорировать бэкенд
BСразу решить, что бэкенд всегда прав, и игнорировать фронтенд
CВзять среднее между 10k и 8k, чтобы получить компромиссное число
DСопоставить записи по `order_id` и разложить расхождение по стадиям `request`, `payment`, `callback`, `finalize`
Ответ: `reconciliation` лучше всего делать на уровне идентификаторов и этапов процесса, а не сравнивать только агрегаты.
Сопоставление по `order_id` показывает, какие заказы видны на фронте, но не дошли до финализации на бэкенде, и наоборот. Разложение по стадиям выявляет, где именно теряются события: в `logging`, в очереди, в обработчике или в витрине. Это позволяет быстро отличить проблему данных от реального сбоя бизнес-процесса оплаты.
13Какое наблюдение сильнее всего говорит, что падение `conversion rate` связано с реальным бизнес-эффектом, а не с `missing data`?
AПадение видно только в одном дашборде, а в сырых данных метрика не падала
BПадение подтверждается независимыми источниками `billing` и `support`, а `sanity check` по `row count` и `max(event_time)` не показывает провала
CПадение видно только в одной версии `ETL`, а другие отчеты не тронуты
DОдновременно вырос `null rate` в ключевых полях, значит это бизнес-эффект
Ответ: Подтверждение эффекта независимыми источниками при нормальных `sanity check` чаще указывает на реальный бизнес-эффект.
Если `row count` и `max(event_time)` выглядят нормально, меньше шансов, что проблема в неполноте данных. Когда эффект одновременно виден в независимых системах, например `billing`, и сопровождается сигналами из `support`, это усиливает гипотезу бизнес-изменения. После этого имеет смысл сегментировать эффект и проверить, не совпал ли он с продуктовым релизом или изменением политики.
14После обогащения отчета справочником число строк стало сильно больше, а `DAU` в отчете превысил `DAU` в исходной витрине событий. Что наиболее вероятно произошло?
AПользователей действительно стало больше именно после обогащения справочником
BСработала сезонность, из-за которой `DAU` удваивается при добавлении справочника
CНарушена уникальность `primary key` в справочнике, поэтому `join` стал `one-to-many` и породил `duplicates`
DСправочник всегда делает метрики более точными, поэтому рост `DAU` ожидаем
Ответ: Рост количества строк после `join` часто означает `one-to-many` и появление `duplicates` из-за неуникального ключа.
Если справочник содержит несколько строк на один `primary key`, то при `join` каждая факт-строка размножается. Это ломает `invariant` сопоставимости метрик до и после обогащения и может раздувать `DAU`. Проверьте уникальность ключа в справочнике и сделайте `reconciliation` количества строк до и после `join`.
15Вчера количество событий `checkout` стало ноль, но появилось новое событие `checkout_v2` с похожими полями. Какое действие наиболее корректно?
AСделать вывод, что пользователи перестали оформлять заказы
BУдалить `checkout_v2`, потому что новое событие всегда шум
CПрименить «поправочный коэффициент» и продолжить отчет без проверки
DПроверить изменения `instrumentation` и `logging`, обновить `schema` маппинг и сделать `reconciliation` между `checkout` и `checkout_v2`
Ответ: Когда меняется название или схема события, нужно обновлять `schema` и делать `reconciliation`, прежде чем интерпретировать тренд.
Нулевое значение старого события вместе с появлением нового часто означает смену `instrumentation`, а не бизнес-обвал. Сопоставьте события по ключам процесса, например `order_id`, и проверьте покрытие: какой процент старых кейсов теперь живет в `checkout_v2`. После `reconciliation` обновите правила подсчета и только затем пересматривайте выводы по воронке.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram