R vs Python в продуктивном контуре

    Элегантные трюки в 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».

    Комментарии 10

      0

      Про п. 3 — все же есть MyST Markdown (вдохновленный как раз RMarkdown), который позволяет писать отчет с исполняемыми блоками кода.

        0

        Если я правильно понимаю, то это пакет с ограниченными целями — разработка html книг с возможностью перевода в pdf путем печати на pdf принтере. Ближайший сутевой аналог — AsciiDoc, но пока никак не RMarkdown. Поправьте, если не так.


        RMarkdown существенно шире. Это и различные интерактивные отчеты, и генерация книг, отчетов, сайтов. Создание различных внешних представлений из одного исходника (word, tex, pdf). Возможность создания презентаций (например, xaringan).


        Я даже не стал упоминать Shiny, чтобы не было споров, потому как по его мотивам появилось недавно такое направление и в python (Dash). Но это уж совсем vendor lock-in (Plotly). В plotly ужасно тесно.

          0

          Ну резанула фраза про то, что аналогов нет вообще. То, что RMarkdown круче я и не спорю)

        0
        Для python есть свой data.table, но выглядит пока сыро — полгода назад на нем я так и не смог реализовать то, что было на R/data.table.

        Что касается R vs python — по тому же kaggle видно, что доля скриптов на R последние несколько лет неуклонно падает. Подозреваю, что не в последнюю очередь из-за того, что в R до сих пор нет приличного deep learning фреймворка, а велосипед R keras -> py keras не кажется особенно надежным. Может, R torch доведут до ума.
          +1
          1. Да, data.table портируют. В тестах на производительность он есть. Но для чего пользоваться медленным полуфабрикатом, если есть оригинал? Поэтому даже не счел нужным упоминать. Совсем аутсайдерская экзотика, тем более что базисом в питоне выступает pandas.
          2. Все многообразие задач не сводится к deep learning. Ну да, там питон используется активно. Но по сути это такая же клеевая прокладка между внешними платформами. Вся сила в платформах и понимании алгоритмов, а не в байндингах.
          3. Есть еще интересные платформы, например, H2O.
            0
            Ну меня-то убеждать в преимуществах R/data.table не надо — мне эта связка всегда нравилась своей выразительностью и скоростью.

            А вот из-за отставания в deep learning (модно-молодежно) R не стал популярной «прокладкой» к низкоуровневым библиотекам. Питон же постепенно переваривает все интересные фичи R (ну и других языков). Даже без deep learning в R не хватает удобного фреймворка для работы с GPU.

            H2O тянет за собой Java + еще один формат as.h2o + интересные ошибки — у меня не те масштабы, чтобы оценить удобство такого подхода.
            0

            так вроде уже отвязали torch от питона как от лишней тормозящей прослойки

              0
              R сейчас может libtorch напрямую использовать.
            0
            возможно выскажу непопулярное мнение, но для ентерпрайза держать один центральный отдел аналитики и нанимать питонистов для обычной трансформации и визуализации данных — пустая трата времени и ресурсов. Питонисты-сатанисты стоят дороже, а сам язык и рантайм жрут компьютерные ресурсы как не в себя и очень медленные. Я уже не говорю про головные боли с библиотеками и пакетными менеджерами (и возможностью подцепить трояна через какую-нибудь питоновскую библиотеку). Спарк-хадуп кластер требует еще больше ресурсов, как на людей так и на инфраструктуру.

            с другой стороны если использовать только SQL (любой), то не нужно создавать новую инфраструктуру — все может работать на существующей инфраструктуре для продуктовых баз данных. Сами SQL специалисты в целом дешевле и более квалифицированные (за те же деньги для питониста-ДС можно взять убер скиллового SQL эксперта).

            визуализацию вообще можно/нужно отдать в руки бизнеса (BI embedded into business), пусть каждый отдел который занимается бизнесом берет себе BI специалиста — тулы типа ПоверБИ/Табло могут покрыть 99% нужд бизнеса, они будут внедрены в контекст самого бизнеса и будет быстрый «feedback loop».

            единственно куда нужно брать специалисов питон/R (без разницы какой язык) — это продуктовое машинное обучение, т.е. создание и поддержание новых продуктов с использованием МЛ. Причем это будет зависеть от ниши — если вы в computer vision — то вам нужен и питон и С++.
            Если вы в финансах/страховании — то скорее всего у вас есть кодовая база на SAS, и нет смысла менять стек.

            Так что грубо говоря без разницы какие там недостатки у пандас по сравнению с data.table, пандас вообще не нужен как таковой. Нужен:
            1. SQL для ETL
            2. решение для BI визуализации (powerBI, tableai, microstrategy, pentaho, qlikview, etc.), чтобы люди близкие к бизнесу, но далекие от ИТ могли сами себе свои диаграммы и отчетики клепать (self-service Business Intelligence так называемый)

            если вам нужен МЛ, то:
            3. нужен любой подходящий язык для разработки статистических моделей, которые приходят из ETL
            4. подходящий рантайм для деплоя и мониторинга стат моделей в проде.
              0

              Мы уже обсуждали подобный подход, например, здесь: https://habr.com/ru/post/461463/.
              Он вполне логичен.


              1. Но на практике оказывается, что есть огромное количество задач, которые не могут быть решены классическим ETL и не натягиваются на модель прямоугольного табличного мира.
                Вот тут вот рассказывали кусочек: https://www.meetup.com/ru-RU/rMoscow/events/267695103/. Мир DBA крайне ограничен, SQL неспособен работать в среде неструктурированных, многоформатных и обрывочных данных. Это все равно как битый блок на диске. Файл прочитать нельзя (DBA подход), но если это картинка, то и с одним битым блоком можно ее почти всю восстановить (DS подход).


              2. Self BI — классные инструменты. Но у них есть 2 маленьких изъяна, которые сжирают все их преимущество.
                а) нужны хорошие прямоугольные данные. далеко не для каждой задачи они существуют и могут быть получены ETL/DAD преобразованием.
                б) self-analytics требует от человека совокупности навыков по обработке данных, их валидации, оценке качества и правдоподобности результата, знаний математики и программирования (какого-никакого), умения визуализировать результат. Обладают ли этими знаниями менеджеры, которые рисуют в табло дашбордики? Да за редким исключением. Поэтому и веры нет в отображаемые результаты и серьезную проверку показателей они зачастую не выдерживают.


              3. Приходилось несколько лет работать с Oracle DBA рука об руку (telecom, realtime). Видел все их мучения, чтобы вроде простые вещи положить в структуру SQL. В конечном итоге они стали делать для сервисных (незвонковых) сложных запросов микс между оракловыми процедурами и доп. обработкой скриптовыми языками — разработчики просто устали прожигать жизнь, играя по чужим правилам.


              4. В целом я говорю о комбинации R + Clickhouse. Никто SQL не отбрасывает, но его роль достаточно сильно снижается. Большая хранилка, быстрая считалка простых агрегатов. Все сложное — снаружи. Дешевле и быстрее.


              5. Смогу ли я переубедить Вас? Нет, нет и еще раз нет. Но такой цели и нет. Наличие на руках множества выполненных проектов, когда DBA/BI/big data "сливались" еще на этапе формулировки задачи дают основание утверждать о жизнеспособности этого подхода.


            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое