Ускорить Pandas в 60 раз: проверяем лайфхаки из интернета на реальном проекте и обкладываемся бенчмарками

[atepaevm]

Традиционный комментарий в поддержку polars

[economist75]

+1, и в поддержку fireducks. Однако кейс необычный, и гарантировать ускорение за счет другой живности мы не можем.

[digitaljay]

Плюсану

Но летом 2023, когда проект рефакторился, polars был еще в нестабильной нулевой мажорной версии, так что затаскивать его в продовый проект не хотелось

[Cekory]

  подгрузка ретроданных для этого занимала целый год (!)

Как это могло попасть в прод?

[digitaljay]

Это было MVP внутреннего продукта для сотрудников, так что проект изначально собирали "на коленке", чисто чтобы протестить гипотезу

[kkalmutskiy]

Можно было ещё все что можно обернуть numba и переписать циклы на честные векторные операции, тогда можно было бы на порядок-два ускориться

[digitaljay]

Да, упоминала в статье, что векторные операции хорошо сказываются на скорости, но сходу их было сложно внедрить, тк это обычно требует довольно сильных изменений в коде + операции со строками, например, так сходу не векторизовать

[Ananiev_Genrih]

2025 год: ёжики плакали, кололись, упорно игнорировали polars и duckdb продолжая давиться пандасом "потому что дисклеймер"

[digitaljay]

Не, в 2025 году у нас к счатью этот проект уже не на пандасе живет)))
А вот в 2023 на момент рефакторинга пандас был не самым плохим решением

[CrazyElf]

Насчёт приколов с лишней памятью при конвертации из numpy. Надо было просто сразу и нумпаю тот же тип данных указывать, тогда не было бы расходов на переконвертацию. А вы ему никакой тип не указывали, получался опять же какой-то дефолтный тип по умолчанию.

А так вообще круто, я думал всё знаю про пандас, но узнал таки что-то новое.

Жалко ещё, что Dask совсем никто не использует, но в общем у меня с ним тоже не сложилось в своё время. А потом уже появились более удобные конкуренты.

[AndreySozy]

Если для реализации бизнес-логики достаточно реляционных операций, то такая логика должна реализовываться на SQL. И желательно в базе данных, чтобы не таскать датасеты по сети в контейнер и обратно.

[economist75]

На SQL получается многословно. Плюс это нередко прод-сервер, который легко обвалить неудачным джойном. Поэтому аналитики выгружают csv, зеркалят их в DuckDB или читают прямо огнеутками и дальше джойнят без опасений.

Роль SQL снижается в наше время. Он больше теперь для грубой выборки и партиционирования. Оконные ф-ии могут быстро приводить к деградации скорости, а множественные джойны некрасивы, в отличие от однострочников в JupyterLab в отдельно выполнимых ячейках. В 25 млн блокнотов на гитхабе лишь 1,5% содержат код на SQL.