[Python, Программирование, Data Mining, Big Data, R] R vs Python в продуктивном контуре
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Элегантные трюки в 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».
===========
Источник:
habr.com
===========
Похожие новости:
- Обновление Ruby 3.0.1 с устранением уязвимостей
- [ECM/СЭД] Content Services Platform — новая реинкарнация систем электронного документооборота
- [API, Dart] Dart на сервере
- [Python, Алгоритмы, API, 1С] Tesseract vs таблицы. Распознавание документов. Часть 2
- [Программирование, Промышленное программирование, Управление разработкой, Распределённые системы] Предварительная оптимизация — корень всех зол?
- [Хостинг, Информационная безопасность, Серверное администрирование, Законодательство в IT] Дата-центр возле Амстердама называют «выгребной ямой интернета», но он продолжает работу
- [Читальный зал, Научно-популярное, Космонавтика] Знакомьтесь, первая вертушка на Марсе. Что же делает её такой… изобретательной (перевод)
- [Разработка веб-сайтов, .NET, ASP, C#, Микросервисы] Учим ASP.NET Core новым трюкам на примере Json Rpc 2.0
- [Беспроводные технологии, Разработка для интернета вещей, Разработка под Arduino, DIY или Сделай сам] MQTT-SN + ESP8266
- [] 10 лет главной IT-конференции на Урале. Чего ждать от DUMP-2021?
Теги для поиска: #_python, #_programmirovanie (Программирование), #_data_mining, #_big_data, #_r, #_data_science, #_enterprise, #_r, #_python, #_python, #_programmirovanie (
Программирование
), #_data_mining, #_big_data, #_r
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:57
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Элегантные трюки в notebook на персональном компьютере (ноутбуке) — это хорошо и интересно. Но как только речь заходит об исполнении кода в продуктивном контуре, тут же появляются масса ограничений в виде:
Нынче в России такая фаза, что для задач data science язык python позиционируется как "серебряная пуля". Похоже, что такой тезис выдвинули те, кто продают курсы по DS на python. А дальше маховик пошел. В целом, это вполне нормально — почти все процессы в физическом мире являются колебательными. Но, все-таки, в этом хайпе немного недоговаривают. Есть в python ряд досадных моментов, даже в базовых DS задачах, которые сильно усложняют его использование в продуктивном контуре. Проблема 1 Имя этой проблемы — BlockManager. Это один из столпов архитектуры 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». =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_data_mining, #_big_data, #_r |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:57
Часовой пояс: UTC + 5