Комментарии 14
Для сравнения использован Pyarrow в Polars, отключенный по умолчанию в Pandas 2, вот и вся разница. Зачем все это сравнение, если с Pyarrow в Pandas результаты такие же или лучше? А для распараллеливания Dask нужен или joblib, и то и то честно по количеству доступных ядер умеет раскидать и кратно ускорить.
Спасибо за комментарий.
Я дополнил статью отдельным сравнением между Polars и Pandas (+Pyarrow). Там видно, что скорость пандаса с Pyarrow действительно стала выше, но даже с учетом этого Pandas отстает от Polars.
Polars все же остается быстрее чем Pandas на 10-15%.
Код вы не показываете, а такая малая разница может быть связана с более аккуратным указанием типов столбцов при открытии файлов или разницей версий библиотек (например, polars может использовать более новую версию pyarrow или другие параметры). Обе библиотеки вызывают один и тот же метод pyarrow.csv.read_csv, так какую разницы вы ожидаете найти? Можно его просто в joblib обернуть и использовать без лишний прослоек.
Спасибо ещё раз за ваши комментарии.
Как отмечалось в статье, тут речь не идёт о том, что Polars полностью лучше чем Pandas. Это лишь результат обработки конкретного кейса, с которым довелось поработать. Не исключено, что Pandas может стать лучше, быстрее и т.д. Опять же вам решать в конечном итоге чем пользоваться и как.
каждый девятый дата-аналитик из десяти
То есть один из десяти?.. )))
Прочитав всевозможные форумы, которые хоть как-то намекали на повышение
скорость обработки в Pandas, мы поняли, что метод .apply — это то, что
необходимо для достижения этой максимальной скорости (само собой, мы
видели комментарии насчет использования .numpy, но для нашего случая оно
не очень подходило).
Ребят, кажется вы не то читали. Я мало знаю про Pandas, но из того что знаю - apply это самый медленный способ производить расчеты в Pandas и применять его надо только если очень хочется.
Переходя к цифрам, бессмысленно рассматривать файлы с количеством строк
меньше 5к — тут на валидацию выходит меньше секунды. Поэтому мы
рассматриваем варианты с 10к строк и выше.
Это не серьезно в принципе. Вы попробуйте гигабайт хотя-бы двадцать своему алгоритму скормить.
Вот синтетический пример:
import pandas as pd
from timeit import timeit
n = 10000000
df = pd.DataFrame([{"a": i, "b": i, "c": i} for i in range(n)], columns=["a", "b", "c"], index=list(range(n)))
def test1():
data = df.apply(lambda i: i + 1)
def test2():
df["a"] = df["a"] + 1
df["b"] = df["b"] + 1
df["c"] = df["c"] + 1
t1 = timeit("from __main__ import test1; test1()", number=100)
print(t1)
t2 = timeit("from __main__ import test2; test2()", number=100)
print(t2)
и результат
7.037287416
1.9289679590000013
какой может быть перфоманс с лямбдами, вы что? Вызывать питонью функцию в цикле на большом датасете - это безумие. Мало того, что вызов функций в питоне сам по себе не быстрый процесс, так вы же прям направленно убиваете весь смысл движка - использование векторных инструкций процессора.
Спасибо за комментарии)
Для простых операции как вы показываете в своём примере действительно лучше не пользоваться методом apply, но в статье речь идёт о более комплексной проверке, которые требуют обработку через определённые функции. Эти функции не могут быть заменены методами от Pandas или Numpy (и об этом тоже было написано в статье)
Да, верно сказано про лямбды и отказ в тестах от методов isna(), notna(), np.where() и вообще Numpy-методов (ведь Pandas написана поверх Numpy, значит это одно и то же?) Эти методы гораздо быстрее родных и там где скорость важна - аналитики их используют и знают.
Текущая ситуация с Pandas vs Polars для аналитиков - примерный паритет. Pandas умеет в мультииндексы, Polars умеет во что-то немного быстрее. Но скорость увеличить можно несчетным числом способов, самый легкий из которых - апгрейд и ETL.
Спасибо за ваш комментарии)
Тут мы только сравниваем Pandas и Polars без каких-либо дополнения. Конечно у Pandas есть возможность получить огромный буст в своей работе, или наверное вообще было проще отказаться от обеих библиотек и смотреть в сторону чего-то другого.
Но тут я решил немного поделиться результатом и своими мыслями. Надеюсь в будущем смогу поработать с другими библиотеками и пойму что я упустил в своей статье)
Основная проблема таких бенчмарков - это то, что они не учитывают, что pyarrow, polars и тд. поддерживают только 60-70% функциональности pandas, что убивает все приросты от повышенной скорости. А если надо обрабатывать огромные объёмы, то для этого давно есть Spark (а уж Spark + Scala вообще топ)
В процессе приложения можно SQLite3 загрузить и пользоваться SQL для обработки. CSV грузит быстро, типы данных на уровне полей сохраняет, так что можно менять на лету, работает очень быстро. На сотнях гигабайт еще 20 лет назад работало прекрасно, с ноутбучным HDD и 1GB RAM.
В процессе приложения можно SQLite3 загрузить и пользоваться SQL для обработки. CSV грузит быстро, типы данных на уровне полей сохраняет, так что можно менять на лету, работает очень быстро.
Тогда уж DuckDB
Битва медведей: Pandas против Polars