Sanity-check и оценка: вопросы для собеседования (часть 3)
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Вопросы 11–15 из 20
11В отчёте `CTR` показан как 2.5. Команда утверждает, что это 2.5%. Какой `units` `sanity-check` самый правильный?
AУточнить, в каких `units` хранится `CTR`: доля (0..1) или проценты (0..100), и привести к единому формату везде.
BСчитать, что 2.5 и 2.5% — одно и то же, раз цифры совпали.
CВсегда делить `CTR` на 100, даже если он уже в долях, чтобы перестраховаться.
DСравнивать `CTR` между днями можно без `units`, потому что это относительная метрика.
Ответ: Для метрик-долей важно фиксировать `units`: доля в диапазоне 0..1 или проценты в диапазоне 0..100.
Если `CTR` равен 2.5, это уже больше 1, значит в долях это невозможно и требуется интерпретация как проценты. Хороший грубая прикидка `constraints` чек: доля кликов не может превышать 1. Чтобы избежать ошибок, договоритесь об одном формате хранения и отображения и делайте явное преобразование `units` на границах системы. Это типичная ловушка, которая даёт `order of magnitude` сбои в отчётах.
12В дашборде метрика `conversion` определена как доля пользователей, совершивших хотя бы одну покупку за день. В отчёте вы видите 130%. Какой грубая прикидка `sanity-check` по `constraints` наиболее уместен?
AЭто нарушает `upper bound`: доля пользователей не может быть больше 100%, проверьте `units` числителя и знаменателя (пользователи vs события) и фильтры.
BЭто нормально: значит пользователи в среднем покупают 1.3 раза в день.
CНужно умножить значение на 100, чтобы привести к правильному формату.
DДостаточно округлить до 100% и продолжать анализ.
Ответ: Для доли пользователей существует `upper bound` 100%, поэтому значение выше 100% почти всегда указывает на ошибку в `units` или определении метрики.
Быстрый грубая прикидка помогает сразу проверить `constraints` метрики: доля пользователей с событием не может превышать 100%. Если получилось 130%, часто перепутали `units`: в числителе посчитали события (покупки), а в знаменателе пользователей. Ещё типичный источник — дубли, неверные джойны или фильтры по времени. Сначала исправьте определение, потом интерпретируйте результат.
13Каждое событие занимает примерно 1 `KB` в логах, а в день приходит 50 млн `events`. Какой `order of magnitude` для суточного объёма данных ближе всего, если сделать грубая прикидка оценку по `units`?
AОколо 50 MB
BОколо 5 GB
CОколо 50 GB
DОколо 50 TB
Ответ: При грубая прикидка оценке объёма умножайте количество объектов на размер одного объекта и проверяйте `order of magnitude`.
50 млн умножить на 1 `KB` даёт порядка 50 млн `KB`. Это примерно 50 тыс `MB`, то есть около 50 `GB`, если считать в десятичном приближении. Такой `order of magnitude` полезен, чтобы быстро поймать ошибки в планировании хранилища. Дальше можно уточнять средний размер события и долю сжатия как отдельные `assumptions`.
14ETL job обработал 120 млн строк за 2 часа. Какой грубая прикидка `throughput` в `rows per second` ближе всего?
AОколо 17 тыс строк в секунду
BОколо 170 строк в секунду
CОколо 170 тыс строк в секунду
DОколо 1.7 млн строк в секунду
Ответ: Перевод времени в секунды и расчёт `throughput` помогают быстро проверить реалистичность скорости обработки.
2 часа — это 7200 секунд, поэтому 120 млн / 7200 ≈ 17 тыс строк в секунду по грубая прикидка. Такой `units` чек помогает поймать ошибки вроде перепутанных минут и секунд. Если получилось 1.7 млн строк в секунду, стоит пересчитать, не потеряли ли вы ноль или не перепутали `rows` и `batches`. В интервью важно уметь сделать такую оценку без точного калькулятора.
15Вы видите 300 млн `events` в день. Коллега заявил, что `DAU` равен 250 млн. Вы знаете, что у активного пользователя минимум 5 `events` в день. Какой `upper bound` `sanity-check` корректен?
AСравнить 300 млн и 250 млн напрямую: раз они близки, значит всё нормально.
BПостроить `upper bound`: `DAU` не может превышать 300 млн / 5 = 60 млн, значит 250 млн противоречит `constraints`.
CПостроить `lower bound`: `DAU` точно больше 300 млн / 5 = 60 млн, значит 250 млн занижен.
DИгнорировать минимум 5 `events`, потому что он не влияет на `units`.
Ответ: Если известен минимум событий на пользователя, можно поставить `upper bound` на `DAU` через общее число `events`.
При `constraints` минимум 5 `events` на активного пользователя общее число `events` ограничивает максимум пользователей. Поэтому `DAU` не может быть выше 60 млн при 300 млн `events`. Такой грубая прикидка чек быстро находит ошибки в расчёте уникальных пользователей или в фильтрах активности. Далее стоит проверить дедупликацию пользователей и определение активного дня.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram