Качество данных и инварианты: вопросы для собеседования (часть 4)
Дубликаты, пропуски, нарушенные инварианты, расхождения между таблицами — проблемы качества данных, с которыми аналитик сталкивается ежедневно. На собеседовании дают датасет с ошибками и просят найти их. Умение быстро обнаружить проблему в данных экономит часы работы и защищает от ложных выводов.
Вопросы 16–20 из 20
16Агрегатная таблица показывает 100k сессий за день, а расчёт из сырых событий даёт 70k. Что логичнее проверить первым?
AВыбрать большее число для отчёта стейкхолдерам: показатель в 100k выглядит оптимистичнее текущей цифры
BУдалить агрегатную таблицу и оставить расчёт только из сырых данных без сверки правил агрегации и фильтрации
CУмножить значение из сырых данных на корректирующий коэффициент для выравнивания расхождения между источниками
DСверить определения сессии: правила сессионизации, фильтры событий, часовой пояс и дедупликацию на одном срезе данных
Ответ: При сверке агрегатов и сырых данных первым делом выравнивают определение сессии и правила агрегации.
Разные правила сессионизации и фильтры могут давать большие расхождения даже при корректных данных. Часто различаются часовой пояс, способы дедупликации и набор событий, которые считаются сессией. Когда определения совпали, можно искать технические причины: пропуски, дубликаты или ошибки в конкретном шаге пайплайна. Прыгать к умножению на коэффициент или удалять агрегат до сверки определений — путь к новым ошибкам.
Подробный разбор → 17В 9 утра пришёл алерт: `DAU` за вчера на 20% ниже обычного. Какой порядок действий наиболее правильный для диагностики?
AСразу починить дашборд и пересобрать витрины событий, не проверяя сырые таблицы, `row_count` и `max(event_time)` по источникам загрузки
BПроверить полноту загрузки (`row_count`, `max(event_time)`), затем сверить значения между источниками и разрезами, и только потом смотреть изменения в схеме и логах
CСразу объявить это реальным падением бизнеса и разослать отчёт стейкхолдерам, не сверяя `row_count` и `max(event_time)` источников
DСпросить у продакт-менеджера, что менялось в продукте, и принять его версию без проверки таблиц `events`, `row_count` и логов
Ответ: Правильная диагностика начинается с проверки полноты загрузки данных, затем сверка между источниками, и только потом — анализ изменений в инструментировании и пайплайне.
Если загрузка данных неполная, любая интерпретация `DAU` будет ошибочной — поэтому сначала проверяют `row_count` и `max(event_time)`. Затем сверка с независимыми источниками и в разрезах показывает, локальна проблема или системная. После этого смотрят деплои, изменения схемы и логов, чтобы найти конкретную причину. Прыгать в починку дашборда или объявлять падение бизнеса до этих шагов — типичные ошибки.
Подробный разбор → 18Какую проверку лучше добавить как защитный инвариант, чтобы защититься от повторной загрузки одного и того же дня и появления дублей в витрине?
AПроверять, что `avg(metric)` за день выглядит похоже на прошлую неделю и не сильно отклоняется от привычного диапазона значений по выборке.
BПроверять уникальность первичного ключа в каждой партиции условием `count_distinct(primary_key) = count(*)` и требовать идемпотентности загрузки.
CПроверять, что `max(metric)` не превышает заранее заданный порог и в данных не появляется аномально больших чисел за обработанный день.
DПроверять визуально, что на дашборде нет резких углов на графике `metric` и линия выглядит непрерывной без подозрительных скачков вверх.
Ответ: Инвариант на уникальность первичного ключа в партиции вместе с идемпотентностью загрузки предотвращает размножение фактов при повторных запусках.
Если загрузка не идемпотентна, повторный запуск может добавлять те же строки заново. Условие `count_distinct(primary_key) = count(*)` ловит нарушение уникальности сразу после загрузки, до того как ошибка попадёт в отчёты. Это надёжнее визуальных проверок и проверок диапазона, потому что прямо описывает требование к данным. Такие инварианты помогают строить устойчивые пайплайны и доверять цифрам в витрине.
Подробный разбор → 19После внеплановой перезагрузки данных дневной объём событий вырос ровно на величину, близкую к исходному объёму дня. Какой шаг лучше всего подтвердит, что причина — дубли?
AСравнение дневных сумм по витринам и фиксация дублей по факту удвоения строк без анализа `event_id` и `ingest_time`
BПроверка повторов `event_id`, кластеров по `ingest_time` около времени перезагрузки и распределения `batch_id`
CАнализ упоминаний продукта в соцсетях за день и трактовка скачка `events` как органической реакции аудитории
DСверка расходов на маркетинг и трактовка скачка `events` как органического роста при стабильном бюджете
Ответ: Сочетание перезагрузки и роста повторов `event_id` — сильный индикатор дублей из-за неидемпотентной загрузки.
При повторной загрузке без идемпотентности одни и те же события могут записаться второй раз. Кластеры по `ingest_time` часто указывают на повторную запись в момент перезагрузки. Проверка по `batch_id` и уникальности `event_id` помогает локализовать источник и оценить масштаб удвоения. Сравнение только итоговых сумм или анализ маркетингового бюджета не отделяют дубли от настоящего скачка трафика, а соцсети не дают такой телеметрии в принципе.
Подробный разбор → 20Падение конверсии заметно только у сегмента новых пользователей, а у возвращающихся всё стабильно. Какой шаг диагностики наиболее разумен первым?
AСразу выкатить точечные правки в онбординг для новых пользователей: ускорит реакцию команды без долгой диагностики причин
BСвериться по сегменту: сопоставить число новых с источником регистраций и проверить заполнение поля user_type и его распределение
CСначала проверить общий график конверсии: если в среднем стабильно, искать причину в новых сегментах преждевременно и можно подождать
DСравнить скорость загрузки и долю ошибок у новых и возвращающихся, чтобы выделить технические причины снижения именно у новых пользователей
Ответ: Сегментный эффект требует сверки знаменателей и проверки инструментирования сегментирующих полей, а не сразу продуктовых выводов.
Если поле `user_type` сломалось или изменилось правило классификации, метрика по сегменту может «поехать» без реального эффекта в продукте. Сверьте количество новых пользователей с независимым источником, например с таблицей регистраций, и проверьте распределение этих пользователей в эксперимент. Если знаменатель и сегментация корректны, тогда уже можно обсуждать реальное продуктовое влияние и искать причины в воронке.
Подробный разбор →