Idei și întâlniri despre procesele care pot fi automatizate apar zilnic în afaceri de diferite dimensiuni. Dar, pe lângă timpul necesar pentru a crea un model, trebuie să se aloce timp pentru evaluarea și verificarea faptului că rezultatul obținut nu este întâmplător. După implementare, orice model trebuie monitorizat și verificat periodic.
Acestea sunt etape care trebuie parcurse în orice companie, indiferent de dimensiunea acesteia. Când ne referim la amploarea și structurile legate de Sberbank, numărul ajustărilor fine crește considerabil. Până la sfârșitul anului 2019, Sberbank folosea deja peste 2000 de modele. Nu este suficient să dezvolți un model; este necesară integrarea cu sistemele industriale, dezvoltarea vitrinelor de date pentru construirea modelelor și asigurarea controlului funcționării acestuia pe cluster.
Echipa noastră dezvoltă platforma Sber.DS. Aceasta permite rezolvarea sarcinilor de învățare automată, accelerează procesul de verificare a ipotezelor, simplifică, în general, procesul de dezvoltare și validare a modelelor, precum și controlează rezultatul muncii modelului în PROM.
Pentru a nu vă înșela așteptările, vreau să vă spun din timp că această postare este introducerea și, mai jos, discutăm despre ceea ce se află, în principiu, sub capotă în platforma Sber.DS. Povestea ciclului de viață al modelului, de la creație la implementare, o vom relata 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 de la momentul în care apare ideea dezvoltării sale până la implementarea în PROM, monitorizarea și scoaterea din uz. Multe dintre funcționalitățile bibliotecii sunt dictate de regulile autorităților de reglementare, de exemplu, raportarea și stocarea seturilor de date de antrenament și validare. De fapt, aceasta este un registru al tuturor modelelor noastre.
Sistemul de dezvoltare este destinat dezvoltării vizuale a modelelor și metodologiilor de validare. Modelele create trec printr-o validare inițială și sunt livrate sistemului de execuție pentru îndeplinirea funcțiilor lor de afaceri. De asemenea, în sistemul de execuție, modelul poate fi plasat pe monitor cu scopul de a rula periodic metodologiile de validare pentru a controla funcționarea acestuia.
Sistemul include mai multe tipuri de noduri. Unele sunt destinate conectării la diverse surse de date, altele - transformării datelor inițiale și îmbogățirii acestora (etichete). Există multe noduri pentru construirea diverselor modele și pentru validarea acestora. Dezvoltatorul poate încărca date din orice sursă, le poate transforma, filtra, vizualiza datele intermediare și le poate împărți în părți.
De asemenea, platforma conține module deja pregătite, care pot fi trasate în zona de proiectare. Toate acțiunile se desfășoară printr-o interfață vizualizată. Practic, se poate rezolva o sarcină fără a scrie o singură linie de cod.
Dacă funcționalitățile încorporate nu sunt suficiente, sistemul oferă posibilitatea de a crea rapid propriile module. Am implementat un mod de dezvoltare integrată pe baza pentru cei care creează module noi "de la zero".
Arhitectura Sber.DS este construită pe microservicii. Există multe păreri despre ceea ce înseamnă microservicii. Unii consideră că este suficient să împarti codul monolitic în părți, dar acestea continuă să acceseze aceeași bază de date. La noi, un microserviciu trebuie să comunice cu alt microserviciu doar prin REST API. Niciun acces direct la baza de date.
Ne străduim ca serviciile să nu devină foarte mari și lente: un exemplu nu ar trebui să consume mai mult de 4-8 gigaocteți de memorie RAM și trebuie să asigure posibilitatea scalării orizontale a cererilor prin lansarea de noi instanțe. Fiecare serviciu comunică cu celelalte doar prin REST API (). Echipa responsabilă pentru serviciu trebuie să mențină compatibilitatea inversă a API-ului până la ultimul client care îl utilizează.
Nucleul aplicației este scris în Java folosind Spring Framework. Soluția a fost proiectată inițial pentru o desfășurare rapidă în infrastructura cloud, de aceea aplicația a fost construită folosind un sistem de containerizare (). Platforma se dezvoltă constant, atât în ceea ce privește extinderea funcționalității de afaceri (se adaugă noi conectori, AutoML), cât și în ceea ce privește eficiența tehnologică.
Una dintre «caracteristicile» platformei noastre constă în faptul că putem rula cod dezvoltat în interfața vizuală pe orice sistem de execuție a modelului Sberbank. Acum există deja două: una pe Hadoop și cealaltă 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 capacitățile de integrare eficientă în ecosistemul Sberbank, avem de asemenea planuri de a susține lucrul cu mediile de execuție existente. În viitor, soluția poate fi integrată flexibil „din cutie” în orice peisaj al oricărei organizații.
Cei care au încercat vreodată să mențină o soluție care rulează Python pe Hadoop în PRO, știu că e puțin să pregătești și să livrezi mediu Python pentru fiecare nod de data. O mulțime de biblioteci C/C++ pentru învățarea automată care utilizează module Python nu îți vor permite să te odihnești liniștit. Nu trebuie să uiți să actualizezi pachetele atunci când adaugi biblioteci sau servere noi, menținând compatibilitatea înapoi cu codul modelului deja implementat.
Există câteva abordări pentru a face acest lucru. De exemplu, pregătirea anticipată a câtorva biblioteci frecvent utilizate și integrarea acestora în PRO. În distribuția Hadoop de la Cloudera, acest lucru se face de obicei folosind . De asemenea, acum în Hadoop apare posibilitatea de a rula -containere. În unele cazuri simple, codul poate fi livrat împreună cu pachetul .
Banca abordează foarte serios securitatea rulării codului terț, astfel încât utilizăm la maximum noile capacități ale nucleului Linux, unde procesul lansat într-un mediu izolat , poate fi restricționat, de exemplu, în ceea ce privește accesul la rețea și la discurile locale, ceea ce reduce semnificativ capacitățile codului malițios. Zonele de date ale fiecărui departament sunt protejate și accesibile doar proprietarilor acestor date. Platforma garantează că datele dintr-o zonă pot ajunge în alta doar printr-un proces de publicare a datelor cu control la toate etapele, de la accesul la surse până la livrarea datelor în vitrina țintă.
Anul acesta, ne propunem să finalizăm MVP-ul lansării modelelor scrise în Python/R/Java pe Hadoop. Ne-am fixat o sarcină ambițioasă de a învăța să rulăm orice mediu utilizator pe Hadoop, pentru a nu restricționa utilizatorii platformei noastre.
De asemenea, s-a dovedit că mulți specialiști DS au cunoștințe excelente de matematică și statistică, creează modele remarcabile, dar nu sunt foarte familiarizați cu transformările de date mari, având nevoie de ajutorul inginerilor noștri de date pentru pregătirea seturilor de antrenament. Am decis să ajutăm colegii și să creăm module convenabile pentru transformarea standardizată și pregătirea caracteristicilor pentru modelele bazate pe motorul Spark. Aceasta va permite să dedicăm mai mult timp dezvoltării modelelor și să nu așteptăm ca inginerii de date să pregătească un nou set de date.
La noi lucrează oameni cu cunoștințe din diferite domenii: Linux și DevOps, Hadoop și Spark, Java și Spring, Scala și Akka, OpenShift și Kubernetes. Data viitoare, vă vom vorbi despre biblioteca de modele, despre cum trece o modelă prin ciclul de viață în cadrul companiei, precum și despre cum se desfășoară validarea și implementarea.
Sursa: habr.com
