Переписали дневной ETL с Pandas на Polars — выигрыш 6x по времени, но грабли тоже собрали

[proxmoxaddict]

Поделюсь опытом миграции, может кому сэкономит неделю. Был дневной ETL на Pandas: тянем ~40 ГБ сырых логов (партиционированный parquet), джойним со справочниками, агрегируем, пишем витрины. Крутилось часа полтора и периодически падало по памяти на пиковых днях, приходилось дробить руками. Переписали на Polars с ленивым API (scan_parquet + lazy, без eager-загрузки), включили streaming-движок для агрегаций, которые не влезают в RAM. Итог: то же самое считается минут за 14, пик по памяти упал втрое, падений по OOM больше нет вообще. Прирост 6x по времени, и это без переезда на другое железо. Но не всё гладко, ниже про грабли, и хочу услышать, у кого как.

[Bowden]

Грабли давай, конечно, но сразу встречный вопрос: а почему не DuckDB? У тебя задача звучит как чистый SQL-кейс — джойны, агрегации, partitioned parquet. DuckDB это всё жрёт нативно, out-of-core из коробки, и SQL читается всей командой, а не только тем, кто выучил polars-экспрешены. Мы похожий пайплайн гоняем на нём, 40 ГБ для него вообще не нагрузка. Polars шикарен, когда тебе нужны сложные оконные трансформации внутри Python, но для классического ETL DuckDB часто проще и так же быстр.

[fabs2002x]

@Bowden, Грабли, как обещал. Первое и самое больное — таймзоны и datetime. Polars гораздо строже Pandas: где Pandas молча проглатывал смесь naive и tz-aware дат, Polars честно падает, и нам пришлось приводить всё к UTC явно на входе. Второе — экосистема: половина наших аналитиков пишет код, который ждёт на выходе pandas.DataFrame (scikit, кастомные либы), так что на границе пайплайна всё равно .to_pandas(), и вот тут zero-copy не всегда срабатывает, иногда ловишь лишнюю копию в памяти. Третье — ленивость коварна: .collect() в неожиданном месте материализует промежуток, который ты считал ленивым, и привет, пик по памяти вернулся. Профилируй план через explain, иначе streaming тихо отключается на неподдерживаемой операции.

[nixos_andy]

Полностью узнаю себя в пункте про .collect() в неожиданном месте. Добавлю от себя: следите за версией. До Polars 1.x streaming-движок был помечен экспериментальным и реально мог тихо давать другой результат на краевых случаях с null в группировках. На 1.x стало сильно стабильнее, но всё равно — закрепите версию в проде и не прыгайте на свежак без прогона на эталонном датасете. Один раз словили расхождение в агрегации после минорного обновления, искали полдня.

[depechie]

@fabs2002x, Не хочу быть тем самым душнилой, но: 40 ГБ в день — это размер, на котором и оптимизированный Pandas с Arrow-бэкендом (тот, что в Pandas 3.0 по умолчанию) уже не так позорно выглядит, как старый numpy-backed. Прежде чем переписывать тысячи строк на новый фреймворк, стоит хотя бы померить, сколько даёт просто включение copy-on-write и Arrow-типов на текущем коде. Иногда выигрыш миграции съедается стоимостью поддержки кода, который теперь понимает полтора человека в команде. Не агитирую против Polars, он реально быстр, просто призываю считать совокупную стоимость, а не только секунды на бенчмарке.

[nogo487]

Полярис у нас в проде год, отвечу скептику выше: совокупная стоимость как раз в плюсе оказалась, потому что упавший ночью пайплайн на Pandas по OOM стоил дежурному инженеру вставания в 4 утра, а это куда дороже любого рефакторинга. Стабильность по памяти из-за streaming — недооценённый аргумент, его на бенчмарках не видно, а в эксплуатации это главное. Но соглашусь, что порог входа в синтаксис реальный: новичку polars-экспрешены поначалу выносят мозг сильнее, чем привычный pandas. Документацию команде дать обязательно, иначе каждый изобретает свой стиль и ревью превращается в ад.