Качество данных и инварианты: вопросы для собеседования (часть 2)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 6–10 из 20
6Каждый день в отчёте последние 2 часа выглядят как ноль событий, но на следующий день эти часы «дозаполняются». Какое объяснение наиболее вероятно?
AЗапаздывающие данные из-за пакетной доставки или задержки загрузки: события приходят с лагом
BСдвиг времени на два часа между часами пользовательских устройств и серверного времени
CРегулярные дубликаты от повторной загрузки одних и тех же событий в хвосте дня
DРеальное падение активности пользователей за два часа до полуночи как бизнес-эффект
Ответ: Регулярный «провал хвоста» дня чаще всего означает запаздывающие данные, а не изменение поведения пользователей.
Если данные догружаются позже, отчёты на свежем срезе будут недосчитывать последние часы. Сравните `event_time` и `ingest_time`, чтобы оценить лаг доставки и настроить `watermark` или задержку публикации витрины. Регулярный «провал хвоста» дня — типичный признак запаздывающих данных, а не сдвига часовых поясов или поведения пользователей. Важно учитывать это при проверке согласованности отчётов, чтобы не принимать задержку за бизнес-падение.
Подробный разбор → 7В отчёте по странам доля сегмента `unknown` резко выросла до 40 процентов, и региональные метрики стали «прыгать». Что проверить первым?
AСегмент `unknown` отражает реальное географическое смещение аудитории: пользователи переехали и страна перестала определяться
BСегмент `unknown` стоит игнорировать в отчёте и не учитывать его при принятии решений по региональным метрикам
CПокрытие ключа `country_id`: рост доли `NULL` после `JOIN` со справочником и появление новых кодов вне справочника витрины
DЗамена группировки на континенты вместо `country_id`: новый разрез сглаживает скачок и стабилизирует доли в отчёте
Ответ: Резкий рост доли `NULL` после `JOIN` обычно указывает на проблемы ключей или пропусков в справочнике.
Причина может быть в рассинхронизации справочника, смене формата `country_id` или появлении новых значений без обновления витрины. Сделайте сверку покрытия: какая доля фактов не находит совпадение в справочнике и как это изменилось относительно контрольного периода. После этого проверяют обновления схемы и расписание загрузки справочника. Версии «пользователи переехали», «`unknown` всегда шум» или «давайте скроем за группировкой по континентам» уводят от настоящей причины и закрепляют поломку.
Подробный разбор → 8После релиза приложения количество событий `add_to_cart` на Android стало почти нулевым, а на iOS и web без изменений. Что вероятнее всего проверить первым?
AСезонность спроса: пользователи Android могли заметно реже добавлять товары в корзину именно в дни сразу после релиза приложения
BДанные платёжного провайдера: цепочка покупок могла остановиться в день релиза, и события корзины перестали отправляться вместе
CИзменения инструментирования событий или логирования в SDK на Android и схеме события `add_to_cart` после релиза новой версии
DСлучайные флуктуации трафика: график одного события на одной платформе иногда падает почти к нулю и затем сам возвращается
Ответ: Падение только на одной платформе чаще всего связано с инструментированием событий и корректностью логирования на этой платформе.
Реальные бизнес-изменения обычно затрагивают несколько платформ, если продукт один и тот же. Проверьте раскатку версий, ошибки в SDK, изменения имён полей и условий отправки события `add_to_cart`. Также полезно сделать сверку по версиям приложения и убедиться, что событие исчезло именно после релиза. Версии про сезонность только на Android, проблемы платёжного провайдера или случайные флуктуации не объясняют, почему iOS и web остались без изменений.
Подробный разбор → 9Выручка по событиям в продуктовой витрине на 5 процентов выше, чем в платёжной системе за тот же день. Что логичнее всего проверить первым в рамках сверки данных?
AПересчитать отчёт за весь месяц по обеим системам и принять решение по итоговой сумме, не разбираясь в причине дневного расхождения
BПроверить корректность визуализации на дашборде и подтягивание данных в инструмент отчётности, не сверяя определения и окна расчёта
CСверить определения и окна расчёта: брутто или нетто, учёт возвратов, валюту и часовой пояс отсечения дня в обеих системах
DУдалить часть записей из платёжной системы, чтобы цифры в источниках совпали и продуктовая витрина выглядела согласованно
Ответ: Перед поиском багов нужно выровнять определения метрики и правила отсечения периода между источниками.
Расхождения часто возникают из-за разных правил: учитывать ли возвраты, какой момент считать выручкой и в каком часовом поясе закрывается день. Ещё одна частая причина — различие между брутто и нетто или разные фильтры статусов оплаты. Если определения совпали, следующий шаг — сверка на уровне идентификаторов, например сопоставление по `order_id`. Удалять данные ради совпадения цифр — категорически нельзя.
Подробный разбор → 10Вчера число событий `purchase` выросло в 2 раза, но число уникальных `order_id` почти не изменилось. Какой источник проблемы наиболее вероятен?
AПоявились дубликаты событий из-за повторной отправки или ретраев в системе сбора и доставки логов
BРеальный рост продаж без увеличения количества заказов из-за изменения средней корзины пользователей
CСбой в платёжной системе, из-за которого платежи списываются дважды на стороне банка-эквайера
DОшибка округления выручки при конвертации валют, которая удвоила число строк в таблице событий
Ответ: Если уникальных ключей не стало больше, а событий стало больше, это типичный признак дубликатов в логах.
При повторной доставке событие может записаться несколько раз, особенно при доставке «не менее одного раза» и автоматических ретраях. Проверяйте уникальность `event_id` и повторяемость `order_id` с одинаковыми атрибутами. Исправления обычно включают дедупликацию и идемпотентность на стороне приёмника или конвейера данных. Реальный рост продаж без роста заказов или ошибка округления валют не объясняют двукратный скачок числа событий.
Подробный разбор →