backfill 2 млрд строк в хранилище. Пайплайн стабильно обрабатывает 50 тыс строк в секунду. Какая грубая прикидка оценка времени ближе всего?Оценка порядка величины, проверка результатов на здравый смысл, Fermi-задачи — навыки, которые защищают от ошибок на порядки. На собеседовании могут спросить: «сколько данных генерирует Яндекс.Метрика за день?» или попросить проверить, правдоподобен ли результат запроса. Аналитик, который не делает sanity check, рискует принять решение на основе бага.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
4% от 500 тыс — это около 20 тыс покупок в день. Такой расчёт — хороший `sanity-check`, чтобы оценить нагрузку на оплату и поддержку. Если кто-то получает 200 тыс, скорее всего перепутал проценты и доли или потерял `units`. При необходимости можно построить `upper bound`, считая, что `conversion` не может быть выше 100%.
Подробный разбор →В сутках 86 400 секунд, поэтому 800 `requests per second` дают около 69 млн `requests per day`. Такая прикидка помогает оценить нагрузку и лимиты до подробных расчётов. Ошибки чаще всего связаны с потерянным нулём или смешением `units`. Для `upper bound` можно учитывать пик нагрузки, а не среднюю.
Подробный разбор →В грубая прикидка оценках месячный период удобно брать как 30 дней, если не требуется точность до календаря. Важно не перепутать `units`: `events per day` нужно перевести в `events per month`. Если планируете инфраструктуру, можно также построить `upper bound`, взяв 31 день или пиковый день. Но для первичной прикидки достаточно 30.
Подробный разбор →Если каждый из 3 млн пользователей активен 5 дней в месяц, то суммарно это 15 млн пользователь-дней в месяц. Делим на 30 и получаем около 500 тыс `DAU` по грубая прикидка. Это не точное значение, но хороший `order of magnitude` `sanity-check`. Дальше можно уточнять распределение активности, потому что оно обычно неравномерное.
Подробный разбор →При таймауте 30 минут средняя `session` на 40 часов противоречит здравому смыслу и бизнес-логике. Частые причины: перепутанные `units` времени (секунды и миллисекунда), неверное объединение событий или отсутствие закрывающего события. Такой грубая прикидка `sanity-check` помогает сразу искать баг в пайплайне, а не объяснять результат поведением пользователей. После фикса стоит проверить распределение длительностей и долю экстремальных значений.
Подробный разбор →В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Открыть Карьерник в Telegram