Комментарии 7
Генрих, просто прекрасно.
Добрый день.
Спасибо, интересная статья.
Как пандас контрибьютор, пока с весьма скромным вкладом, позволю себе пару замечаний:
Исторически, насколько мне известно, в том числе из единственной книни Wes Mackinney, его мотивацией создания пандас была не "убогость языка python" как такового, а скорее в отсутствии гибкости у экселя, который на тот момент был основным инстурментом анализа в крупных коммерческих конторах, в одной из которых и работал Вес. Зная язык пайтон и его удобство, он как раз и решил сделать свой пакет. При этом, в упомянутой книге, он, конечно, пишет о всех недостатках питона в виде GIL и проблем как с памятью так и с производительностью в сравнении с аналогами. Однако там же он отмечает, что питон остается идеальным выбором в качестве "клея" между разными решениями написанными на c/c++, которых в избытке и они проверенны временем (все эти балсы лапаки айгены минуиты итд).
Смотрел с ужасом на приведенные Вами скрипты (в плане читаемости), а потом прочел "нечитаемый марсианский синтаксис пандас". Дело, наверное, привычки.
Как мне кажется, уже давно понятно, что пандас это не для, скажем, продакшн, анализа. Я воспринимаю его скорее это как разведку, когда нужно пощупать данные. Кроме того, многие ограничения прекрасно обходятся на этапе до использования пандас, например через нумпай, который можно и распараллелить.
Несмотря на всё это, я понимаю Вашу боль - в R это все из +- коробки, а пользуются все всё равно питоном...
Господа, прошу прощения за опечатки. К сожалению, не могу исправить.
Комментарий ждал одобрения модератора 5 часов и теперь, когда я заметил, что комментарий опубликован, прошло более 30минут.
dplyr сначала выглядит неочевидно, я сам упорно держался за rbase, но когда освоишь, это такое кунфу, от которого невозможно отказаться
Быстрее у Вас потому что тест не жизненный. Не в том смысле что датасеты не те (они такие же как и у меня) а в том что такие штуки как arrow / columnar dbms - это не про то чтобы посоревноваться на небольшом датасете в оперпамяти (заметьте, я arrow сравниваю с duckdb под dplyr соусом а не с чистым dplyr в качестве движка)
Чтобы приземлить Ваш бенчмарк чуть ближе к реальности, попробуйте накопировать 200 файлов flights на жёсткий диск в виде 200 паркетов (>60млн.записей), это будет датасет для arrow или duckdb. Затем rbind в оперпамяти (если ее хватит) -это будет датасет для dplyr. Вот теперь если сравнивать на фильтрации и группировках выясниться что даже на 8гб оперативы с чистым dplyr будет гораздо менее комфортно, потому что перегружена оперпамять и один поток а в arriw/duckdb -многопоточность на быстрых ssd и размер оперативы не так критичен. Тут я конечно немного лукавлю в том смысле что если оперпамяти ну прям дофига то на тех же h2o бенчмарках по ссылке в конце статьи data.table уделывает и dplyr и arrow и утку.
И еще одна ремарка: если совсем уж жизненно делать- то 200 паркетов сохраняют не в кучу а по поддиректриям (партициям) где название каждой такой папки так же участвует в фильтрации и arrow/duckDB понимает в какие папочки лезть или идти мимо и разница с data.table в оперпамяти будет не столь разительна (пример про это есть у arrow в виньетках)
Утиные истории со стрелами на паркете