1 
Содержание
Бенчмарк на машине с двумя ядрами и 5,8 ГБ памяти показал, что для типичных аналитических задач переход на Spark часто избыточен. Вместо кластера можно обойтись DuckDB или Polars, которые справляются с файлами до 5 ГБ без падений по памяти и без настройки JVM. Тест охватил загрузку, фильтры с группировкой, join, оконные функции и сортировку на данных от 6 до 180 млн строк. Результаты полезны тем, кто решает, стоит ли усложнять стек ради объёмов, которые помещаются на одном ноутбуке. При выборе инструмента важно понимать, что pandas и Spark требуют больше ресурсов из-за копирования данных в памяти и запуска виртуальной машины Java, тогда как Polars и DuckDB используют более эффективные форматы хранения и обработку по частям. Это позволяет избежать лишних расходов на инфраструктуру, если данные не распределены по нескольким серверам.
Как устроен тест и что именно проверяли
Автор запустил одинаковые операции на шести вариантах: обычный pandas, pandas с бэкендом pyarrow, Polars в ленивом режиме, Polars со streaming, DuckDB и PySpark в локальном режиме. Данные генерировались по схеме TPC-H, основная нагрузка приходилась на таблицу lineitem. Каждая операция возвращала контрольные суммы и количество строк, чтобы исключить расхождения в результатах. TPC-H представляет собой стандартный набор запросов для проверки производительности аналитических систем, а lineitem содержит записи о позициях заказов и служит основной таблицей фактов в этом бенчмарке. Память измерялась отдельным потоком каждые 50 мс по всему процессу, включая дочерние. Порог установлен на 5 ГБ, чтобы избежать свопа. Spark получил ограничение в 60 % доступной памяти и настройку shuffle-партиций по числу ядер. Shuffle здесь означает перераспределение данных между задачами для операций вроде группировки. Polars streaming и DuckDB работали без специального тюнинга, только с лимитом памяти. Такой подход показал реальные пределы каждой библиотеки на слабом железе, а не на сервере с десятками ядер. При принятии решения о выборе инструмента стоит учитывать overhead от запуска JVM в Spark и возможность превышения памяти в pandas при работе с большими таблицами, что делает тест релевантным для ноутбуков с ограниченными ресурсами.
Где каждая библиотека сдалась первой
Pandas без pyarrow не справился с загрузкой уже на 18 млн строк, а с pyarrow дотянул до 60 млн. При группировке и join оба варианта упирались в 60-180 млн строк, но сортировка и запись в parquet падали на 18 млн. Polars в обычном режиме дошёл дальше, однако streaming-вариант и DuckDB обработали все объёмы без превышения лимита памяти. PyArrow использует колоночный формат, который снижает потребление памяти по сравнению со строковым хранением в базовом pandas. Streaming в Polars позволяет обрабатывать данные порциями, избегая загрузки всего датасета сразу. PySpark в локальном режиме проигрывал по времени на малых данных из-за старта JVM, а на больших объёмах терял строки в одной из операций. Автоматическая сверка результатов обнаружила баг: Spark пропускал целый день данных при оконной функции. Ошибка не проявлялась на синтетических тестах без жёсткого контроля сумм, поэтому в реальных пайплайнах её легко пропустить. При оценке надёжности важно помнить, что распределённые системы вроде Spark добавляют сложность и риск потери данных, если не настроен строгий контроль результатов, тогда как встраиваемые решения DuckDB и Polars дают предсказуемое поведение на одном узле.
Что это даёт командам с ограниченным железом
В российских компаниях, где доступ к облачным кластерам стоит дорого или ограничен санкциями, такие тесты помогают избежать лишних расходов. DuckDB и Polars работают через обычный pip или conda, не требуют Java и не зависят от внешних сервисов. Их можно ставить на офисные ноутбуки и CI-сервера с 8-16 ГБ памяти без настройки сети и прав доступа. При этом важно понимать ограничения: если данные уже распределены по нескольким серверам или нужны именно распределённые join через сеть, Spark остаётся инструментом по умолчанию. На одном узле с жёстким лимитом памяти он чаще проигрывает по скорости и надёжности. Перед внедрением стоит прогнать похожий бенчмарк на своих объёмах и задачах, чтобы не платить за сложность, которая не нужна. Для команд это означает возможность быстрее запускать аналитику без привлечения DevOps для кластера, но только пока объём данных не требует горизонтального масштабирования.
Источник
Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Pandas Polars DuckDB и Spark на слабом железе.
Курс по теме — Каталог курсов Школы Больших Данных
