Элегантные трюки в notebook на персональном компьютере (ноутбуке) — это хорошо и интересно. Но как только речь заходит об исполнении кода в продуктивном контуре, тут же появляются масса ограничений в виде:

• объема доступного железа;
• требований по производительности;
• стабильности;
• соблюдения требований ИБ;
• … (добавьте специи по вкусу).

Нынче в России такая фаза, что для задач data science язык python позиционируется как "серебряная пуля". Похоже, что такой тезис выдвинули те, кто продают курсы по DS на python. А дальше маховик пошел. В целом, это вполне нормально — почти все процессы в физическом мире являются колебательными.

Но, все-таки, в этом хайпе немного недоговаривают. Есть в python ряд досадных моментов, даже в базовых DS задачах, которые сильно усложняют его использование в продуктивном контуре.

Является продолжением серии предыдущих публикаций.

Проблема 1

Имя этой проблемы — BlockManager. Это один из столпов архитектуры pandas. Внешне проявляется в том, что:

• память потребляет "как не в себя";
• время исполнения кода зависит от предыдущих состояний интерпретатора и последовательности операций и может меняться на несколько порядков.

Плохо то, что причины такого поведения скрыты за кулисами от обычного разработчика. Такая рулетка в продуктивном контуре при согласованных ресурсах и выделенном окне времени на расчеты мало кому нравится.

Можно, например, почитать:

• наглядную демонстрацию этой проблематики в статье 'The one pandas internal I teach all my new colleagues: the BlockManager';
• причины появления BlockManager и допущенные компромиссы в документах автора pandas Wes McKinney 'What is BlockManager and why does it exist?';
• личное мнение Wes McKinney в статье 'Apache Arrow and the "10 Things I Hate About pandas"'.

Проблема 2

Типичная связка pandas + sql/spark для данных среднего объема (сотни Гб — десятки Тб) по скорости и объему требуемых аппаратных ресурсов очень сильно проигрывает связке data.table + Clickhouse на типичных задачах (преобразования data.frame). Технические детали и актуальные тесты можно посмотреть на страничке Database-like ops benchmark. Желающие могут сами скачать тесты, выполнить их на своей инфраструктуре и составить собственное мнение.

Проблема 3

Story-telling отчеты позволяют крайне эффективно предоставлять пользователям информацию. Удачная реализация концепции Literate Programming. И пользоваться таким отчетами бизнес пользователям весьма удобно. В python, к сожалению, не наблюдается аналога Rmarkdown.

Вывод

Понятно, что тренды у нас формируются курсами и требованиями к вакансиям на hh.ru. Но если говорить о решении практических задач в enterprise то использование связки R + Clickhouse оказывается куда выгоднее. К этой обойме можно еще присовокупить golang, тоже отличный инструмент.

Fin, доставайте напалм.

Предыдущая публикация — «R, Монте-Карло и enterprise задачи, часть 2».