Нужно ли формировать отчеты аналитиков с очень высокой скоростью
Что проверяют
Не бросаетесь ли вы оптимизировать, не выяснив требований. За формулировкой «очень высокая скорость» ничего конкретного нет, и первый признак сильного кандидата это встречные вопросы. Второй слой: понимаете ли вы, что тяжёлую аналитику не считают на лету поверх боевой базы.
Как отвечать
Сначала уточнить, что значит быстро и для кого:
- кто читает отчёт: человек в интерфейсе ждёт секунды, ночная выгрузка может считаться час;
- какая допустимая свежесть данных: вчерашний срез и «прямо сейчас» дают разные архитектуры;
- объём, глубина истории и сколько отчётов запрашивают одновременно;
- что считается провалом: медленный отчёт раз в месяц и постоянные таймауты это разные задачи.
Дальше решение выбирается под ответы. Интерактивным отчётам помогает предрасчёт: витрины, материализованные представления, инкрементальные агрегаты по расписанию. Разовому отчёту чаще хватает индекса и переписанного запроса, это видно по плану. Тяжёлые срезы уводят с боевой базы на реплику или в колоночное хранилище, где такие сканы стоят дёшево. Роль Python тут скромная: агрегацию отдать базе, большие выборки читать частями через курсор или chunksize, а не собирать миллион строк в список.
Где спотыкаются
Отвечают «конечно, чем быстрее, тем лучше» и сразу переходят к asyncio и multiprocessing. Асинхронность ускоряет ожидание ввода и вывода, а не счёт, потоки в CPython упираются в GIL, и к отчёту, который тормозит на стороне базы, всё это отношения не имеет.
Тянут данные в приложение и группируют их там. База умеет считать агрегат рядом с данными, а приложение сначала оплачивает передачу строк по сети и превращение их в объекты.
Называют цифры вроде «ускорили с минут до секунд» без единого замера. Следующий вопрос всегда один: чем мерили и что оказалось узким местом. Без ответа история звучит как заученный шаблон.