Поводом для публикации послужила запись в блоге 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 источники, xmljson, txtcsvlog, xlsx, REST API);
- соотнести данные из разных источников друг с другом и привести к удобоваримому для ML алгоритмов виде;
- придумать мат. модель описываемых бизнес-сущностей, посчитать;
- отрисовать во всевозможных срезах и представлениях, нагенерировать разных отчетов в менджерском виде (docx, xlsx, pptx, pdf) с описанием текущей ситуации и рекомендациями.
Классификация по кейсам не надумана, а получилась на основе реальных потребностей бизнеса (наука и чистый MLAIDL отдельно). Наверное, в ближайшее время можно будет «в скриншотах» поделиться про решение 2-3 задачек.
Практика показывает, что R + Shiny позволяют «щелкать» подобные задачи весьма и весьма эффективно. Если есть задачи, имеет смысл посмотреть на эти инструменты более внимательно.
Предыдущая публикация — Конструктивные элементы надежного enterprise R приложения.
Автор: i_shutov
