Поводом для публикации послужила запись в блоге Rstudio: «Shiny 1.1.0: Scaling Shiny with async», которая может очень легко пройти мимо, но которая добавляет очень весомый кирпичик в задаче применения R для задач бизнеса. На самом деле, в dev версии shiny асинхронность появилась примерно год назад, но это было как бы несерьезно и «понарошку» — это же dev версия. Перенос в основную ветку и публикация на CRAN является важным подтверждением, что многие принципиальные вопросы продуманы, решены и протестированы, можно спокойно переносить в продуктив и пользоваться.


А что еще есть в R, кроме «бриллианта», что позволяет превратить его в универсальный аналитический инструмент для практических задач?


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


Почему Shiny


Если говорить о практическом применении R для различной обработки данных в бизнес-процессах реальной компании, то основными пользователями аналитических результатов будут выступать менеджеры различного уровня. Слой DS аналитиков мы оставляем за скобками, им нужен широкий спектр инструментов, включая прямодй доступ в БД. Они сами все могут и умеют. Графический web-based АРМ будет являться удобным подспорьем, но никак не ключевым дифференциатором.


В отличии от DS специалиста, обычному менеджеру нужен удобный интерфейс, который будет снабжать его всей информацией (исторической, аналитической, прогнозной и т.д.), необходимой для принятия решения или отчета перед руководством. Собственно говоря, интерфейс Пользователя есть «альфа и омега» любой enterprise Системы. Никто и никогда не будет заглядывать под капот (ну разве что только на долгих и мучительных этапах RFI-RFP). Никто и никогда не будет разбираться выходить экспериментировать за границами своих user-story, указанных в должностных обязанностях. Никто и никогда не будет размышлять на тему протоколов, алгоритмов, проверки достоверности и точности.


С помощью Shiny можно нарисовать весьма разветвленный интерфейс, который будет включать в себя текст, графику, таблицы, почти все структурные html элементы (bootstrap framework). JS позволяет добавить сложную тюнинг веб интерфейса, CSS — сделать произвольное стилевое оформление. Также весьма несложно на R сделать несколько важных вещей, которые качественно меняют работу с интерфейсом, а именно, динамическая генерация контента. Тут речь идет о:


  • табличных и графических данных, изменяемых по таймеру или запросу пользователя и модифицируемых при отображении в соотв. с динамическими ограничениями (например, сокрытие звездочками части перс. данных);
  • составу элементов в интерфейсе (в зависимости от логики бизнес-процесса можно в ходе исполнения добавить\убрать кнопки, закладки, пр..);
  • содержанию этих элементов (например, наполнение списков доступных значений на основании подгруженных данных);
  • интеллектуальное управление содержанием управляющих элементов (например, выбор значений из одного списка будет определять доступное для выбора содержимое других элементов);
  • реализации ролевой модели на уровне данных (например, в зависимости от роли могут быть доступны только определенные подмножества того или иного элемента)

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


Асинхронность shiny и почему это так важно


Само по себе shiny приложение исполняется последовательно, на каждую url ссылку (shiny app) в shiny server open-source поднимается один backend R процесс, который обслуживает вычисления в соответствии с пользовательской активностью. Вплоть до последнего релиза open-source версия shiny была полностью синхронной. Это означало, что любое длительное вычисление в рамках кода «замораживало» отклик приложения для всех пользователей, которые одновременно им пользовались. Естественное, что в enterprise версии Shiny Server Pro вопрос управления пользовательскими сессиями был решен. У Потребителя была возможностью выбора — получить ли за 5 секунд все что любят при enterprise применении или же дополнить самому.


В принципе, такую особенность shiny приложений можно было нивелировать путем:


  • разнесения приложений для разных пользователей на разные url, включающие, например, имя пользователя (код один, в ос делаются линки на shiny сервере)
  • проведения сложных вычислений заблаговременно, в другом фоновом процессе
  • оптимального симбиоза между возможностями по обработке данных на сторое бэкенда и постпроцессинга в R.

Однако, теперь стало все многократно удобнее. Асинхронность через механизмы promise(s) позволяет парой строчек порождать дополнительные R потоки в которых будут проводится ресурсоемкие вычисления, без влияния на производительность потока и время отклика основного shiny приложения. Так что формально вопрос параллельной работы многих пользователей можно считать решенным и в open-source версии тоже. Время пить кофе и ждать результата — это не про Shiny.


Типичные истории практического применения R


Говорить о моделях и ML в рамках enterprise применения любят много и часто, но реально к решению этих задач можно подступаться только после оцифровки задачи и подготовки данных. И это все можно сделать в рамках R.
Естественно, что одним R не всегда обходится, в зависимости от масштаба задачи и объема данных может потребоваться и open-source olap backend и open-source подсистема сбора данных. Но это ничего не меняет, поскольку пользователь работает только с Приложением Пользователя (см. выше).
На многие из историй ранее выпускались специальные продукты от «больших вендоров», внедряемые годами за миллиардные бюджеты. Но теперь все решается гораздо проще и дешевле. Практика показывает, что 99% задач бизнеса ложатся в один из трех нижеописанных кейсов.


Кейс №1. Операционная аналитика


Типичная задача, которая заключается в создании оперативного контура обратной связи. Основные этапы:


  • мультипротокольный и мультиформатный сбор данных в режиме, близком к реальному (в соотв. со спецификой бизнес-процессов оптимальная дельта составляет единицы-десятки минут) из различных систем разных производителей и справочников по различным форматам. Например, это могут быть данные от насосного оборудования, данные с различных сканеров, логи работы систем
  • чистка, нормализация и обогащение данными из иных источников и справочников
  • анализ полученных временных рядов. тут и расчет прогнозов и анализ отклонений от прогнозируемых значений, и анализ аномалий, и различный антифрод и прогнозирование возможных проблем (например, температура в холодильниках начала медленно повышаться. пока показатели в уставках, но тренд очевиден — товар может скоро испортиться)
  • расчет всяких мгновенных значений KPI (в границах фантазии бизнес-аналитиков)
  • мультиканальное замыкание обратной связи: формирование отчетов, обновление дашбордов, автоматический репортинг во внешние системы (напр., мониторинг), автоматическое исполнение команд в низлежащих системах.

Классические экземпляры:


  • контроль различного оборудования,
  • мониторинг длительных бизнес-процессов,
  • «онлайн» анализ продаже,
  • анализ работы колл-центра,
  • общий анализ систем контроля доступа (например, была ли заявка в SAP на доступ определенного сотрудника в определенное время в определенное место, или то, что видит СКУД — аномалия?).

Таких задач масса и все может быть решено средствами экосистемы R.


Кейс №2. Excel консолидация


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


Типичная задача:
WHILE (!Fired) DO {


  • собрать грязные данные из массы различных источников, по большей части excel ручного ведения;
  • многократно провалидировать это все (техническая и логическая валидация источников + логическая кросс-валидация между источниками);
  • провести расчеты, консолидации, распределения;
  • сделать массу различных выгрузок для выдачи наружу другим подразделениям;
  • ловко отчитаться о проделанной работе.
    }
    И это все исполняется в режиме постоянного аврала и переработок.

Классические экземпляры:


  • Аналитика для комплексных систем управления проектами (КСУП), когда одним msproject не отделаешься. Масса подрядчиков отчитывается как может, а надо делать сводную картину и управлять рисками.
  • Системы заказа и дистрибуции (торговля и логистика). Что куда везти, как распределять, как собирать заказы, как их декомпозировать. А еще неплохо и спрогнозировать закупки.

Кейс №3. Системы поддержки принятия решений


Тут еще проще и наиболее приближено к чистому ML:


  • собрать информацию откуда можно (всевозможные odbc и не совсем odbc compliant источники, xml\json, txt\csv\log, xlsx, REST API);
  • соотнести данные из разных источников друг с другом и привести к удобоваримому для ML алгоритмов виде;
  • придумать мат. модель описываемых бизнес-сущностей, посчитать;
  • отрисовать во всевозможных срезах и представлениях, нагенерировать разных отчетов в менджерском виде (docx, xlsx, pptx, pdf) с описанием текущей ситуации и рекомендациями.

Классификация по кейсам не надумана, а получилась на основе реальных потребностей бизнеса (наука и чистый ML\AI\DL отдельно). Наверное, в ближайшее время можно будет «в скриншотах» поделиться про решение 2-3 задачек.


Практика показывает, что R + Shiny позволяют «щелкать» подобные задачи весьма и весьма эффективно. Если есть задачи, имеет смысл посмотреть на эти инструменты более внимательно.


Предыдущая публикация — Конструктивные элементы надежного enterprise R приложения.

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


  1. CheY
    03.07.2018 18:16

    А неужели и правда ни для python'а, ни для других языков, удобных для DS, нет ничего похожего на shiny? Я не копал в эту сторону, но ведь это крайне удобная вещь — странно, что то же сообщество python'а, которое любит перенимать идеи из R, не переняло и это…


    1. pr1k0l
      03.07.2018 19:45

      Как раз сегодня искал ответ на вопросы в статье и нашёл для себя https://nteract.io/ – интерактивные блокноты с довольно богатыми возможностями по визуализации и условно безграничными по предобработке данных.

      В качестве рантайма можно использовать Python, NodeJS, R из коробки. Если заморочиться, то хоть весь список отсюда: https://github.com/jupyter/jupyter/wiki/Jupyter-kernels.


      1. i_shutov Автор
        03.07.2018 21:31

        Про интерактивные ноутбуки спору нет — они есть для всех передовых стеков. Речь про веб приложение для "менеджера". Там нужно именно функциональное приложение, заточенное на конкретные варианты использования. А всю кухню надо засовывать под капот и не показывать.


        Я предварительно долго искал под питон, но так и не нашел аналога shiny. Dash относительно новый и не про это.


    1. andmkv
      04.07.2018 22:03

      На python есть достойный аналог Shiny — называется Dash plot.ly/products/dash
      Тоже опенсорс с коммерческой версией, по возможностям — примерно то же самое что Шайни.
      Кстати на основной их продукт — библиотеку plotly — тоже стоит обратить внимание как R-водам, так и сторонникам Python


      1. i_shutov Автор
        05.07.2018 11:08

        Ну, вообще-то, не аналог.
        Shiny — среда и пакеты для полноценной разработки аналитических веб приложений на R. См. набор функций на https://shiny.rstudio.com/reference/shiny/1.1.0/ и оду Shiny от одной из ведущих западных DS компаний: https://www.mango-solutions.com/blog


        Dash — маленький частный случай для визуализации данных для аналитиков.


  1. Akogay
    03.07.2018 21:19

    Повелись на данную серию статей о простоте и легкости R Shiny.
    1) куча граблей по дороге
    2) очень долго создавать более менее сложное приложение


    Богатые конторы покупают enterprise ПО.
    БЕДНЫЕ используют POWER BI


    1. i_shutov Автор
      03.07.2018 21:44

      1. Learning curve весьма велика при выходе на профессиональный уровень. И неважно что это, программирование, кулинария, танцы, ...
      2. Наша практика говорит о другом. Грабли есть всегда, но в shiny их не так уже и много. Аналитическое приложение можно создавать как очень быстро, так и очень долго. Все зависит от требований. Но не было почти ни одного требования, которые нельзя было сделать на R+Shiny.
      3. Тот, кто жил в жестких рамках вендорского ПО (венгерские грабли = фича) и знает, как надо просить годами что-то добавить или изменить (часто безрезультатно), вряд-ли будет говорить об enterprise ПО как о панацее.

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