Элегантные трюки в notebook на персональном компьютере (ноутбуке) — это хорошо и интересно. Но как только речь заходит об исполнении кода в продуктивном контуре, тут же появляются масса ограничений в виде:
- объема доступного железа;
- требований по производительности;
- стабильности;
- соблюдения требований ИБ;
- … (добавьте специи по вкусу).
Нынче в России такая фаза, что для задач data science язык python позиционируется как "серебряная пуля". Похоже, что такой тезис выдвинули те, кто продают курсы по DS на python. А дальше маховик пошел. В целом, это вполне нормально — почти все процессы в физическом мире являются колебательными.
Но, все-таки, в этом хайпе немного недоговаривают. Есть в python ряд досадных моментов, даже в базовых DS задачах, которые сильно усложняют его использование в продуктивном контуре.
Проблема 1
Имя этой проблемы — BlockManager. Это один из столпов архитектуры pandas. Внешне проявляется в том, что:
- память потребляет "как не в себя";
- время исполнения кода зависит от предыдущих состояний интерпретатора и последовательности операций и может меняться на несколько порядков.
Плохо то, что причины такого поведения скрыты за кулисами от обычного разработчика. Такая рулетка в продуктивном контуре при согласованных ресурсах и выделенном окне времени на расчеты мало кому нравится.
Можно, например, почитать:
- наглядную демонстрацию этой проблематики в статье 'The one pandas internal I teach all my new colleagues: the BlockManager';
- причины появления
BlockManagerи допущенные компромиссы в документах автораpandasWes 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».
SemyonSinchenko
Про п. 3 — все же есть MyST Markdown (вдохновленный как раз RMarkdown), который позволяет писать отчет с исполняемыми блоками кода.
i_shutov Автор
Если я правильно понимаю, то это пакет с ограниченными целями — разработка html книг с возможностью перевода в pdf путем печати на pdf принтере. Ближайший сутевой аналог — AsciiDoc, но пока никак не RMarkdown. Поправьте, если не так.
RMarkdown существенно шире. Это и различные интерактивные отчеты, и генерация книг, отчетов, сайтов. Создание различных внешних представлений из одного исходника (word, tex, pdf). Возможность создания презентаций (например, xaringan).
Я даже не стал упоминать
Shiny, чтобы не было споров, потому как по его мотивам появилось недавно такое направление и в python (Dash). Но это уж совсем vendor lock-in (Plotly). Вplotlyужасно тесно.SemyonSinchenko
Ну резанула фраза про то, что аналогов нет вообще. То, что RMarkdown круче я и не спорю)