Качество данных и инварианты: вопросы для собеседования (часть 2)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 6–10 из 20
6Каждый день в отчете последние 2 часа выглядят как ноль событий, но на следующий день эти часы «дозаполняются». Какое объяснение наиболее вероятно?
AЭто `time shift`, потому что время всегда сдвигается на 2 часа ровно
BЭто `late arrivals` из-за батчевой доставки или задержки ingestion, и события приходят с лагом по `ingest_time`
CЭто `duplicates`, потому что нули всегда означают дубликаты
DЭто реальный бизнес-эффект, потому что пользователи прекращают активность строго за 2 часа до полуночи
Ответ: Регулярный «провал хвоста» дня чаще всего означает `late arrivals`, а не изменение поведения пользователей.
Если данные догружаются позже, то отчеты на свежем срезе будут недосчитывать последние часы. Сравните `event_time` и `ingest_time`, чтобы оценить лаг доставки и настроить `watermark` или задержку публикации витрины. Важно учитывать это в `sanity check`, чтобы не принимать задержку данных за бизнес-падение.
7В отчете по странам доля `unknown` резко выросла до 40 процентов, и региональные метрики стали «прыгать». Что проверить первым?
AПокрытие ключа `country_id`: рост `null rate` после `join` и появление новых кодов, которых нет в справочнике
BСчитать, что пользователи массово переехали и страна перестала определяться
CИгнорировать `unknown`, потому что он всегда шум в данных
DПоменять группировку на континенты, чтобы скрыть проблему
Ответ: Резкий рост `null rate` после `join` обычно указывает на проблемы ключей или `missing data` в справочнике.
Причина может быть в рассинхронизации справочника, смене формата `country_id` или появлении новых значений без обновления витрины. Сделайте `reconciliation` покрытия: какая доля фактов не находит матч в справочнике и как это изменилось относительно контроля. После этого проверяют обновления `schema` и расписание загрузки справочника.
8После релиза приложения количество событий `add_to_cart` из Android стало почти ноль, а iOS и web без изменений. Что вероятнее всего проверить первым?
AСезонность спроса на товары, потому что Android-пользователи покупают только по будням
BИзменения `instrumentation` или `logging` в Android `sdk` и схеме события `add_to_cart`
CДанные платежного провайдера, потому что покупки могли остановиться
DСлучайные флуктуации, потому что любой график иногда падает к нулю
Ответ: Падение только на одной платформе чаще всего связано с `instrumentation` и корректностью `logging` на этой платформе.
Реальные бизнес-изменения обычно затрагивают несколько платформ, если продукт один и тот же. Проверьте rollout версий, ошибки в `sdk`, изменения имен полей и условий отправки события. Также полезно сделать `reconciliation` по версиям приложения и убедиться, что событие исчезло именно после релиза.
9Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платежной системе за тот же день. Что логичнее всего проверить первым в рамках `reconciliation`?
AСразу пересчитать отчет за месяц, потому что один день не важен
BПроверить, не сломалась визуализация на дашборде
CСверить `definition` и окна: `gross` или `net`, учет `refunds`, валюта и `time zone` отсечения дня
DУдалить часть записей из платежной системы, чтобы цифры совпали
Ответ: Перед поиском багов нужно выровнять `definition` метрики и правила отсечения периода между источниками.
Расхождения часто возникают из-за разных правил: учитывать ли `refunds`, какой момент считать выручкой, и в каком `time zone` закрывается день. Еще одна частая причина — различие между `gross` и `net` или разные фильтры статусов. Если определения совпали, следующий шаг — `reconciliation` на уровне идентификаторов, например сопоставление по `order_id`.
10Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
AРеальный рост продаж без увеличения количества заказов
BСбой в платежной системе, из-за которого платежи считаются дважды в банке
CОшибка округления выручки при конвертации валют
DПоявились `duplicates` из-за повторной отправки события или ретраев в `logging`
Ответ: Если уникальных ключей не стало больше, а событий стало больше, это типичный признак `duplicates`.
При повторной доставке событие может записаться несколько раз, особенно при `at-least-once delivery` и ретраях. Проверяйте уникальность `event_id` и повторяемость `order_id` с одинаковыми атрибутами. Исправления обычно включают `deduplication` и `idempotency` на стороне приемника или пайплайна.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram