Качество данных и инварианты: вопросы для собеседования (часть 4)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 16–20 из 20
16Агрегатная таблица показывает 100k `sessions` за день, а расчет из сырых `events` дает 70k `sessions`. Что логичнее проверить первым?
AСразу выбрать число, которое больше, потому что оно выглядит оптимистичнее
BУмножить 70k на фиксированный коэффициент, чтобы «починить» расхождение
CСверить `definition` `sessions`: правила `sessionization`, фильтры событий, `time zone` и `deduplication` на одном и том же срезе данных
DУдалить `aggregate` таблицу и считать только из сырых данных без проверки
Ответ: При `reconciliation` агрегатов и сырых данных первым делом выравнивают `definition` и правила агрегации.
Разные правила `sessionization` и фильтры могут давать большие расхождения даже при корректных данных. Часто различаются `time zone`, способы дедупликации и набор событий, которые считаются сессией. Когда определения совпали, можно искать технические причины: `missing data`, `duplicates` или ошибки в конкретном шаге пайплайна.
17В 9 утра пришел алерт: `DAU` на вчерашней дате на 20 процентов ниже, чем обычно. Какой порядок действий наиболее правильный для диагностики?
AСначала спросить менеджера, что изменилось в продукте, и только потом смотреть данные
BСразу чинить дашборд, не проверяя сырые данные и пайплайн
CСразу объявить это реальным бизнес-падением и разослать отчет без проверок
DСначала сделать `sanity check` ingestion (`row count`, `max(event_time)`), затем `reconciliation` между источниками и сегментами, затем проверить недавние изменения `instrumentation`, `logging` и `schema`
Ответ: Правильный triage начинается с `sanity check`, затем идет `reconciliation`, и только потом — анализ изменений `instrumentation` и пайплайна.
Если ingestion неполный, любая интерпретация `DAU` будет ошибочной, поэтому сначала проверяют `row count` и `max(event_time)`. Затем `reconciliation` с независимыми источниками и разрезами показывает, локальна ли проблема или системная. После этого проверяют деплои, изменения `schema` и `logging`, чтобы найти конкретную причину и оценить, какие метрики пострадали.
18Какую проверку лучше добавить как `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` ловит нарушение уникальности сразу после загрузки. Это надежнее визуальных проверок и помогает строить устойчивые пайплайны и отчеты.
19После внепланового `reprocessing` дневной объем событий вырос ровно на величину, близкую к исходному объему дня. Какой шаг лучше всего подтвердит, что причина — `duplicates`?
AПроверить, не выросли расходы на маркетинг в этот день
BПосмотреть отзывы пользователей в соцсетях и сделать вывод по ним
CИгнорировать день и сравнивать только средние за месяц
DПроверить повторяемость `event_id` и наличие кластеров по `ingest_time` около времени `reprocessing`, а также распределение по `batch_id`
Ответ: Сочетание `reprocessing` и роста повторов `event_id` — сильный индикатор `duplicates` из-за неидемпотентной загрузки.
При повторной загрузке без `idempotency` одни и те же события могут записаться второй раз. Кластеры по `ingest_time` часто указывают на повторную запись в момент `reprocessing`. Проверка по `batch_id` и уникальности `event_id` помогает локализовать источник и оценить масштаб удвоения.
20Падение `conversion rate` заметно только у сегмента новых пользователей, а у возвращающихся все стабильно. Какой шаг диагностики наиболее разумен первым?
AСразу признать, что продукт стал хуже именно для новых пользователей, и не проверять данные
BИгнорировать сегментацию и смотреть только общий график
CСделать `reconciliation` по сегменту: сверить число новых пользователей с источником регистраций, проверить корректность `assignment` в эксперимент и `instrumentation` поля `user_type`
DИсключить новых пользователей из отчета, чтобы метрика выглядела лучше
Ответ: Сегментный эффект требует `reconciliation` знаменателей и проверки `instrumentation` сегментирующих полей.
Если поле `user_type` сломалось или изменилось правило классификации, сегментная метрика может «поехать» без реального эффекта. Сверьте количество новых пользователей с независимым источником, например регистрациями, и проверьте `assignment` в эксперимент на этом же сегменте. Если знаменатель и сегментация корректны, тогда можно обсуждать реальное продуктовое влияние.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram