Cada día surgen ideas y reuniones sobre qué otros procesos se pueden automatizar en empresas de distintos tamaños. Pero además de que se puede dedicar mucho tiempo a crear un modelo, hay que dedicarlo a evaluarlo y comprobar que el resultado obtenido no es aleatorio. Después de la implementación, cualquier modelo debe ser monitoreado y verificado periódicamente.
Y estas son todas las etapas que hay que completar en cualquier empresa, independientemente de su tamaño. Si hablamos de la escala y el legado de Sberbank, el número de ajustes aumenta significativamente. A finales de 2019, Sber ya había utilizado más de 2000 modelos. No basta simplemente con desarrollar un modelo, es necesario integrarlo con sistemas industriales, desarrollar data marts para construir modelos y asegurar el control de su funcionamiento en el cluster.
Nuestro equipo está desarrollando la plataforma Sber.DS. Le permite resolver problemas de aprendizaje automático, acelera el proceso de prueba de hipótesis, en principio simplifica el proceso de desarrollo y validación de modelos y también controla el resultado del modelo en PROM.
Para no engañar sus expectativas, quiero decir de antemano que esta publicación es introductoria, y debajo del corte, para empezar, hablamos de lo que, en principio, hay debajo del capó de la plataforma Sber.DS. Contaremos la historia sobre el ciclo de vida del modelo desde la creación hasta la implementación por separado.
Sber.DS consta de varios componentes, siendo los claves la biblioteca, el sistema de desarrollo y el sistema de ejecución de modelos.
La biblioteca controla el ciclo de vida del modelo desde que surge la idea de desarrollarlo hasta su implementación en PROM, seguimiento y desmantelamiento. Muchas capacidades de la biblioteca están dictadas por reglas reguladoras, por ejemplo, informes y almacenamiento de muestras de capacitación y validación. De hecho, este es un registro de todos nuestros modelos.
El sistema de desarrollo está diseñado para el desarrollo visual de modelos y técnicas de validación. Los modelos desarrollados se someten a una validación inicial y se suministran al sistema de ejecución para que realice sus funciones comerciales. Además, en el sistema en tiempo de ejecución, el modelo se puede colocar en un monitor con el fin de lanzar periódicamente técnicas de validación para monitorear su funcionamiento.
Hay varios tipos de nodos en el sistema. Algunos están diseñados para conectarse a varias fuentes de datos, otros están diseñados para transformar los datos de origen y enriquecerlos (marcado). Hay muchos nodos para construir diferentes modelos y nodos para validarlos. El desarrollador puede cargar datos de cualquier fuente, transformarlos, filtrarlos, visualizar datos intermedios y dividirlos en partes.
La plataforma también contiene módulos listos para usar que se pueden arrastrar y soltar en el área de diseño. Todas las acciones se realizan mediante una interfaz visualizada. De hecho, puedes resolver el problema sin una sola línea de código.
Si las capacidades integradas no son suficientes, el sistema ofrece la posibilidad de crear rápidamente sus propios módulos. Hicimos un modo de desarrollo integrado basado en para aquellos que crean nuevos módulos desde cero.
La arquitectura de Sber.DS se basa en microservicios. Hay muchas opiniones sobre qué son los microservicios. Algunas personas piensan que basta con dividir el código monolítico en partes, pero al mismo tiempo siguen yendo a la misma base de datos. Nuestro microservicio debe comunicarse con otro microservicio únicamente a través de REST API. No hay soluciones para acceder a la base de datos directamente.
Intentamos garantizar que los servicios no se vuelvan muy grandes y torpes: una instancia no debe consumir más de 4 a 8 gigabytes de RAM y debe brindar la capacidad de escalar solicitudes horizontalmente mediante el lanzamiento de nuevas instancias. Cada servicio se comunica con otros solo a través de REST API (). El equipo responsable del servicio debe mantener la API compatible con versiones anteriores hasta el último cliente que la utilice.
El núcleo de la aplicación está escrito en Java utilizando Spring Framework. La solución se diseñó inicialmente para una implementación rápida en la infraestructura de la nube, por lo que la aplicación se creó utilizando un sistema de contenedorización. (). La plataforma está en constante evolución, tanto en términos de aumento de la funcionalidad empresarial (se están agregando nuevos conectores, AutoML) como en términos de eficiencia tecnológica.
Una de las características de nuestra plataforma es que podemos ejecutar código desarrollado en una interfaz visual en cualquier sistema de ejecución de modelos de Sberbank. Ahora ya hay dos: uno en Hadoop y el otro en OpenShift (Docker). No nos detenemos allí y creamos módulos de integración para ejecutar código en cualquier infraestructura, incluidas las locales y la nube. En cuanto a las posibilidades de una integración efectiva en el ecosistema de Sberbank, también planeamos apoyar el trabajo con entornos de ejecución existentes. En el futuro, la solución se podrá integrar de manera flexible “lista para usar” en cualquier entorno de cualquier organización.
Aquellos que alguna vez han intentado soportar una solución que ejecuta Python en Hadoop en PROM saben que no es suficiente preparar y entregar un entorno de usuario de Python a cada nodo de datos. La enorme cantidad de bibliotecas C/C++ para aprendizaje automático que utilizan módulos de Python no te permitirá estar tranquilo. Debemos recordar actualizar los paquetes al agregar nuevas bibliotecas o servidores, manteniendo la compatibilidad con el código del modelo ya implementado.
Hay varios enfoques sobre cómo hacer esto. Por ejemplo, prepare con anticipación varias bibliotecas de uso frecuente e impleméntelas en PROM. En la distribución Hadoop de Cloudera, suelen utilizar . También ahora en Hadoop es posible ejecutar -contenedores. En algunos casos sencillos es posible entregar el código junto con el paquete. .
El banco se toma muy en serio la seguridad de ejecutar código de terceros, por lo que aprovechamos al máximo las nuevas características del kernel de Linux, donde un proceso se ejecuta en un entorno aislado. , puede limitar, por ejemplo, el acceso a la red y al disco local, lo que reduce significativamente las capacidades del código malicioso. Las áreas de datos de cada departamento están protegidas y son accesibles únicamente para los propietarios de estos datos. La plataforma garantiza que los datos de un área puedan llegar a otra área solo a través de un proceso de publicación de datos con control en todas las etapas, desde el acceso a las fuentes hasta el aterrizaje de los datos en el escaparate de destino.
Este año planeamos completar el MVP de lanzamiento de modelos escritos en Python/R/Java en Hadoop. Nos hemos propuesto la ambiciosa tarea de aprender a ejecutar cualquier entorno personalizado en Hadoop, para no limitar de ninguna manera a los usuarios de nuestra plataforma.
Además, resultó que muchos especialistas de DS son excelentes en matemáticas y estadística, crean modelos interesantes, pero no están muy versados en transformaciones de big data y necesitan la ayuda de nuestros ingenieros de datos para preparar muestras de entrenamiento. Decidimos ayudar a nuestros colegas y crear módulos convenientes para la transformación estándar y la preparación de características para modelos con motor Spark. Esto le permitirá dedicar más tiempo a desarrollar modelos y no esperar a que los ingenieros de datos preparen un nuevo conjunto de datos.
Empleamos personas con conocimientos en diferentes áreas: Linux y DevOps, Hadoop y Spark, Java y Spring, Scala y Akka, OpenShift y Kubernetes. La próxima vez hablaremos sobre la biblioteca de modelos, cómo pasa el modelo por el ciclo de vida dentro de la empresa, cómo se produce la validación y la implementación.
Fuente: habr.com