Какой объем данных вы обрабатываете

Что проверяют

Масштаб вашего реального опыта и понимание, где у инструментов предел. Цифра нужна, но важнее, почему под такой объём выбраны именно эти инструменты. Следом спросят, что вы сделаете, если данных станет в десять раз больше.

Как отвечать

Отвечайте цифрами из своего проекта, сразу в нескольких измерениях:

• объём в покое: сколько гигабайт или терабайт лежит в базе или хранилище;
• поток: строк или событий в секунду и в сутки, отдельно средний и пиковый;
• порция обработки: батч в сто строк и файл на 50 ГБ требуют разного подхода;
• требование ко времени: отчёт к утру или ответ за сотню миллисекунд.

Затем свяжите объём с инструментами:

• до нескольких гигабайт: pandas, но ему нужно в разы больше памяти, чем весит файл. Выручают read_csv(chunksize=...), узкие dtype и Parquet вместо CSV;
• десятки гигабайт на одной машине: Polars с ленивыми вычислениями или DuckDB, оба быстрее pandas и умеют работать с данными больше памяти;
• больше одной машины: PySpark или Dask;
• поток событий: консьюмеры Kafka. Celery это очередь фоновых задач, а не потоковая обработка.

Про параллелизм: из-за GIL CPU-нагрузку параллелят процессами (multiprocessing, ProcessPoolExecutor), а потоки и asyncio помогают при ожидании сети и диска. Сборка Python без GIL существует, но пока не вариант по умолчанию.

Сильный ответ звучит так: «Около 40 млн строк в сутки, пик 2 тысячи событий в секунду, хранилище 3 ТБ в Parquet, дневная агрегация на Polars идёт 12 минут». Подставьте свои числа. Если объёмы были скромные, так и скажите и покажите, что понимаете, что изменится при росте.

Где спотыкаются

Отвечают «большие данные» или «много» без чисел. Для интервьюера это знак, что кандидат не знает свою систему.

Путают число строк и объём в байтах или называют средний поток вместо пикового, хотя система падает именно на пике.

Преувеличивают масштаб. Следом спросят про партиционирование, память и время обработки, и придуманная цифра не выдержит второго вопроса.