Настоящая публикация не содержит ни кода, ни картинок, поскольку суть вопроса несколько шире, а на конкретные вопросы всегда можно ответить в комментариях.


За последние пару лет мне довелось применять R для решения весьма разнообразных задач в различных вертикалях. Естественно, что применение R заведомо подразумевает решение задач, связанных с той или иной математической обработкой цифровых данных, а разнообразность задач определялась, в первую очередь, самой предметной областью в которой эти прикладные задачи возникали. Частично отдельные задачи кратко упоминались в предыдущих публикациях. Разные предметные области, от земли (АПК) и заканчивая применением для прикладных задач с использованием летательных аппаратов, вплоть до космических.


Накопленная практика позволяет утверждать, что изначальный кредит доверия в R, сопутствующую экосистему и коммьюнити оказался полностью оправданным. Не возникло ни одного кейса, который нельзя было бы решить средствами R за разумный срок.


Независимое подтверждение этого тезиса можно получить путем наблюдения за экспоненциальным ростом успешного применения R в обычном бизнесе (не ИТ) на Западе. Например, практически половина докладов с конференции EARL 2017 (Enterprise Applications of the R Language), прошедшей в сентябре этого года, содержат кейсы по использованию R для решения бизнес-задач. В докладах есть примеры по анализу данных в недвижимости, автоматизация деятельности аудиторов, анализ транспортных систем, анализ системы канализации и многие другие отрасли...


Бизнес-кейсы, когда применение R оправдано, в целом могут быть охарактеризованы следующим образом: по набору разнородных внутренних и внешних источников необходимо оперативно получить информацию о потенциально проблемных местах, требующих человеческого вмешательства. А также желательно предоставить весь набор информационных срезов и представлений, помогающих человеку принять оптимальное решение.


Понятно, что в такой постановке задачи требуется давать ответы не только на типовые вопросы, но и быть готовым быстро предоставить все необходимое для разового запроса. Акцент несколько смещается с методичного перелопачивания всей информации, сохраненной в корпоративной системе, к локальной композиции подходящих к контексту вопроса элементов из различных источников данных.


Какой функционал обычно бывает востребован?


  1. импорт данных из различных источников. txt\csv, xls, web scrapping, RDBMS.
  2. простейшая обработка данных (группировка, агрегатирование).
  3. временной анализ (как правило, 80% данных сопровождаются временными метками).
  4. расширенная обработка (элементы высшей математики, включая элементы машинного обучения); наиболее популярен поиск аномалий, различные классификаторы, рекомендации и прогнозирование и модная нынче тема “process mining”.
  5. визуализация способами X, Y, Z, (вписать недостающие).
  6. интеграция с внешними информационными системами для экспорта рассчитанных данных.
  7. экспорт в форматы, удобные для восприятия человеком. pdf, html, xls, doc, ppt.
  8. web-base рабочее место для аналитика\рядового пользователя.
    Приведенный функционал доступен в рамках экосистемы R без особой необходимости инсталляции каких-либо дополнительных сторонних компонент. Оптимальный open-source набор выглядит следующим образом:
    • RStudio IDE — для разработки и ad-hoc анализа;
    • пакеты с CRAN\GitHub — для расширения функционала в контексте задачи;
    • Shiny Server — для создания интерактивных web-based аналитических приложений.
    • Plumber API для публикации функций R-аналитики для использования сторонними приложениями.

Все вышеупомянутое было относительно подробно разобрано в предыдущих публикациях.


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


С точки зрения бизнеса инструментарий R можно считать почти идеальным и вот почему:


  1. Отсутствует какой-либо финансовый барьер для начала использования:
    • Не надо никаких первоначальный вложений в лицензии.
    • Нет никаких лицензионных ограничений и проблем потенциального расширения.
    • Нет никаких ежегодных платежей за поддержку лицензий.
    • Все прекрасно работает на linux, нет необходимости в приобретении дополнительных ОС.
  2. Если внешние системы выдают необходимую информацию, то этого уже достаточно для начала проекта. Сопутствующие проекты по доработке не требуются, все можно будет сделать на уровне аналитики.
  3. Уже есть доказанная практика применения R в бизнесе практически во всех вертикалях.
  4. Не надо планировать глобальный проект, достаточно начать с частных проблемных мест. Проекты получаются компактными и быстрыми, результаты легко переводятся в деньги (заработанные или сэкономленные). Полученные результаты позволяют взглянуть на существующие задачи под иным углом зрения, обнаружить реальные проблемы и расставить акценты в более правильном виде.

Однако, как всегда, найдется и ложка дегтя.


На Западе R и Python проходят катком по задачам работы с данными. Любой интересующийся человек хоть краем уха слышал про эти языки\платформы. В России же про R знает и слышали исчезающе малая группа людей. Шаг влево, шаг вправо — и мы оказываемся в мире 1С, C++, Java. Сложно, долго, дорого. Нескончаемый development, сильно ограниченный по функционалу “толстый клиент”.


Западное R коммьюнити можно считать сформировавшимся. Российское R коммьюнити не может появиться из ниоткуда. Может имеет смысл оглянуться вокруг и пробовать решать задачи по-другому? После успешного решения нескольких бизнес задач трудно будет заставить себя вернуться к старым методам. Слишком уж разительной будет перемена.


Предыдущий пост: «Цифровая экономика и экосистема R»

Комментарии (26)


  1. WizardryIB
    17.10.2017 15:22

    Одобряю. На хабре полно программистов и python им ближе, но простым аналитикам комфортно и на R. Каждому своё…


    1. i_shutov Автор
      17.10.2017 15:33

      Если нужно не просто внутри покрутить числа, но еще и дать обычным бизнес-пользователям удобный инструмент для самостоятельной работы, то аналога Shiny в Python среде пока что нет. Dash вышел только-только, много проще по функционалу и заточен на plotly, что не кажется неестественным.


  1. dimastrow
    17.10.2017 15:45

    Поддерживаю, но оставлю свои правки.
    В джентельменском комплекте не хватает Jupyter Notebook. Недавно поставил помимо стандартного Python интерпретатора, R, оказался крайне доволен, удобство ноутбука с его ламповым маркдауном, Latex и bash-ем очень помогает.
    Рython или R, раньше пользовался R(тащем та продолжаю изучать его и использовать и сейчас), на новом месте работы пришлось оперативно учить Python, ибо вся экосистема построена на нем. Могу сказать, что на Python я программирую, а вот на R анализирую, собственно, где то я уже слышал такую фразу, и сейчас только убедился в ней.


    1. i_shutov Автор
      17.10.2017 15:52

      А мы на R не только анализируем, но и программируем. Фактически, shinyapp, выступает в качестве лица к аналитическому бэкенду. С обработкой exeption, валидацей, автотестами, ассертами, roxygen документированием, db бэкендом, js+css тюнингом и пр. Ожидаемый в следующем релизе shiny асинхронный режим работы вообще развяжет руки.


      1. dimastrow
        17.10.2017 16:22

        Я могу вам только позавидовать :)


    1. i_shutov Автор
      17.10.2017 15:57

      А для ряда задач приходится еще вспоминать и Mathematica


  1. kablag
    17.10.2017 19:45

    Для меня единственной проблемой в R является большое количество пакетов, решающих сходные задачи, особенно если делаешь «на века» — сначала напишешь так, потом по другому… и всё хочется попробовать :)


    1. i_shutov Автор
      18.10.2017 10:34

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


  1. KEugene
    17.10.2017 22:28

    Не знаю, в тему ли статьи или нет, но хотелось бы добавить еще такое наблюдение. Если посмотреть вакансии Data Analyst / Data Scientist на местном рынке труда, то с вероятностью 95% получим описание, в первую очередь, разработчика C или Java с соответствующей «специализацией». Если же аналогичные позиции посмотреть на indeed или seek, то требования явно смещаются в сторону именно анализа, а не создания инструментов. И тут уже фигурируют R, Python, RapidMiner, SPSS и т.п. и даже Excel, а также возникает необходимость в знании средств визуализации. А для публикаций аналитических данных, де-факто, стало стандартом предоставление материалов в формате Jupyter Notebook (как R так и Python).
    Могу предположить, что не в последнюю очередь все это связано с тем, что не программисту (экономисту / аналитику / финансисту / математику) не составит особого труда осилить Python или R в качестве рабочего инструмента, в отличие от тех же C или Java. Плюс бесплатность, кроссплатформенность кода, не притязательность в ресурсах и огромное количество доступных ресурсов.


    1. i_shutov Автор
      18.10.2017 10:37
      +1

      я бы сказал, что "в яблочко". когда смотришь на то, что есть у нас "в среднем" и то, что происходит сейчас за границей в области DS, разрыв в менталитете колоссальный.


  1. evseev
    18.10.2017 02:52

    Хотелось бы знать мнение тех, кто использует R. Скажем так, бытует мнение, что R очень медленный. Есть-ли подвижки в этом вопросе? В моем случае это один из самых критичных параметров. Ждать — не вариант. Данных очень много и бывает они обрабатываются по несколько суток подряд на i7 c 8 потоками.


    1. YuryFedin
      18.10.2017 10:15
      +1

      В описанном варианте скорее всего проблема не с R, а в общей организации процесса(системы). Возможно некоторые операции над данными стоит решать раньше, на уровне базы данных(хранения данных), а не на уровне анализа уже...


      1. evseev
        18.10.2017 12:37

        К сожалению все что можно было сделать уже сделано. Это просто тот случай когда данных очень много.


    1. i_shutov Автор
      18.10.2017 10:31

      Мнение — не самый надежный источник данных. Формально — да, base R медленный. Это интерпретатор, хоть и с компиляцией в байт-код.


      Однако, современный R — это, прежде всего, набор пакетов, который используется для работы. Большинство пакетов, критичных по времени исполнения, разрабатываются с применением C++. Векторизация, функциональное программирование, выбор правильных пакетов и алгоритмов, использование бэкендов на которые можно переложить рутинную тривиальную работу (БД или BigData движки), использование RCPP для критического кода — вот оптимальный способ применения R.


      Мы еще дополнительно применяем:


      1. еженедельный мониторинг интересных изменений в пакетах. Медленное старье без жалости выкидываем из набора инструментов и подходов. Типичный пример — пакет checkmate. Четкий упор на производительность заставил в прикладных задачах распрощаться и с базовыми средствами R и с пакетом assertive.
      2. Использование языка Go для "near real-time" тривиального препроцессинга потоковых данных.
      3. Пересели на Clickhouse в качестве бэкенда.
      4. Если задача позволяет, то делаем параллельные вычисления, в т.ч. и средствами R. На использование GPU пока не переходили, не было нужды.

      R — отнюдь не паллиатив. Но на бизнес-задачи он натягивается очень хорошо. Если действительно интересно, то можно отдельно обсудить задачу, которая есть у Вас. Может что-то смогу подсказать. Внимательная профилировка и анализ используемых функций порой позволяет ускорить выполнение на несколько порядков. Но нужна конкретика и лучше это делать не в треде, а через личку.


      1. evseev
        18.10.2017 12:55

        Спасибо за ответ. Пока используется Matlab. Но что бы им полноценно можно было пользоваться его нужно купить. Лицензионная чистота не обсуждается. Сейчас стоит вопрос либо купить Matlab, либо рассмотреть альтернативы.

        Скажем так. Из того, что я почерпнул в различных статьях R примерно равен по скорости с Python (стандартная реализация). Может быть чуть медленнее. Python в свою очередь медленнее C++,Java в 1000 раз. Matlab чуть-чуть не дотягивает до C++ и Java. Вопрос вот в чем. Можно-ли R «разогнать» до Matlab не сломав себе мозг?


        1. i_shutov Автор
          18.10.2017 14:08

          Наверное в чем-то можно. Примеры подходов я упоминал и выше и ниже. Но это все равно сферический ответ, потому что вопрос абстрактен. А еще может оказаться так, что какие-то вещи, наоборот, в Матлабе замучаешься делать, будет он не догоняемым, а безуспешно догоняющим. Можно еще и Julia посмотреть, но без сформулированной задачи это будет простая любознательность.


          1. evseev
            18.10.2017 15:26

            Matlab как раз таки устраивает и скоростью и удобством в данном конкретном случае. Не очень устраивает коммерческая лицензия в $2500 ;)

            Спасибо за ваши ответы.


            1. aback
              19.10.2017 18:10

              В R есть пакет sparklyr ( spark.rstudio.com/index.html ) — реализация технологии Spark из стека Apache. Это, по моему скромному мнению, быстрый Map-Reduce для больших данных за счет того, что данные обрабатываются в оперативной памяти. Плюс там же есть много ML. Скорость обработки существенно возрастает. Даже пример был на Хабре


              1. atikhonov
                20.10.2017 09:42

                В R, как обычно, не только sparklyr для Spark, есть еще 3 вариации,
                а пример, видимо этот:
                habrahabr.ru/post/308534


    1. WinDigo
      18.10.2017 10:54

      Не самый оригинальный ответ, конечно, но: «Зависит от задачи и умения писать быстрый код».
      Неплохие начальные советы можно найти здесь:
      Efficient R Programming: Efficient optimization (и вообще в целом познавательная книга).
      R Inferno (классический подбор основных ошибок при написании кода на R).

      Если работа ведётся с «таблицеподобными» данными, которые помещаются в оперативную память и важна именно скорость работы, то можно порекомендовать data.table, хотя я больше предпочитаю dplyr.


      1. i_shutov Автор
        18.10.2017 11:02

        на оригинальность я и не претендовал.
        про отдельный кейсы с производительностью я упоминал в предыдущих постах.


        Тут ведь действительно все зависит от задачи. Например, для работы с временем (а это бывает очень часто) избегайте использования as.POSIXct. Жутко медленная реализация. Но это никак не относится к табличному представлению.


        А еще вот это полезно: Extending R with C++. A Brief Introduction to Rcpp


        1. atikhonov
          18.10.2017 12:15

          WinDigo же про свой ответ писал (что у него не самый оригинальный ответ, но он такой «Зависит ...»


          1. i_shutov Автор
            18.10.2017 12:30

            Да уже потом увидел, что уровень вложенности тот же самый. Но мой ответ тоже не оригинальный, поэтому никакого подвоха и не увидел.


    1. WTYPMAH
      18.10.2017 15:02

      Как в любом функциональном интерпретируемом языке, скорость исполнения во львиной доле зависит от качества написания кода.
      Но и сам язык не стоит на месте в этом вопросе: есть пакеты / сервисы, соторые специально созданы для поддержки действительно BigData, многопоточности и т.д.


    1. i_shutov Автор
      20.10.2017 09:40

      Если честно, то описание состояния в целом "считает несколько суток подряд" никак не характеризует эффективность текущего способа решения.


      Простой пример. Сейчас в пуле задач есть задача анализа работы колл-центра (нескольких), построенного на астерисках. Астериски в продуктиве, поэтому что уже пишут в логи и cdr, с тем и приходится жить.


      Делаем на R, поскольку dial plan весьма сложный, информация нужна очень разная, а существующие open-source системы "статистики" дают разброс в показаниях на сотни процентов. Нет смысла ни разбираться в них, ни дотачивать.
      Возможно, после завершения задачи постараюсь опубликовать более подробно.


      Не далее как вчера пришлось оптимизировать обработку данных по очередям. 4 последовательных конвейера. Знакомство с принципами работы компьютера на уровне HW (когда-то на asm приходилось писать) + понимание внутренних структур и представлений в R + некие познания в алгоритмах позволили простым путем незначительных преобразований и перестановки последовательности действий ускорить каждый блок примерно в 3-4 раза. Итого, общее ускорение = 3.5^4 ~ 150 раз.


      Это мы еще даже не опускались на уровень C++, потенциальное распараллеливание и оптимизацию объемов данных исходя из бизнес-процессов.


      1. evseev
        20.10.2017 22:19

        В общем случае не характеризует. Но в данном случае заблудится просто негде.

        И вместо 150 раз хотелось бы видеть 1000. И так, что бы обойтись без С++, Java и тем более asm.