Поводом для публикации послужила запись в блоге 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 приложения.