Цифровая экономика и экосистема R

    Если смотреть прессу, словосочетание «цифровая экономика» ожидается одним из популярных в ближайшие несколько лет.



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


    Почему необходимы новые подходы и инструменты?


    • Многократное увеличение объемов данных
    • Многократное увеличение источников данных
    • Многократное увеличение форматов обмена
    • Работа с неструктурированными данными
    • Смещение фокуса от исторического анализа к научному прогнозированию
    • Акцент на визуализацию и удобства восприятия
    • Многократное снижение времени на принятие решения вплоть до работы в режиме «реального времени»

    High Level Design (HLD) аналитической системы на базе R


    В эволюционного развития различных задач были пересмотрены различные методики и современные open-source средства. В результате сформировался достаточно универсальный стек общего назначения, общая архитектура которого выглядит следующим образом:



    Ключевые компоненты решения


    • RStudio — аналитическая экосистема (импорт, обработка, визуализация) на основе платформы R
    • Yandex ClickHouse — сверхбыстрая колоночно-ориентированная БД, оптимизированная для работы с временнЫми данными
    • Appache Drill — платформа для обеспечения унифицированного SQL доступа к BigData & NoSQL данным
    • Appache Airflow — оркестратор
    • «ETL» — платформа для приема разнообразной структурированной информации в относительно «чистой» форме с применением языка Go

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


    Ожидаемые бизнесом выходы от аналитической системы


    Как правило, большинство людей ожидают увидеть «отчеты», не детализируя, что именно они в это слово вкладывают. Экосистема R позволяет получать много больше типичных ожиданий:


    • генерация штатных отчетов в виде HTML (с элементами интерактива в виде встроенных htmlWidgets);
    • генерация штатных отчетов в виде PDF;
    • генерация различных выгрузок в различных форматах для M2M взаимодействия;
    • интерактивные аналитические приложения (дашборды);
    • элементы операционной аналитики (автоматическое внесение изменений в другие ИТ системы на основе полученных вычислений).

    Средой существования всех упомянутых типов отчетов и АРМ является Shiny Server\Connect Server. В платной или бесплатной редакции — зависит от требований, которые выходят за рамки аналитики и определяются требованиями по нагрузке, безопасности, централизованному управлению.


    5 бизнес-аргументов в пользу приведенного HLD


    1. Быстрые сроки ввода в эксплуатацию и минимальная стоимость владения за счет применения передовых апробированных open-source инструментов.
    2. Широчайший спектр функциональных возможностей по импорту, обработке и визуализации.
    3. Унифицированные высокопроизводительные технологии для данных различного масштаба данных (миллионы – сотни триллионов строк\ гигабайты – петабайты данных).
    4. Использование открытых общедоступных пакетов (>10 тыс штук), в том числе в части:
      • алгоритмической обработки, включая методы машинного обучения;
      • визуализации и создания интерактивных аналитических дашбордов на базе технологий HTML5+CSS+JS.
    5. Наличие «enterprise compliant» коммерческих версий доступных по модели подписки для ключевых open-source компонент.

    P.S.
    Практика раз за разом показывает, что цифровые преобразования упираются отнюдь не в возможности инструментов (open-source), а в неготовность людей менять восприятие, изучать новое, мыслить стратегически или просто страх перемен.


    Примером подобного типового пожелания является наличие «визуального» конструктора, так, чтобы только мышкой, без какого-либо программирования можно было получить результат неограниченной сложности. Однако, это красивое требование, культивируемое представителями BI визуализации, очень плохо сочетается с самим содержанием цифровых перемен которые ожидают человечество.


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


    В цифровом мире язык программирования становится таким же важным знанием, как язык международного общения. Интересно, что в отдельных западных компаниях, воспринимавшихся ранее как классическое производство, программирование становится важным навыком даже для менеджеров. Прекрасный пример подобной трансформации — компания GE, подразделение GE Digital. Ролик — Discover GE Digital: The Digital Industrial Company


    Предыдущий пост: RStudio Connect — «фейслифтинг» Shiny для корпоративного применения

    Поделиться публикацией

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

      0
      Всё прекрасно но без реальной экономики, цифровая не нужна. Кормить население бигдатой будите, а пенсии выдавать источниками данных и широчайшими возможностями?
        0

        Наверное, на этот вопрос тут ответ искать бесполезно.


        Тем не менее


        1. https://ria.ru/economy/20161206/1482988837.html. Вектор задан.
        2. Расточительное использование имеющихся ресурсов оправданий особых не имеет. Если в окна дует зимой — надо окна менять, а не батареи добавлять.
        3. Стратегия эффективного управления — своевременно использовать актуальную информацию из всех доступных источников. При этом нет необходимости покупать калькуляторы из чистого золота. Многие задачи решаются гораздо проще и быстрее, а с сэкономленными средствами можно своих сотрудников поддержать, а не кормить ватагу вендоров.
          0
          Вы видели какие калькуляторы для 1С ставят? Говорить можно что угодно показывать направление и вектора, но если смотреть курс движения по факту, то всё что заявляется это только болтовня. У нас «Стратегия эффективного управления» без обратной связи.
        +2
        ИМХО, на наше положение во времени на графике относительно наступления «золотого века» автор смотрит слишком оптимистично. Да и идти будет далеко не так гладко как нарисовано.
          0
          Если смотреть на иллюстрацию и не читать статью складывается ощущение, что статья только для того чтобы объяснить почему несмотря на 30 лет внедрения и два инвестиционных пузыря интегральная производительность труда в большинстве отраслей и не думала расти. А очень хочется получить деньги на ещё один пузырь, третий. :)
            –1
            Для тех кто любит кубики и мышку, рекомендую использовать KNIME. Это не идет в разрез с содержанием статьи и позволяет кому-то делать кубики на R, а кому-то из кубиков создавать цифровую экономику.)
              +2
              Я немного сбит с толку. Про понятие «цифровая экономика» или «digital business» в последнее время очень много пишется в различных СМИ и релизах компаий при внедрении тех или иных комплексов. Чаще всего это связано с автоматизацией неких процессов, учетом данных или принятии решений (или все вместе). Во главе всего чаще всего стоит сбор неких данных, их обработка и обратная связь в виде либо команды к действию (автоматизированное производство и т.п.), либо создание аналитического отчета, дающего некие рекомендации менеджменту. Во всяком случае, мне так кажется.

              Кроме того, как я не раз смог убедиться, у многих компаний эволюция документооборота происходит от некой учетной системы. У многих это 1С. Например, я несколько лет имел дело с крупных холдингом, где все началось именно с 1С Предприятие и автоматизации бухучета. Потом «прикрутили» адаптированные модули, связанные с управленческим учетом. С ростом компания обзавелась телеметрией (тысячи датчиков: уровень топлива, GPS, датчики на агрегатах) и решили делать бюджет больше не в Экселе. В результате, добавились сервера от Microsoft. Одним из «бонусов» шел Power BI, который позволяет создавать довольно неплохие отчеты уже после двух дней обучения обычного экономиста/бухгалтера.

              И вот у меня возник вопрос: «экосистема R» — как я понимаю, в приведенном мной примере лишь замена Power BI. Как это превратит бизнес в «цифровой бизнес»?

              Кстати, в этом холдинге уже больше года внедряется система под заголовком Digital Business. Если в двух словах, то это ИИ, который на основании данных с датчиков, плановых экономических показателей, занесенных алгоритмов, исторических данных и еще нескольких параметров будет сам готовить технологические карты и производственные планы. По ним уже будет формироваться производственный буджет. Контроль за выполнением бюджета будет осуществляться по данным 1С. Все это будет в «одной коробке» (конечно, не буквально). Таким образом, будет минимизирован человеческий фактор. С точки зрения этой компании именно так выглядит цифровой бизнес.
                0

                Евгений, спасибо за такой развернутый комментарий.


                Отвечаю по позициям.


                1. Понятие "цифровая экономика" сейчас находится в состоянии осмысления. Применительно к России с его содержанием можно ознакомиться здесь: Цифровая экономика — Правительство России, а в картинках — здесь
                2. Публикация является "бизнес-надстройкой" над предыдущими технологическими публикациями. "Экосистема R" это не PowerBI, а весь цифровой блок + АРМ + визуализация:
                  • частичный сбор (подхват всяких legacy, кустарщины, web-scrapping и прочий слаботипизированный сбор) и процессинг данных;
                  • выверка и чистка;
                  • исполнение различных вычислительных алгоритмов;
                  • реализация интерфейсов машина-человек, как в форме стационарных отчетов, так и в форме аналитических АРМ (тут и есть некоторое пересечение с PowerBI);
                  • опциональное управление внешними системами.
                    Можно провести аналогию с "бытовой" робототехникой, где все тупое железо работает под управлением Android + периферийные Arduino. R выполняет роль Android-а
                3. Насчет описания Digital Business — у нас на текущий момент ровно такое же понимание. В одной из инициатив как раз стоит задача контроля всех параметров технологического конвейера на предмет
                  • анализа отклонений,
                  • прогнозирования брака (конвейер каждый раз перестраивается под параметры выходной продукции, требуемой конкретному заказчику)
                  • оптимизации физико-технических параметров (например, температура нагрева, давление, скорость валков и пр..) с тем, чтобы снизить расход электроэнергии и снизить износ оборудования без ухудшения качества выходной продукции.
                0
                Было бы также полезно рассмотреть минусы связки R+Shiny, хотя, возможо, вы нашли свои work-around. На текущий момент основные проблемы берут корни в том, что Shiny является достаточно закрытой библиотекой в части управления backend'ом, соответственно это мешает сделать систему полноценной OLTP (я буду писать «невозможность», но это может быть «сложность», по которой у меня пока нет решения):

                1. Невозможность полноценной реализации monopoly access
                2. Невозможность реализации расширенной логики авторизации и поддержки ролевых моделей по RBAC
                3. Проверка ролевой модели доступа должна быть явно реализована в каждой точке доступа
                4. Невозможность реализации горизонтальной масштабируемости
                5. Невозможность частичного апдейта back-front end, только через полный апдейт с операционной блокировкой сервера.
                6. Однонаправленная транспортировка клиент/сервер по HTTP (невозможность реализации SingnalR или COMMET)
                7. Невозможность разделения back|fromt end разработки
                8. Тяжелая ресурсная стоимость UI-render Shiny пакета
                9. Высокая сложность отладки, зависимость базовых механизмов (логирование, access management, управление представлениями и т.д.)

                Реализация R+Shiny идеально подходит для систем, которые разработаны «под одного пользователя». Как только возникает необходимость обеспечить параллельную работу нескольких пользователей на одними и теми же данными — начинается хаос :(

                ИМХО — R необходимо использовать для тех вещей, для которых он создан: статистическая backend логика, аналитика и big data; прочая бизнес-логика, UI и тд. должны быть реализованы на других платформах. Благо Micrisoft подарил свет в конце тоннеля внедрив поддержку R в .NET и MS SQL.
                  0

                  Еще 2 комментария.


                  1. Пакет Shiny генерирует стандартный HTML, в базисном варианте на базе библиотеки bootstrap. Накладных расходов очень мало. И даже оставаясь в рамках пакетов R базовый интерфейс может быть расширен огромным количеством элементов не говоря о возможности добавления своих JS скриптов и CSS стилей. Если это в новинку, могу ссылок дать.


                  2. Насчет обмена данными между сервером и клиентом.
                    Приложения обеспечивают двусторонний обмен, методы реактивного программирования скрывают из app.R весь механизм обработки событий.
                    Достаточно удобно строятся динамические интерактивные web приложения.
                    Примеры: Plot interaction, Adding and removing UI objects, Table interaction

                  Shiny Server, который представляет собой NodeJS + R в бэкенде + пакет shiny для связки веба с R поддерживает широкий спектр протоколов обмена:


                  3.8 Specifying Protocols


                  Shiny Server provides a wide variety of techniques to keep the data in the web browser synchronized. The preferred technique, and the one most widely used, is the use of WebSockets. However, if WebSockets are not supported — either by some intermediate network between Shiny Server and your client, or by your client's web browser — then a fallback protocol will be used. In total, Shiny Server provides nine different methods of connecting to the server in real-time. In order of preference, they are:


                  • WebSocket
                  • XDR Streaming
                  • XHR Streaming
                  • iframe Eventsource
                  • iframe HTML File
                  • XDR Pollilng
                  • XHR Polling
                  • iframe XHR Polling
                  • JSONP Polling
                    0
                    1. Накладность расходов в том, что при вызове bootstrap генерируется весь компонент ui.R, вы не можете инициализировать вызов по обращению, это специфика реализации в shiny. Если у вас большое приложение даже без сложной логики инициализации, можете просто замерить время между вызовом приложения и загрузкой UI.

                    Также не совсем понятно, зачем в shiny так сильно порезали функционал AdminLTE. Теоретически, конечно, добраться к нему можно, но через ненужные костыли. Например, попробуйте добавить header right sidebar, который по-умолчанию есть в AdminLTE.

                    О том, что можно подключать js, css никто не спорит, но это уже не реализация самого shiny.

                    Я не говорю, что это все не возможно, но реализовано или приходится решать через столько костылей, что возникает вопрос — а стоит ли? Особенно когда система уходит на прод и нужно обеспечить удаленный bug-fixing, распределенную разработку и т.д.

                    2. Поддержка протокола как таковая и реализация — две большие разницы, имхо. Реактивность shiny обеспечивает односторонний обзервер только ui. Вы видите возможность реализации стандартного паттерна Наблюдатель серверной части в shiny? Например, обновление счетчика и вызов пуш-уведомления при отправке сообщения другим пользователем? Т.е. сам объект, ивент и обсервер за ним полностью на стороне серверной части, а не в ui. Такая задача потребует инициализации нескольких промежуточных reactivalues контейнеров, и нескольких обзерверов для связки, но это костыль, который очень далек от паттерна.

                    На всякий случай повторюсь, я не говорю, что shiny плох, или его не нужно использовать вообще (у меня самого сейчас на поддержке несколько реализаций с shiny, которые поддерживаются go-live у внешних клиентов). Но с усложнением задачи и архитектуры приложения, все минусы shiny вылазят очень больно и возникает необходимость реализации других вариантов.
                      0
                      1. Наличие компьютера на рабочем месте никак не означает, что его возможности используют хотя бы на 5%.
                        Поэтому основная задача — еще раз напомнить в приземлении на конкретику, что есть набор апробированных бесплатных инструментов (экосистема мне нравится больше, поскольку это именно слаженная совокупность), которые позволяют решать т.н. "головоломные" задачи бизнеса в части манипуляции почти произвольными данными и любыми масштабами. А про R & Shiny слышали очень немногие.


                      2. Задачу кросс-взаимодействия мы иногда решаем посредством реактивных внешних источников, в частности, db backend + reactivePoll. Вполне шустро и просто. Как раз и получается паттерн Наблюдатель в 3 строчки в голом его проявлении. А элементы UI используют данные из реактивного источника и автоматически актуализируются при его обновлении.
                  +1

                  В целом, во многом согласен. Серебряную пулю пока не изобрели. Спасает несколько моментов.


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


                  2. Коммерческие версии продуктов RStudio (или ветка Microsoft) во многом закрывают вопросы AAA, масштабирования, логирования, публикации и пр.


                  3. Пользователи бывают разные. Писателей (разработчиков\аналитиков) на порядки меньше Читателей (которым нужен результат в виде комиксов). Пока конфликтов не возникает. Ну а для больших проектов могут использоваться полноценные бэкенды. Например, для time-series статических данных (а это события, транзакции, измерения,...) решение Yandex Clickhouse оказалось очень конкурентноспособным по отношению к дорогим западным продуктам.


                  4. Приведенный подход не только не противоречит разработке специализированного UI на других языках\фреймворках, но даже поддерживает. Как только собран полнофункциональный комплекс, для элементов UI, плохо ложащихся на Shiny, можно и нужно разрабатывать специализированный интерфейс. При этом можно использовать все сделанные на R наработки, например, через REST API. В последней версии RStudio Connect этот функционал включен сразу в поставку. Однако ситуация такова, что в разработку можно будет пускать не 100%, а 20-40%.

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

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