Cada día xorden ideas e reunións sobre que outros procesos poden automatizarse en empresas de varios tamaños. Pero ademais de que se pode dedicar moito tempo á creación dun modelo, cómpre dedicalo a avalialo e comprobar que o resultado obtido non é aleatorio. Despois da implantación, calquera modelo debe ser supervisado e revisado periódicamente.
E estas son todas as etapas que hai que completar en calquera empresa, independentemente do seu tamaño. Se falamos da escala e do legado de Sberbank, o número de axustes aumenta significativamente. A finais de 2019, Sber xa utilizara máis de 2000 modelos. Non basta simplemente con desenvolver un modelo, é necesario integrarse cos sistemas industriais, desenvolver data marts para construír modelos e garantir o control do seu funcionamento no clúster.
O noso equipo está a desenvolver a plataforma Sber.DS. Permite resolver problemas de aprendizaxe automática, acelera o proceso de proba de hipóteses, en principio simplifica o proceso de desenvolvemento e validación de modelos e tamén controla o resultado do modelo en PROM.
Para non enganar as túas expectativas, quero dicir de antemán que esta publicación é introdutoria, e baixo o corte, para comezar, falamos do que, en principio, está baixo o capó da plataforma Sber.DS. Contaremos por separado a historia sobre o ciclo de vida do modelo desde a súa creación ata a súa implementación.
Sber.DS consta de varios compoñentes, sendo os principais a biblioteca, o sistema de desenvolvemento e o sistema de execución do modelo.
A biblioteca controla o ciclo de vida do modelo desde que aparece a idea de desenvolvelo ata a súa implantación en PROM, seguimento e desmantelamento. Moitas capacidades da biblioteca están ditadas polas regras reguladoras, por exemplo, a presentación de informes e o almacenamento de mostras de formación e validación. De feito, este é un rexistro de todos os nosos modelos.
O sistema de desenvolvemento está deseñado para o desenvolvemento visual de modelos e técnicas de validación. Os modelos desenvolvidos son sometidos a unha validación inicial e son subministrados ao sistema de execución para realizar as súas funcións empresariais. Ademais, no sistema de execución, o modelo pódese colocar nun monitor coa finalidade de lanzar periodicamente técnicas de validación para supervisar o seu funcionamento.
Hai varios tipos de nodos no sistema. Algúns están deseñados para conectarse a varias fontes de datos, outros están deseñados para transformar os datos de orixe e enriquecelos (marcado). Hai moitos nodos para construír diferentes modelos e nodos para validalos. O programador pode cargar datos de calquera fonte, transformalos, filtralos, visualizalos datos intermedios e dividilos en partes.
A plataforma tamén contén módulos preparados que se poden arrastrar e soltar na área de deseño. Todas as accións realízanse mediante unha interface visualizada. De feito, pode resolver o problema sen unha soa liña de código.
Se as capacidades integradas non son suficientes, o sistema ofrece a posibilidade de crear rapidamente os seus propios módulos. Fixemos un modo de desenvolvemento integrado baseado en para aqueles que crean novos módulos desde cero.
A arquitectura de Sber.DS está construída sobre microservizos. Hai moitas opinións sobre o que son os microservizos. Algunhas persoas pensan que é suficiente dividir o código monolítico en partes, pero ao mesmo tempo seguen a ir á mesma base de datos. O noso microservizo debe comunicarse con outro microservizo só a través da API REST. Non hai solucións para acceder directamente á base de datos.
Tentamos garantir que os servizos non se volvan moi grandes e torpes: unha instancia non debe consumir máis de 4-8 gigabytes de RAM e debe proporcionar a capacidade de escalar horizontalmente as solicitudes lanzando novas instancias. Cada servizo se comunica con outros só a través da API REST (). O equipo responsable do servizo ten que manter a API retrocompatible ata o último cliente que a utiliza.
O núcleo da aplicación está escrito en Java usando Spring Framework. A solución foi deseñada inicialmente para a súa rápida implantación na infraestrutura da nube, polo que a aplicación foi construída mediante un sistema de contenerización (). A plataforma está en constante evolución, tanto no que se refire ao aumento da funcionalidade empresarial (engádense novos conectores, AutoML) como no que se refire á eficiencia tecnolóxica.
Unha das características da nosa plataforma é que podemos executar código desenvolvido nunha interface visual en calquera sistema de execución de modelos de Sberbank. Agora xa hai dous: un en Hadoop, o outro en OpenShift (Docker). Non nos detemos aí e creamos módulos de integración para executar código en calquera infraestrutura, incluso local e na nube. En canto ás posibilidades de integración efectiva no ecosistema de Sberbank, tamén pensamos apoiar o traballo con contornos de execución existentes. No futuro, a solución pódese integrar de forma flexible "fóra da caixa" en calquera paisaxe de calquera organización.
Aqueles que xa tentaron soportar unha solución que executa Python en Hadoop en PROM saben que non é suficiente con preparar e entregar un ambiente de usuario Python a cada nodo de datos. O gran número de bibliotecas C/C++ para a aprendizaxe automática que usan módulos de Python non che permitirá estar tranquilo. Debemos lembrar de actualizar os paquetes ao engadir novas bibliotecas ou servidores, mantendo a compatibilidade con versións anteriores co código do modelo xa implementado.
Hai varios enfoques para facelo. Por exemplo, prepare varias bibliotecas de uso frecuente con antelación e implementalas en PROM. Na distribución Hadoop de Cloudera, adoitan usar . Tamén agora en Hadoop é posible executar - contedores. Nalgúns casos sinxelos é posible entregar o código xunto co paquete .
O banco tómase moi en serio a seguridade de executar código de terceiros, polo que aproveitamos ao máximo as novas funcións do núcleo de Linux, onde un proceso se executa nun ambiente illado , pode limitar, por exemplo, o acceso á rede e ao disco local, o que reduce significativamente as capacidades do código malicioso. As áreas de datos de cada departamento están protexidas e só son accesibles para os propietarios destes datos. A plataforma garante que os datos dunha área poidan chegar a outra área só a través dun proceso de publicación de datos con control en todas as fases, desde o acceso ás fontes ata o desembarco dos datos no escaparate de destino.
Este ano pensamos completar o MVP de lanzar modelos escritos en Python/R/Java en Hadoop. Propuxémonos a ambiciosa tarefa de aprender a executar calquera ambiente personalizado en Hadoop, para non limitar de ningún xeito os usuarios da nosa plataforma.
Ademais, como se viu, moitos especialistas de DS son excelentes en matemáticas e estatísticas, fan modelos interesantes, pero non están moi versados en transformacións de big data e necesitan a axuda dos nosos enxeñeiros de datos para preparar mostras de adestramento. Decidimos axudar aos nosos colegas e crear módulos convenientes para a transformación estándar e a preparación de funcións para os modelos do motor Spark. Isto permitirache dedicar máis tempo a desenvolver modelos e non esperar a que os enxeñeiros de datos preparen un novo conxunto de datos.
Empregamos persoas con coñecementos en diferentes áreas: Linux e DevOps, Hadoop e Spark, Java e Spring, Scala e Akka, OpenShift e Kubernetes. A próxima vez falaremos da biblioteca de modelos, de como transcorre o modelo polo ciclo de vida da empresa, de como se produce a validación e implementación.
Fonte: www.habr.com