Cada dia sorgeixen idees i reunions sobre quins altres processos es poden automatitzar en empreses de diferents mides. Però a més del fet que es pot dedicar molt de temps a la creació d'un model, cal dedicar-lo a avaluar-lo i comprovar que el resultat obtingut no és aleatori. Després de la implementació, qualsevol model s'ha de controlar i revisar periòdicament.
I aquestes són totes les etapes que cal completar en qualsevol empresa, independentment de la seva mida. Si estem parlant de l'escala i el llegat de Sberbank, el nombre d'ajustaments augmenta significativament. A finals del 2019, Sber ja havia utilitzat més de 2000 models. No n'hi ha prou amb desenvolupar un model, sinó que cal integrar-se amb sistemes industrials, desenvolupar data mart per construir models i garantir el control del seu funcionament al clúster.
El nostre equip està desenvolupant la plataforma Sber.DS. Permet resoldre problemes d'aprenentatge automàtic, accelera el procés de prova d'hipòtesis, en principi simplifica el procés de desenvolupament i validació de models i també controla el resultat del model a PROM.
Per no enganyar les vostres expectatives, vull dir per endavant que aquesta entrada és una introducció, i sota el tall, per començar, parlem del que, en principi, està sota el capó de la plataforma Sber.DS. Explicarem la història del cicle de vida del model des de la creació fins a la implementació per separat.
Sber.DS consta de diversos components, els principals són la biblioteca, el sistema de desenvolupament i el sistema d'execució de models.
La biblioteca controla el cicle de vida del model des que apareix la idea de desenvolupar-lo fins a la seva implementació en PROM, seguiment i desmantellament. Moltes capacitats de la biblioteca estan dictades per regles reguladores, per exemple, la presentació d'informes i l'emmagatzematge de mostres de formació i validació. De fet, aquest és un registre de tots els nostres models.
El sistema de desenvolupament està dissenyat per al desenvolupament visual de models i tècniques de validació. Els models desenvolupats se sotmeten a una validació inicial i es subministren al sistema d'execució per dur a terme les seves funcions empresarials. A més, en el sistema d'execució, el model es pot col·locar en un monitor amb la finalitat de llançar periòdicament tècniques de validació per supervisar el seu funcionament.
Hi ha diversos tipus de nodes al sistema. Alguns estan dissenyats per connectar-se a diverses fonts de dades, d'altres estan dissenyats per transformar les dades font i enriquir-les (marcat). Hi ha molts nodes per construir diferents models i nodes per validar-los. El desenvolupador pot carregar dades de qualsevol font, transformar, filtrar, visualitzar dades intermèdies i dividir-les en parts.
La plataforma també conté mòduls ja fets que es poden arrossegar i deixar anar a l'àrea de disseny. Totes les accions es realitzen mitjançant una interfície visualitzada. De fet, podeu resoldre el problema sense una sola línia de codi.
Si les capacitats integrades no són suficients, el sistema ofereix la possibilitat de crear ràpidament els vostres propis mòduls. Hem fet un mode de desenvolupament integrat basat en per a aquells que creen nous mòduls des de zero.
L'arquitectura de Sber.DS es basa en microserveis. Hi ha moltes opinions sobre què són els microserveis. Algunes persones pensen que n'hi ha prou amb dividir el codi monolític en parts, però al mateix temps segueixen passant a la mateixa base de dades. El nostre microservei s'ha de comunicar amb un altre microservei només mitjançant l'API REST. No hi ha cap solució alternativa per accedir directament a la base de dades.
Intentem garantir que els serveis no siguin molt grans i maldestres: una instància no hauria de consumir més de 4-8 gigabytes de memòria RAM i ha de proporcionar la possibilitat d'escalar les sol·licituds de manera horitzontal llançant noves instàncies. Cada servei es comunica amb altres només mitjançant l'API REST (). L'equip responsable del servei ha de mantenir l'API retrocompatible fins a l'últim client que l'utilitzi.
El nucli de l'aplicació està escrit en Java mitjançant Spring Framework. La solució es va dissenyar inicialment per a un desplegament ràpid a la infraestructura del núvol, de manera que l'aplicació es va crear mitjançant un sistema de contenidorització (). La plataforma està en constant evolució, tant pel que fa a l'augment de la funcionalitat empresarial (s'estan afegint nous connectors, AutoML) com pel que fa a l'eficiència tecnològica.
Una de les característiques de la nostra plataforma és que podem executar codi desenvolupat en una interfície visual en qualsevol sistema d'execució de models de Sberbank. Ara ja n'hi ha dos: un a Hadoop, l'altre a OpenShift (Docker). No ens aturem aquí i creem mòduls d'integració per executar codi en qualsevol infraestructura, inclòs a la instal·lació i al núvol. Pel que fa a les possibilitats d'integració efectiva a l'ecosistema de Sberbank, també tenim previst donar suport al treball amb entorns d'execució existents. En el futur, la solució es pot integrar de manera flexible "des de la caixa" a qualsevol paisatge de qualsevol organització.
Els que alguna vegada han intentat donar suport a una solució que executa Python a Hadoop a PROM saben que no n'hi ha prou amb preparar i lliurar un entorn d'usuari Python a cada datanode. La gran quantitat de biblioteques C/C++ per a l'aprenentatge automàtic que utilitzen mòduls Python no us permetrà estar tranquil. Hem de recordar actualitzar els paquets quan afegim noves biblioteques o servidors, mantenint la compatibilitat amb el codi del model ja implementat.
Hi ha diversos enfocaments sobre com fer-ho. Per exemple, prepareu diverses biblioteques d'ús freqüent amb antelació i implementeu-les a PROM. A la distribució Hadoop de Cloudera, solen utilitzar . També ara a Hadoop és possible córrer - contenidors. En alguns casos senzills és possible lliurar el codi juntament amb el paquet .
El banc es pren molt seriosament la seguretat d'executar codi de tercers, de manera que aprofitem al màxim les noves característiques del nucli Linux, on un procés s'executa en un entorn aïllat , podeu limitar, per exemple, l'accés a la xarxa i al disc local, la qual cosa redueix significativament les capacitats del codi maliciós. Les àrees de dades de cada departament estan protegides i només accessibles per als propietaris d'aquestes dades. La plataforma garanteix que les dades d'una àrea puguin arribar a una altra àrea només mitjançant un procés de publicació de dades amb control en totes les etapes, des de l'accés a les fonts fins a l'aterratge de les dades a l'aparador objectiu.
Aquest any tenim previst completar l'MVP de llançament de models escrits en Python/R/Java a Hadoop. Ens hem proposat l'ambiciosa tasca d'aprendre a executar qualsevol entorn personalitzat a Hadoop, per no limitar de cap manera els usuaris de la nostra plataforma.
A més, com va resultar, molts especialistes de DS són excel·lents en matemàtiques i estadístiques, fan models interessants, però no estan molt versats en transformacions de big data i necessiten l'ajuda dels nostres enginyers de dades per preparar mostres de formació. Vam decidir ajudar els nostres companys i crear mòduls convenients per a la transformació estàndard i la preparació de funcions per als models del motor Spark. Això us permetrà dedicar més temps a desenvolupar models i no esperar que els enginyers de dades preparin un nou conjunt de dades.
Comptem persones amb coneixements en diferents àrees: Linux i DevOps, Hadoop i Spark, Java i Spring, Scala i Akka, OpenShift i Kubernetes. La propera vegada parlarem de la biblioteca de models, de com transcorre el model pel cicle de vida dins de l'empresa, de com es produeix la validació i la implementació.
Font: www.habr.com