Idei și întâlniri despre ce alte procese pot fi automatizate apar în afaceri de diferite dimensiuni în fiecare zi. Însă, pe lângă faptul că se poate petrece mult timp pentru crearea unui model, trebuie să-l cheltuiți pentru a-l evalua și pentru a verifica dacă rezultatul obținut nu este aleatoriu. După implementare, orice model trebuie monitorizat și verificat periodic.
Și acestea sunt toate etapele care trebuie parcurse în orice companie, indiferent de dimensiunea acesteia. Dacă vorbim despre amploarea și moștenirea Sberbank, numărul de reglaje fine crește semnificativ. Până la sfârșitul anului 2019, Sber utilizase deja peste 2000 de modele. Nu este suficient să dezvolți un model, ci este necesar să se integreze cu sistemele industriale, să se dezvolte data mart pentru a construi modele și să se asigure controlul funcționării acestuia pe cluster.
Echipa noastră dezvoltă platforma Sber.DS. Vă permite să rezolvați problemele de învățare automată, accelerează procesul de testare a ipotezelor, în principiu simplifică procesul de dezvoltare și validare a modelelor și, de asemenea, controlează rezultatul modelului în PROM.
Pentru a nu vă înșela așteptările, vreau să vă spun în avans că această postare este una introductivă, iar sub tăietură, pentru început, vorbim despre ceea ce, în principiu, se află sub capota platformei Sber.DS. Vom spune povestea despre ciclul de viață al modelului de la creare până la implementare separat.
Sber.DS este format din mai multe componente, cele cheie fiind biblioteca, sistemul de dezvoltare și sistemul de execuție a modelului.
Biblioteca controlează ciclul de viață al modelului din momentul în care apare ideea de a-l dezvolta și până la implementarea lui în PROM, monitorizare și dezafectare. Multe capabilități ale bibliotecii sunt dictate de regulile autorităților de reglementare, de exemplu, raportarea și stocarea mostrelor de instruire și validare. De fapt, acesta este un registru al tuturor modelelor noastre.
Sistemul de dezvoltare este conceput pentru dezvoltarea vizuală a modelelor și a tehnicilor de validare. Modelele dezvoltate sunt supuse unei validări inițiale și sunt furnizate sistemului de execuție pentru a-și îndeplini funcțiile de afaceri. De asemenea, în sistemul runtime, modelul poate fi plasat pe un monitor în scopul lansării periodice a tehnicilor de validare pentru monitorizarea funcționării acestuia.
Există mai multe tipuri de noduri în sistem. Unele sunt concepute pentru a se conecta la diverse surse de date, altele sunt concepute pentru a transforma datele sursă și a le îmbogăți (markup). Există multe noduri pentru construirea diferitelor modele și noduri pentru validarea lor. Dezvoltatorul poate încărca date din orice sursă, poate transforma, filtra, vizualiza datele intermediare și le poate împărți în părți.
Platforma conține, de asemenea, module gata făcute care pot fi trase și plasate în zona de proiectare. Toate acțiunile sunt efectuate folosind o interfață vizualizată. De fapt, puteți rezolva problema fără o singură linie de cod.
Dacă capabilitățile încorporate nu sunt suficiente, sistemul oferă posibilitatea de a crea rapid propriile module. Am realizat un mod de dezvoltare integrat bazat pe pentru cei care creează module noi de la zero.
Arhitectura Sber.DS este construită pe microservicii. Există multe păreri despre ce sunt microservicii. Unii oameni cred că este suficient să împărțiți codul monolitic în părți, dar, în același timp, încă merg la aceeași bază de date. Microserviciul nostru trebuie să comunice cu un alt microserviciu numai prin API-ul REST. Nu există soluții pentru a accesa baza de date direct.
Încercăm să ne asigurăm că serviciile nu devin foarte mari și stângace: o instanță nu ar trebui să consume mai mult de 4-8 gigaocteți de memorie RAM și trebuie să ofere capacitatea de a scala orizontal solicitările prin lansarea de noi instanțe. Fiecare serviciu comunică cu ceilalți numai prin API-ul REST (). Echipa responsabilă cu serviciul trebuie să mențină API-ul compatibil înapoi până la ultimul client care îl folosește.
Nucleul aplicației este scris în Java folosind Spring Framework. Soluția a fost concepută inițial pentru o implementare rapidă în infrastructura cloud, așa că aplicația a fost construită folosind un sistem de containerizare (). Platforma este în continuă evoluție, atât în ceea ce privește creșterea funcționalității afacerii (se adaugă noi conectori, AutoML), cât și în ceea ce privește eficiența tehnologică.
Una dintre caracteristicile platformei noastre este că putem rula cod dezvoltat într-o interfață vizuală pe orice sistem de execuție a modelului Sberbank. Acum există deja două dintre ele: unul pe Hadoop, celălalt pe OpenShift (Docker). Nu ne oprim aici și creăm module de integrare pentru a rula cod pe orice infrastructură, inclusiv on-premise și în cloud. În ceea ce privește posibilitățile de integrare efectivă în ecosistemul Sberbank, ne propunem și să sprijinim lucrul cu mediile de execuție existente. În viitor, soluția poate fi integrată în mod flexibil „din cutie” în orice peisaj al oricărei organizații.
Cei care au încercat vreodată să susțină o soluție care rulează Python pe Hadoop în PROM știu că nu este suficient să pregătească și să livreze un mediu de utilizator Python fiecărui nod de date. Numărul imens de biblioteci C/C++ pentru învățarea automată care folosesc module Python nu vă va permite să stați liniştit. Trebuie să ne amintim să actualizăm pachetele atunci când adăugăm noi biblioteci sau servere, menținând în același timp compatibilitatea cu modelul deja implementat.
Există mai multe abordări pentru a face acest lucru. De exemplu, pregătiți în avans mai multe biblioteci utilizate frecvent și implementați-le în PROM. În distribuția Hadoop a Cloudera, de obicei folosesc . De asemenea, acum în Hadoop este posibil să rulați -containere. În unele cazuri simple este posibilă livrarea codului împreună cu coletul .
Banca ia foarte în serios securitatea rulării codului terță parte, așa că profităm la maximum de noile caracteristici ale nucleului Linux, unde un proces rulează într-un mediu izolat , puteți limita, de exemplu, accesul la rețea și la discul local, ceea ce reduce semnificativ capacitățile codului rău intenționat. Zonele de date ale fiecărui departament sunt protejate și accesibile numai deținătorilor acestor date. Platforma asigură că datele dintr-o zonă pot ajunge în altă zonă doar printr-un proces de publicare a datelor cu control în toate etapele de la acces la surse până la aterizarea datelor în vitrina țintă.
Anul acesta intenționăm să finalizăm MVP-ul de lansare a modelelor scrise în Python/R/Java pe Hadoop. Ne-am propus sarcina ambițioasă de a învăța cum să rulăm orice mediu personalizat pe Hadoop, pentru a nu limita în niciun fel utilizatorii platformei noastre.
În plus, după cum s-a dovedit, mulți specialiști DS sunt excelenți la matematică și statistică, fac modele interesante, dar nu sunt foarte familiarizați cu transformările de date mari și au nevoie de ajutorul inginerilor noștri de date pentru a pregăti mostre de antrenament. Am decis să ne ajutăm colegii și să creăm module convenabile pentru transformarea standard și pregătirea caracteristicilor pentru modelele de pe motorul Spark. Acest lucru vă va permite să petreceți mai mult timp dezvoltând modele și să nu așteptați ca inginerii de date să pregătească un nou set de date.
Angajăm oameni cu cunoștințe în diferite domenii: Linux și DevOps, Hadoop și Spark, Java și Spring, Scala și Akka, OpenShift și Kubernetes. Data viitoare vom vorbi despre biblioteca de modele, cum trece modelul prin ciclul de viață în cadrul companiei, cum au loc validarea și implementarea.
Sursa: www.habr.com