БИГ ДАТА ВСЁ! СПАРК ВСЁ!

В ЛинкеДЫНЕ увидел интересный пост. Решил тут его запостить с указанием автора. А ведь реально, зачем иногда запускать спарк, когда можно все крутить другими инструментами, менее требовательными к настройке и железу.

Начало поста: ⚡️ Data Engineer 2026: Хватит использовать кувалду для гвоздей. Почему Spark часто избыточен.

"Spark или Polars?". Решил провести тест на реальных данных — 1 ТБ логов (соединения, аггрегации, фильтры).

Условия:

Spark: Кластер EMR (3 ноды, суммарно 48 ядер, 128 ГБ RAM). Время включает поднятие сессий и настройку.

Polars + DuckDB: Ноутбук с 64 ГБ RAM. Никакого кластера.

Результаты меня самого удивили:

Spark (кластер): ~20 минут чистой обработки + 5 минут на инициализацию. Итог: 25 минут.

Polars + DuckDB (на компе):

Обработка пачками по 100 ГБ: 7 минут (и можно параллелить).

Однопроходная обработка всего 1 ТБ: 11 минут.

Почему так? Данные не врут, и они совпадают с последними исследованиями :

Скорость: На данных до 1-2 ТБ современные векторизованные движки (Polars, DuckDB) просто быстрее JVM-стека Spark из-за отсутствия накладных расходов на сериализацию и shuffle .

Память: Polars в ленивом режиме реально жрет на 60-70% меньше памяти, чем Spark на аналогичных операциях. Это доказано в тестах MDPI . Данные не хранятся в памяти, а текут через процесс (streaming).

Удобство: Не надо настраивать кластер. Просто pip install.

Но давайте без хайпа. Где правда?

✅ Polars + DuckDB идеальны, когда:

Ваши данные "помещаются" на один хороший сервер (до 5-10 ТБ).

Вы ненавидите возню с конфигами Spark.

У вас 80% ETL-задач — фильтрация, аггрегация, джойны (но не 100-столовые монстры).

❌ Spark все еще рулит, если:

У вас петабайты и тысячи ядер.

Нужна единая платформа с глобальным каталогом данных (Unity Catalog и т.п.).

Требуется сложный стриминг exactly-once, который уже обкатан годами .

Мой вывод: Для 90% дата-инженеров, работающих с "терабайтами", Spark — это оверкилл. Мы платим за сложность инфраструктуры там, где можно обойтись одним мощным инстансом и умным кодом. Конец поста Источник

Мое мнение: Вообще согласен. Но до реальности это может так и не дойти, либо дойдет очень и очень не скоро. Сколько кода уже написано и переписывать его на новые инструменты не целесообразно - это ведь деньги. И очень непонятно, как объяснить бизнесу, что надо сейчас АСТАНАВИТЬСЯ! и все переделывать под поларс и duckDB. Но с другой стороны запуск спарка, когда у тебя есть кластера - не проблема. Ну да.. крутим этими кластерами не ТБ, а даже меньше. А что если в какой-то момент надо будет крутить больше.. Будем срочно перекатываться?

Да и на запуск спарка я бы не сказал, что это проблема. Да, инициализация бывает долгая, пока спарк стартанет. Ну подождать 5 минут можно.. Хотя если ресурсы есть, то за 10 секунд все собирает.

Короче это холиварная тема. Согласен, что некоторые инструменты просто не нужны в компании, но кто даст время не пересборку всех кубер операторов, переписывание и переделку инфры?

В мелких компаниях я бы рассмотрел polars + duckDB точно.. Там еще и рядом starrocks же есть. Вообще всеми руками за!

БИГ ДАТА ВСЁ! СПАРК ВСЁ!
В ЛинкеДЫНЕ увидел интересный пост. Решил тут его запостить с указанием автора | Сетка — социальная сеть от hh.ru