Нужно сделать дозагрузку 2 млрд строк в хранилище. Пайплайн стабильно обрабатывает 50 тыс строк в секунду. Какая грубая оценка времени ближе всего?
Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
1На лендинг приходит 500 тыс визитов в день. Конверсия в покупку составляет около 4% (доля визитов с покупкой). Какая грубая прикидка числа покупок в день при сохранении единиц измерения наиболее корректна?
AОколо 2 тыс покупок в день: получится при подмене 4% на 0.4% от исходного числа визитов в день
BОколо 200 тыс покупок в день: получится при умножении числа визитов на 40% или потере разряда в пересчёте
CОколо 20 тыс покупок в день: 4% от 500 тыс визитов в день при сохранении согласованных единиц измерения
DОколо 5 тыс покупок в день: получится при применении процента только к десятой доле визитов или неверной базе
Ответ: Чтобы перевести визиты в покупки, умножайте число визитов на конверсию и сохраняйте согласованные единицы измерения по обе стороны.
4% от 500 тыс — это около 20 тыс покупок в день. Такой расчёт — хорошая проверка на здравый смысл при оценке нагрузки на оплату и поддержку. Если получилось 200 тыс, скорее всего перепутаны проценты и доли или потеряны единицы. Для верхней границы можно прикинуть, что конверсия не может быть выше 100%, и сравнить результат с этой оценкой.
2Сервис получает 800 запросов в секунду на эндпойнт. Какая грубая прикидка числа запросов в день ближе всего?
AОколо 70 тыс запросов в день
BОколо 70 млн запросов в день
CОколо 7 млн запросов в день
DОколо 700 млн запросов в день
Ответ: Перевод из «в секунду» в «в день» — это умножение на число секунд в дне и проверка единиц измерения.
В сутках 86 400 секунд (примерно 86 тыс). При 800 запросах в секунду в среднем по суткам получаем 800 × 86 400 ≈ 69 млн ≈ 70 млн запросов в день. 7 млн — ошибка на один порядок (как будто 80 RPS вместо 800). 700 млн — на порядок больше реальности и сопоставимо с нагрузкой крупных платформ типа поисковика. 70 тыс — катастрофическое занижение, как если бы взяли 800 запросов всего за час.
3У вас 2.5 млн событий в день и нужно прикинуть объём событий в месяц для планирования. Какой подход к грубой оценке наиболее разумный?
AРазделить дневное значение на 30, чтобы получить месячный объём событий с учётом фактического числа дней в среднем месяце
BУмножить дневное значение примерно на 30, чтобы получить месячный объём для грубой прикидки на планирование инфраструктуры
CУмножить дневное значение примерно на 21, считая только рабочие дни месяца, раз в выходные нагрузка обычно ниже базовой
DУмножить дневное значение примерно на 7, чтобы получить недельный объём, и считать его достаточным для оценки планов на месяц
Ответ: Для грубой оценки месячного объёма из дневного умножают примерно на 30 дней, согласовав единицы измерения.
Для грубой оценки месячный период удобно брать как 30 дней, если не требуется точность до календаря. Важно не перепутать единицы измерения: события в день нужно перевести в события в месяц умножением на число дней. Если планируете инфраструктуру, можно построить верхнюю границу, взяв 31 день или пиковый день. Деление на 30 или на 12, как и умножение на 365, дают неверный масштаб для месячного объёма.
4У вас MAU = 3 млн. Из исследований известно, что средний пользователь активен около 5 дней в месяц. Какая грубая прикидка DAU ближе всего?
AОколо 500 тыс DAU
BОколо 3 млн DAU
CОколо 15 млн DAU
DОколо 50 тыс DAU
Ответ: Перевод из MAU в DAU удобно делать через сумму активных дней на пользователя, делённую на длину периода.
Грубая прикидка DAU из MAU и средней частоты активности: 3 млн пользователей × 5 активных дней / 30 дней в месяце = 0.5 млн пользователь-дней в день в среднем. Это и есть DAU как среднее число уникальных активных в день. Вариант 3 млн получается, если считать, что каждый MAU активен каждый день; 15 млн — путаница пользователь-дней с уникальными; 50 тыс — занижение в 10 раз, эквивалентное одному дню активности на пользователя за месяц.
5Сессия определяется как последовательность действий с таймаутом 30 минут. В отчёте средняя длительность сессии получилась 40 часов. Что это вероятнее всего означает с точки зрения ограничений и единиц измерения?
AЭто нормальный рост вовлечённости пользователей и ожидаемое значение метрики при увеличении длительности сессий
BЭто доказательство корректности метрики: при больших объёмах среднее значение стабилизируется на правдоподобном уровне
CДостаточно умножить 40 на 60 для перевода в минуты, чтобы значение совпало с ожиданиями и таймаутом сессии в 30 минут
DЭто похоже на ошибку в единицах или определении сессии: например, секунды перепутали с миллисекундами или сессии не закрываются
Ответ: Если метрика нарушает очевидные ограничения, первым делом проверяйте определение и единицы измерения расчёта.
При таймауте 30 минут средняя сессия в 40 часов противоречит здравому смыслу и бизнес-логике. Частые причины: перепутанные единицы времени (секунды и миллисекунды), неверное объединение событий или отсутствие закрывающего события. Такая грубая проверка адекватности помогает сразу искать баг в пайплайне, а не объяснять результат поведением пользователей. После фикса стоит проверить распределение длительностей и долю экстремальных значений.