El motivo de la publicación fue la entrada del blog de Rstudio: "Shiny 1.1.0: Scaling Shiny with async", que puede pasar fácilmente, pero que agrega un ladrillo muy significativo a la tarea de usar R para tareas comerciales. En realidad, en la versión de desarrollo de la brillante, la asincronía apareció hace aproximadamente un año, pero fue algo frívola y "imaginaria": es la versión de desarrollo. La transferencia a la sucursal principal y la publicación en CRAN es una confirmación importante de que muchos problemas fundamentales están pensados, resueltos y probados, puede transferirlos de manera segura a un lugar productivo y de uso.
¿Y qué más hay en R, excepto el "diamante", que le permite convertirlo en una herramienta analítica universal para tareas prácticas?
Es una continuación de publicaciones anteriores .
Porque brillante
Si hablamos de la aplicación práctica de R para diversos procesamientos de datos en los procesos comerciales de una empresa real, los principales usuarios de los resultados analíticos serán gerentes en varios niveles. Dejamos la capa de análisis de DS detrás de los corchetes; necesitan una amplia gama de herramientas, incluido el acceso directo a la base de datos. Ellos mismos pueden y pueden hacer todo. La estación de trabajo gráfica basada en web será una ayuda conveniente, pero no un diferenciador clave.
A diferencia de un especialista en DS, un gerente ordinario necesita una interfaz conveniente que le brinde toda la información (histórica, analítica, predictiva, etc.) necesaria para tomar una decisión o informar a la gerencia. En realidad, la interfaz de usuario es el "alfa y omega" de cualquier sistema empresarial. Nadie mirará nunca debajo del capó (bueno, tal vez solo en las etapas largas y dolorosas de RFI-RFP). Nadie entenderá nunca salir a experimentar más allá de los límites de su historia de usuario especificada en las responsabilidades del trabajo. Nadie reflexionará sobre el tema de protocolos, algoritmos, validación y precisión.
Con Shiny, puede dibujar una interfaz muy ramificada que incluirá texto, gráficos, tablas, casi todos los elementos html estructurales (marco de arranque). JS le permite agregar ajustes complejos a la interfaz web, CSS le permite crear un estilo personalizado. También es muy fácil hacer en R varias cosas importantes que cambian cualitativamente el trabajo con la interfaz, a saber, la generación dinámica de contenido. Aquí estamos hablando de:
- datos tabulares y gráficos que pueden cambiarse por temporizador o solicitud del usuario y modificarse cuando se muestran según acc. con restricciones dinámicas (por ejemplo, ocultar asteriscos de parte de datos pers.);
- la composición de los elementos en la interfaz (dependiendo de la lógica del proceso de negocio, puede agregar / eliminar botones, marcadores, etc. durante la ejecución);
- el contenido de estos elementos (por ejemplo, llenar listas de valores disponibles basados en datos cargados);
- gestión inteligente del contenido de los elementos de control (por ejemplo, la selección de valores de una lista determinará el contenido de otros elementos disponibles para la selección);
- implementaciones del modelo de rol a nivel de datos (por ejemplo, dependiendo del rol, solo ciertos subconjuntos de un elemento pueden estar disponibles)
Sin interfaz, sin sistema. Y exactamente en este punto se vuelve casi obvio por qué R, no Python. Debido a que R tiene Shiny (paquetes + tiempo de ejecución) con el que puede hacer directamente R en las interfaces de usuario para sistemas de procesamiento de datos de casi cualquier grado algorítmico de complejidad, pero python, por desgracia, no tiene ese anuncio en el futuro cercano.
Asincronía brillante y por qué es tan importante
La aplicación brillante en sí se ejecuta secuencialmente, para cada enlace de URL (aplicación brillante) en el servidor de código abierto de servidor brillante, se eleva un proceso R de backend, que sirve los cálculos de acuerdo con la actividad del usuario. Hasta el último lanzamiento, la versión de código abierto de shiny era completamente sincrónica. Esto significó que cualquier cálculo extenso dentro del código "congeló" la respuesta de la aplicación para todos los usuarios que la usaron al mismo tiempo. Naturalmente, en la versión empresarial de Shiny Server Pro, el problema de la gestión de sesiones de usuario se ha resuelto. El consumidor tuvo la oportunidad de elegir si desea obtener todo lo que le gusta durante la aplicación empresarial en 5 segundos o complementarlo por sí mismo.
En principio, tal característica de las aplicaciones brillantes podría nivelarse mediante:
- publicar aplicaciones para diferentes usuarios en diferentes URL, incluido, por ejemplo, nombre de usuario (un código, los enlaces se realizan en el servidor brillante)
- realizar cálculos complejos por adelantado, en un proceso de fondo diferente
- La simbiosis óptima entre las capacidades de procesamiento de datos del backend y el posprocesamiento en R.
Sin embargo, ahora se ha vuelto mucho más conveniente. La asincronía a través de los mecanismos de promesa permite que un par de líneas generen hilos R adicionales en los que se realizarán cálculos intensivos en recursos, sin afectar el rendimiento del flujo y el tiempo de respuesta de la aplicación brillante principal. Entonces, formalmente, el problema del trabajo paralelo de muchos usuarios también puede considerarse resuelto en la versión de código abierto. La hora de tomar café y esperar el resultado no se trata de Shiny.
Estudios de casos típicos de R
A menudo les gusta hablar sobre modelos y ML en el marco de las aplicaciones empresariales, pero es posible abordar estas tareas solo después de digitalizar la tarea y preparar los datos. Y todo esto se puede hacer en el marco de R.
Naturalmente, R no siempre es suficiente con uno, dependiendo de la escala de la tarea y la cantidad de datos, pueden requerirse tanto el back-end de apertura de código abierto como el subsistema de adquisición de datos de código abierto. Pero esto no cambia nada, ya que el usuario solo trabaja con la Aplicación del Usuario (ver arriba).
Muchas de las historias anteriormente presentaban productos especiales de "grandes vendedores" que se han introducido a lo largo de los años a miles de millones de dólares. Pero ahora todo se resuelve mucho más fácil y más barato. La práctica muestra que el 99% de las tareas comerciales se encuentran en uno de los tres casos que se describen a continuación.
Caso No. 1. Analítica operacional
Una tarea típica, que es crear un ciclo de retroalimentación operacional. Las etapas principales:
- recopilación de datos multiprotocolo y multiformato en un modo cercano al real (de acuerdo con los detalles de los procesos comerciales, el delta óptimo es de varias decenas de minutos) de varios sistemas de diferentes fabricantes y libros de referencia en varios formatos. Por ejemplo, pueden ser datos del equipo de bombeo, datos de varios escáneres, registros de operación del sistema
- Limpieza, normalización y enriquecimiento con datos de otras fuentes y directorios.
- Análisis de la serie temporal obtenida. Aquí está el cálculo de pronósticos y el análisis de las desviaciones de los valores pronosticados, y el análisis de anomalías, y varios antifraude y predicción de posibles problemas (por ejemplo, la temperatura en los refrigeradores comenzó a aumentar lentamente. Mientras los indicadores están en la configuración, pero la tendencia es obvia: el producto puede ir mal pronto)
- cálculo de cualquier valor KPI instantáneo (dentro de los límites de la imaginación de los analistas de negocios)
- bucle de retroalimentación multicanal: generación de informes, actualización de paneles, informes automáticos a sistemas externos (por ejemplo, monitoreo), ejecución automática de comandos en sistemas inferiores.
Instancias clásicas:
- control de diversos equipos,
- seguimiento de procesos comerciales largos,
- Análisis de ventas "en línea",
- análisis de trabajo del centro de llamadas,
- análisis general de los sistemas de control de acceso (por ejemplo, ¿hubo una aplicación en SAP para el acceso de un determinado empleado en un momento determinado a un lugar determinado, o lo que ACS ve como una anomalía?).
Existen muchos problemas de este tipo y todo se puede resolver mediante el ecosistema R.
Caso No. 2. Consolidación de Excel
La práctica muestra que Excel en la gran mayoría de las empresas es la herramienta principal para los analistas de negocios. Para tareas simples, esto todavía es aceptable; para tareas complejas con una gran cantidad de datos, este enfoque se convierte en un agujero negro, que absorbe cualquier cantidad de recursos y no da nada en la producción.
Tarea típica:
MIENTRAS (! Despedido) HACER {
- recopilar datos sucios de una gran cantidad de fuentes diferentes, principalmente manuales de Excel;
- validarlo todo repetidamente (validación técnica y lógica de las fuentes + validación cruzada lógica entre las fuentes);
- realizar cálculos, consolidaciones, distribuciones;
- hacer muchas descargas diferentes para entregar a otras unidades;
- hábilmente informe sobre el trabajo realizado.
}
Y todo esto se realiza en un modo y procesamiento de emergencia constante.
Instancias clásicas:
- Análisis para sistemas integrados de gestión de proyectos (KSUP), cuando no puede salir con un solo proyecto. La gran mayoría de los contratistas informa lo mejor que pueden, pero necesitamos hacer una imagen consolidada y gestionar los riesgos.
- Sistemas de pedidos y distribución (comercio y logística). Qué llevar, cómo distribuir, cómo recoger los pedidos, cómo descomponerlos. También es bueno pronosticar las compras.
Caso No. 3. Sistemas de soporte de decisiones
Aquí es aún más simple y cercano al ML puro:
- recopilar información desde donde pueda (todo tipo de fuentes compatibles con odbc y no del todo odbc, xml \ json, txt \ csv \ log, xlsx, REST API);
- correlacionar datos de diferentes fuentes entre sí y dar lugar a una forma digerible para algoritmos de ML;
- inventa una estera. un modelo de las entidades comerciales descritas, para calcular;
- dibuje varios cortes y vistas, genere varios informes en forma gerencial (docx, xlsx, pptx, pdf) con una descripción de la situación actual y recomendaciones.
La clasificación de los casos no se inventó, pero resultó en función de las necesidades reales del negocio (ciencia y ML \ AI \ DL por separado). Probablemente en el futuro cercano será posible "compartir capturas de pantalla" sobre la resolución de 2-3 problemas.
La práctica muestra que R + Shiny le permite "hacer clic" en esas tareas de manera muy, muy eficiente. Si hay tareas, tiene sentido mirar estas herramientas más de cerca.
Publicación anterior: características de una sólida aplicación empresarial R.