La raison de la publication était le billet de blog Rstudio: «Shiny 1.1.0: Scaling Shiny with async», qui peut très facilement passer, mais qui ajoute une brique très importante à la tâche d'utiliser R pour les tâches commerciales. En fait, dans la version dev de shiny, l'asynchronie est apparue il y a environ un an, mais c'était un peu frivole et «imaginaire» - c'est la version dev. Le transfert vers la branche principale et la publication sur CRAN est une confirmation importante que de nombreux problèmes fondamentaux sont pensés, résolus et testés, vous pouvez les transférer en toute sécurité vers un environnement productif et d'utilisation.

Et qu'y a-t-il d'autre dans R, à l'exception du «diamant», qui vous permet de le transformer en un outil d'analyse universel pour des tâches pratiques?

Il s'agit d'une continuation des publications précédentes .

Pourquoi brillant

Si nous parlons de l'application pratique de R pour divers traitements de données dans les processus commerciaux d'une entreprise réelle, les principaux utilisateurs des résultats analytiques seront des gestionnaires à différents niveaux. Nous laissons la couche d'analyse DS derrière les crochets; ils ont besoin d'une large gamme d'outils, y compris un accès direct à la base de données. Ils peuvent et peuvent tout faire eux-mêmes. La station de travail graphique basée sur le Web sera une aide pratique, mais pas un différenciateur clé.

Contrairement à un spécialiste DS, un gestionnaire ordinaire a besoin d'une interface pratique qui lui fournira toutes les informations (historiques, analytiques, prédictives, etc.) nécessaires pour prendre une décision ou faire rapport à la direction. En fait, l'interface utilisateur est "l'alpha et l'oméga" de tout système d'entreprise. Personne ne regardera jamais sous le capot (enfin, peut-être seulement aux étapes longues et douloureuses du RFI-RFP). Personne ne comprendra jamais sortir pour expérimenter au-delà des limites de son histoire d'utilisateur spécifiée dans les responsabilités du travail. Personne ne réfléchira jamais au sujet des protocoles, algorithmes, validation et précision.

En utilisant Shiny, vous pouvez dessiner une interface très ramifiée qui comprendra du texte, des graphiques, des tableaux, presque tous les éléments structurels html (framework bootstrap). JS vous permet d'ajouter un réglage complexe à l'interface Web, CSS vous permet de créer un style personnalisé. Il est également très facile de faire sur R plusieurs choses importantes qui changent qualitativement le travail avec l'interface, à savoir la génération dynamique de contenu. Ici, nous parlons:

• données tabulaires et graphiques qui peuvent être changées par minuterie ou demande de l'utilisateur et modifiées lorsqu'elles sont affichées en acc. avec des restrictions dynamiques (par exemple, masquer les astérisques d'une partie des données personnelles);
• la composition des éléments de l'interface (selon la logique du processus métier, vous pouvez ajouter / supprimer des boutons, des signets, etc. lors de l'exécution);
• le contenu de ces éléments (par exemple, remplir des listes de valeurs disponibles en fonction des données chargées);
• gestion intelligente du contenu des éléments de contrôle (par exemple, la sélection de valeurs dans une liste déterminera le contenu des autres éléments disponibles pour la sélection);
• implémentations du modèle de rôle au niveau des données (par exemple, selon le rôle, seuls certains sous-ensembles d'un élément peuvent être disponibles)

Pas d'interface - pas de système. Et exactement à ce stade, il devient presque évident pourquoi R, pas python. Parce que R a Shiny (packages + runtime) avec lequel vous pouvez directement faire R sur les interfaces utilisateur pour les systèmes de traitement de données de presque n'importe quel degré de complexité algorithmique, et python, hélas, n'aura pas une telle annonce dans un avenir proche.

Asynchrone brillant et pourquoi il est si important

L'application brillante elle-même est exécutée séquentiellement, pour chaque lien URL (application brillante) dans le serveur open source brillant, un processus R de backend augmente, qui sert les calculs en fonction de l'activité de l'utilisateur. Jusqu'à la dernière version, la version open-source de shiny était complètement synchrone. Cela signifiait que tout calcul long dans le code "gelait" la réponse de l'application pour tous les utilisateurs qui l'utilisaient en même temps. Naturellement, dans la version entreprise de Shiny Server Pro, le problème de gestion des sessions utilisateur a été résolu. Le consommateur a eu la possibilité de choisir d'obtenir tout ce qu'il souhaite pendant l'application d'entreprise en 5 secondes ou de le compléter lui-même.

En principe, une telle caractéristique des applications brillantes pourrait être nivelée par:

• publier des applications pour différents utilisateurs dans différentes URL, y compris, par exemple, le nom d'utilisateur (un code, les liens sont créés sur un serveur brillant)
• effectuer des calculs complexes à l'avance, dans un processus d'arrière-plan différent
• la symbiose optimale entre les capacités de traitement des données du backend et le post-traitement dans R.

Cependant, il est maintenant devenu beaucoup plus pratique. L'asynchronie via les mécanismes de promesse (s) permet à quelques lignes de générer des threads R supplémentaires dans lesquels des calculs gourmands en ressources seront effectués, sans affecter les performances du flux et le temps de réponse de l'application brillante principale. Donc, formellement, le problème du travail parallèle de nombreux utilisateurs peut également être considéré comme résolu dans la version open-source. Il n'est pas temps de boire du café et d'attendre le résultat.

Études de cas typiques de R

Ils aiment souvent et souvent parler de modèles et de ML dans le cadre d'applications d'entreprise, mais il n'est possible d'aborder ces tâches qu'après avoir numérisé la tâche et préparé les données. Et tout cela peut se faire dans le cadre de R.
Naturellement, R n'est pas toujours suffisant avec un, en fonction de l'échelle de la tâche et de la quantité de données, le backend olap open source et le sous-système d'acquisition de données open source peuvent être nécessaires. Mais cela ne change rien, car l'utilisateur ne travaille qu'avec l'application utilisateur (voir ci-dessus).
Beaucoup d'histoires présentaient auparavant des produits spéciaux de «grands fournisseurs» qui ont été introduits au fil des ans pour des milliards de dollars. Mais maintenant, tout est résolu beaucoup plus facilement et moins cher. La pratique montre que 99% des tâches commerciales entrent dans l'un des trois cas décrits ci-dessous.

Cas n ° 1. Analytique opérationnelle

Une tâche typique consiste à créer une boucle de rétroaction opérationnelle. Les principales étapes:

• collecte de données multi-protocoles et multi-formats dans un mode proche du réel (selon les spécificités des processus métier, le delta optimal est de plusieurs dizaines de minutes) à partir de différents systèmes de différents fabricants et ouvrages de référence sous différents formats. Par exemple, il peut s'agir de données provenant de l'équipement de pompage, de données provenant de divers scanners, de journaux de fonctionnement du système
• nettoyage, normalisation et enrichissement avec des données provenant d'autres sources et répertoires
• analyse des séries chronologiques obtenues. voici le calcul des prévisions et l'analyse des écarts par rapport aux valeurs prévues, et l'analyse des anomalies, et divers antifraude et la prévision de problèmes possibles (par exemple, la température dans les réfrigérateurs a commencé à augmenter lentement. Alors que les indicateurs sont dans les paramètres, mais la tendance est évidente - le produit peut bientôt mal tourner)
• calcul de toutes les valeurs KPI instantanées (dans les limites de l'imagination des analystes commerciaux)
• boucle de rétroaction multicanal: génération de rapports, mise à jour des tableaux de bord, rapports automatiques aux systèmes externes (par exemple surveillance), exécution automatique des commandes dans les systèmes inférieurs.

Instances classiques:

• contrôle de divers équipements,
• suivi des processus métiers longs,
• Analyse des ventes «en ligne»,
• analyse du travail du centre d'appels,
• analyse générale des systèmes de contrôle d'accès (par exemple, y avait-il une application dans SAP pour l'accès d'un certain employé à un certain moment à un certain endroit, ou qu'est-ce qu'ACS considère comme une anomalie?).

Il existe de nombreux problèmes de ce type et tout peut être résolu grâce à l'écosystème R.

Cas n ° 2. Consolidation Excel

La pratique montre qu'Excel dans la grande majorité des entreprises est le principal outil pour les analystes commerciaux. Pour les tâches simples, cela est toujours acceptable; pour les tâches complexes avec beaucoup de données, cette approche se transforme en trou noir, qui aspire n'importe quelle quantité de ressources et ne donne rien en sortie.

Tâche typique:
PENDANT QUE (! Tiré)

• collecter des données sales à partir d'une multitude de sources différentes, principalement Excel manuel;
• valider le tout à plusieurs reprises (validation technique et logique des sources + validation croisée logique entre les sources);
• effectuer des calculs, des consolidations, des distributions;
• faire beaucoup de déchargements différents pour la livraison à d'autres unités;
• rendre compte habilement du travail accompli.
  }
  Et tout cela est effectué en mode et traitement d'urgence constants.

Instances classiques:

• Analytics pour les systèmes de gestion de projet intégrés (KSUP), lorsque vous ne pouvez pas vous lancer avec un seul projet ms. La masse des sous-traitants rend compte du mieux qu'ils peuvent, mais nous devons dresser un tableau consolidé et gérer les risques.
• Systèmes de commande et de distribution (commerce et logistique). Que transporter, comment distribuer, comment collecter les commandes, comment les décomposer. Il est également bon de prévoir les achats.

Cas n ° 3. Systèmes d'aide à la décision

Ici, c'est encore plus simple et plus proche du ML pur:

• recueillir des informations d'où vous le pouvez (toutes sortes de sources compatibles ODBC et pas tout à fait ODBC, xml \ json, txt \ csv \ log, xlsx, API REST);
• corréler les données de différentes sources entre elles et conduire à une forme digestible pour les algorithmes ML;
• venir avec un tapis. un modèle des entités commerciales décrites, à calculer;
• dessiner différentes tranches et vues, générer divers rapports sous forme managériale (docx, xlsx, pptx, pdf) avec une description de la situation actuelle et des recommandations.

La classification des cas n'a pas été inventée, mais s'est révélée basée sur les besoins réels de l'entreprise (science et ML \ AI \ DL purs séparément). Dans un futur proche, il sera probablement possible de "partager des captures d'écran" pour résoudre 2-3 problèmes.

La pratique montre que R + Shiny vous permet de «cliquer» sur ces tâches très, très efficacement. S'il y a des tâches, il est logique d'examiner ces outils de plus près.

Article précédent - Caractéristiques d'une application d'entreprise R robuste .