Începând de anul trecut, compania noastră a început să organizeze hackathon-uri. Prima astfel de competiție a fost foarte reușită, am scris despre asta în . Al doilea hackathon a avut loc în februarie 2019 și nu a avut mai puțin succes. Despre obiectivele ținerii acestuia din urmă nu cu mult timp în urmă organizator.
Participanților li sa dat o sarcină destul de interesantă, cu libertate deplină în alegerea unei stive de tehnologie pentru implementarea acesteia. A fost necesar să se implementeze o platformă de luare a deciziilor pentru implementarea convenabilă a funcțiilor de punctare a clienților care să poată funcționa cu un flux rapid de aplicații, să reziste la sarcini grele, iar sistemul în sine a fost ușor scalabil.
Sarcina nu este banală și poate fi rezolvată în multe feluri, așa cum ne-am convins în timpul demonstrației prezentărilor finale ale proiectelor participanților. Au fost 6 echipe de 5 persoane la hackathon, toți participanții au avut proiecte bune, dar platforma noastră s-a dovedit a fi cea mai competitivă. Avem un proiect foarte interesant, despre care aș vrea să vorbesc în acest articol.
Soluția noastră este o platformă bazată pe arhitectura Serverless în interiorul Kubernetes, care reduce timpul necesar pentru a aduce noi funcții în producție. Le permite analiștilor să scrie cod într-un mediu convenabil pentru ei și să-l implementeze în producție fără participarea inginerilor și dezvoltatorilor.
Ce este scorul
Tinkoff.ru, ca multe companii moderne, are punctaj pentru clienți. Scoring este un sistem de evaluare a clienților bazat pe metode statistice de analiză a datelor.
De exemplu, un client apelează la noi cu o solicitare de a-i acorda un împrumut sau de a deschide un cont individual de antreprenor la noi. Dacă intenționăm să-i acordăm un împrumut, atunci trebuie să-i evaluăm solvabilitatea, iar dacă contul este un antreprenor individual, atunci trebuie să ne asigurăm că clientul nu va efectua tranzacții frauduloase.
La baza luării unor astfel de decizii se află modele matematice care analizează atât datele din aplicație în sine, cât și datele din stocarea noastră. Pe lângă punctare, metode statistice similare pot fi folosite și în serviciul generării de recomandări individuale pentru produse noi pentru clienții noștri.
Metoda unei astfel de evaluări poate accepta o varietate de date de intrare. Și la un moment dat putem adăuga un nou parametru la intrare, care, pe baza rezultatelor analizei datelor istorice, va crește rata de conversie a utilizării serviciului.
Deținem o mulțime de date despre relațiile cu clienții, iar volumul acestor informații este în continuă creștere. Pentru ca punctajul să funcționeze, procesarea datelor necesită și reguli (sau modele matematice) care vă permit să decideți rapid cine să aprobați o cerere, cui să refuzați și cui să mai oferi câteva produse, evaluând interesul lor potențial.
Pentru sarcina în cauză, folosim deja un sistem decizional specializat , care, pe baza regulilor stabilite de analiști, tehnologi și dezvoltatori, decide dacă aprobă sau refuză clientului un anumit produs bancar.
Există multe soluții gata făcute pe piață, atât modele de punctare, cât și sisteme decizionale în sine. Utilizăm unul dintre aceste sisteme în compania noastră. Insa afacerea este in crestere, se diversifica, atat numarul de clienti, cat si numarul de produse oferite sunt in crestere, iar odata cu aceasta, apar si idei de imbunatatire a procesului decizional existent. Cu siguranță oamenii care lucrează cu sistemul existent au multe idei despre cum să-l facă mai simplu, mai bun, mai convenabil, dar uneori ideile din exterior sunt utile. Noul Hackathon a fost organizat cu scopul de a colecta idei solide.
Sarcină
Hackathonul a avut loc pe 23 februarie. Participanților li sa oferit o sarcină de luptă: dezvoltarea unui sistem decizional care trebuia să îndeplinească o serie de condiții.
Ni s-a spus cum funcționează sistemul existent și ce dificultăți apar în timpul funcționării acestuia, precum și ce obiective de afaceri ar trebui să urmărească platforma dezvoltată. Sistemul trebuie să aibă un time-to-market rapid pentru dezvoltarea regulilor, astfel încât codul de lucru al analiștilor să intre în producție cât mai repede posibil. Iar pentru fluxul de aplicații de intrare, timpul de luare a deciziilor ar trebui să tindă la minim. De asemenea, sistemul în curs de dezvoltare trebuie să aibă capabilități de cross-sell pentru a oferi clientului posibilitatea de a achiziționa alte produse ale companiei dacă acestea sunt aprobate de noi și au potențial interes din partea clientului.
Este clar că este imposibil să scriem peste noapte un proiect gata de lansare care va intra cu siguranță în producție și este destul de dificil să acoperim întregul sistem, așa că ni s-a cerut să implementăm cel puțin o parte din el. Au fost stabilite o serie de cerințe pe care prototipul trebuie să le îndeplinească. A fost posibil să se încerce atât acoperirea tuturor cerințelor în întregime, cât și lucrul în detaliu asupra secțiunilor individuale ale platformei în curs de dezvoltare.
În ceea ce privește tehnologia, toți participanții au avut libertate totală de alegere. A fost posibil să se utilizeze orice concepte și tehnologii: streaming de date, învățare automată, aprovizionare cu evenimente, date mari și altele.
Soluția noastră
După un mic brainstorming, am decis că o soluție FaaS ar fi ideală pentru finalizarea sarcinii.
Pentru această soluție a fost necesară găsirea unui cadru Serverless adecvat pentru implementarea regulilor sistemului decizional în curs de dezvoltare. Deoarece Tinkoff folosește în mod activ Kubernetes pentru gestionarea infrastructurii, am analizat mai multe soluții gata făcute pe baza acestuia; vă voi spune mai multe despre el mai târziu.
Pentru a găsi cea mai eficientă soluție, ne-am uitat la produsul dezvoltat prin ochii utilizatorilor săi. Principalii utilizatori ai sistemului nostru sunt analiștii implicați în dezvoltarea regulilor. Regulile trebuie implementate pe server sau, ca în cazul nostru, implementate în cloud, pentru luarea ulterioară a deciziilor. Din perspectiva unui analist, fluxul de lucru arată astfel:
- Analistul scrie un script, o regulă sau un model ML pe baza datelor din depozit. Ca parte a hackathonului, am decis să folosim Mongodb, dar alegerea sistemului de stocare a datelor nu este importantă aici.
- După ce a testat regulile dezvoltate privind datele istorice, analistul își încarcă codul în panoul de administrare.
- Pentru a asigura versiunea, tot codul va merge la depozitele Git.
- Prin panoul de administrare, va fi posibil să implementați codul în cloud ca un modul funcțional fără server.
Datele inițiale de la clienți trebuie să treacă printr-un serviciu specializat de Îmbogățire menit să îmbogățească cererea inițială cu date din depozit. Era important să implementăm acest serviciu în așa fel încât să funcționeze cu un singur depozit (din care analistul preia date atunci când elaborează reguli) pentru a menține o structură de date unificată.
Chiar înainte de hackathon, ne-am hotărât asupra cadrului Serverless pe care îl vom folosi. Astăzi există destul de multe tehnologii pe piață care implementează această abordare. Cele mai populare soluții din arhitectura Kubernetes sunt Fission, Open FaaS și Kubeless. Există chiar și .
După ce am cântărit toate argumentele pro și contra, am ales . Acest cadru Serverless este destul de ușor de gestionat și îndeplinește cerințele sarcinii.
Pentru a lucra cu Fission, trebuie să înțelegeți două concepte de bază: funcție și mediu. O funcție este o bucată de cod scrisă într-una dintre limbile pentru care există un mediu Fission. include Python, JS, Go, JVM și multe alte limbaje și tehnologii populare.
Fission este, de asemenea, capabil să îndeplinească funcții împărțite în mai multe fișiere, pre-ambalate într-o arhivă. Funcționarea Fission într-un cluster Kubernetes este asigurată de pod-uri specializate, care sunt gestionate de framework-ul însuși. Pentru a interacționa cu podurile de cluster, fiecărei funcție trebuie să i se atribuie propria rută și căreia îi puteți transmite parametrii GET sau corpul solicitării în cazul unei solicitări POST.
Drept urmare, am plănuit să obținem o soluție care să permită analiștilor să implementeze scripturi de reguli dezvoltate fără participarea inginerilor și dezvoltatorilor. Abordarea descrisă elimină, de asemenea, nevoia dezvoltatorilor de a rescrie codul analistului într-o altă limbă. De exemplu, pentru sistemul actual de luare a deciziilor pe care îl folosim, trebuie să scriem reguli în tehnologii și limbi foarte specializate, al căror domeniu de aplicare este extrem de limitat și există, de asemenea, o dependență puternică de serverul de aplicații, deoarece toate proiectele de reguli ale băncii sunt implementate într-un singur mediu. Ca urmare, pentru a implementa reguli noi, este necesară eliberarea întregului sistem.
În soluția propusă de noi, nu este nevoie să eliberăm reguli; codul poate fi implementat cu ușurință printr-un clic pe un buton. De asemenea, gestionarea infrastructurii în Kubernetes vă permite să nu vă gândiți la încărcare și scalare; astfel de probleme sunt rezolvate imediat. Și utilizarea unui singur depozit de date elimină necesitatea de a compara datele în timp real cu datele istorice, ceea ce simplifică munca analistului.
Ce avem
De când am venit la hackathon cu o soluție gata făcută (în fanteziile noastre), tot ce trebuia să facem a fost să ne transformăm toate gândurile în linii de cod.
Cheia succesului la orice hackathon este pregătirea și un plan bine scris. Prin urmare, primul lucru pe care l-am făcut a fost să decidem în ce module va consta arhitectura sistemului nostru și ce tehnologii vom folosi.
Arhitectura proiectului nostru a fost următoarea:
Această diagramă prezintă două puncte de intrare, analistul (utilizatorul principal al sistemului nostru) și clientul.
Procesul de lucru este structurat astfel. Analistul dezvoltă o funcție de regulă și o funcție de îmbogățire a datelor pentru modelul său, își stochează codul într-un depozit Git și își implementează modelul în cloud prin aplicația de administrator. Să luăm în considerare modul în care va fi apelată funcția implementată și să luăm decizii cu privire la solicitările primite de la clienți:
- Clientul completează un formular pe site și își trimite cererea către operator. O aplicație asupra căreia trebuie luată o decizie vine la intrarea sistemului și este înregistrată în baza de date în forma sa originală.
- În continuare, cererea brută este trimisă pentru îmbogățire, dacă este necesar. Puteți completa solicitarea inițială cu date atât de la servicii externe, cât și de la stocare. Interogarea îmbogățită rezultată este, de asemenea, stocată în baza de date.
- Este lansată funcția de analist, care preia o interogare îmbogățită ca intrare și produce o soluție, care este, de asemenea, scrisă în stocare.
Am decis să folosim MongoDB ca stocare în sistemul nostru datorită stocării de date orientate pe documente sub formă de documente JSON, deoarece serviciile de îmbogățire, inclusiv cererea inițială, au agregat toate datele prin controlere REST.
Deci, am avut XNUMX de ore pentru a implementa platforma. Am distribuit rolurile cu destul de mult succes; fiecare membru al echipei avea propria sa zonă de responsabilitate în proiectul nostru:
- Panouri de administrare front-end pentru munca analistului, prin care acesta putea descărca reguli din sistemul de control al versiunilor de scripturi scrise, selecta opțiuni pentru îmbogățirea datelor de intrare și edita scripturi de reguli online.
- Administrator backend, inclusiv API-ul REST pentru partea frontală și integrarea cu VCS.
- Configurarea infrastructurii în Google Cloud și dezvoltarea unui serviciu pentru îmbogățirea datelor sursă.
- Un modul pentru integrarea aplicației de administrare cu framework-ul Serverless pentru implementarea ulterioară a regulilor.
- Scripturi de reguli pentru testarea performanței întregului sistem și agregarea de analize pe aplicațiile primite (decizii luate) pentru demonstrația finală.
Să începem în ordine.
Interfața noastră a fost scrisă în Angular 7 folosind kitul de interfață bancară. Versiunea finală a panoului de administrare arăta astfel:
Deoarece a fost puțin timp, am încercat să implementăm doar funcționalitatea cheie. Pentru a implementa o funcție în clusterul Kubernetes, a fost necesar să selectați un eveniment (un serviciu pentru care trebuie implementată o regulă în cloud) și codul funcției care implementează logica decizională. Pentru fiecare implementare a unei reguli pentru serviciul selectat, am scris un jurnal al acestui eveniment. În panoul de administrare puteți vedea jurnalele tuturor evenimentelor.
Tot codul de funcție a fost stocat într-un depozit Git la distanță, care trebuia setat și în panoul de administrare. Pentru versiunea codului, toate funcțiile au fost stocate în diferite ramuri ale depozitului. Panoul de administrare oferă, de asemenea, posibilitatea de a face ajustări la scripturile scrise, astfel încât înainte de a implementa o funcție în producție, nu puteți doar să verificați codul scris, ci și să faceți modificările necesare.
Pe lângă funcțiile de reguli, am implementat și capacitatea de a îmbogăți treptat datele sursă folosind funcții de îmbogățire, al căror cod era și scripturi în care era posibil să mergeți la depozitul de date, să apelați servicii terțe și să efectuați calcule preliminare. . Pentru a demonstra soluția noastră, am calculat semnul zodiacal al clientului care a părăsit cererea și i-am determinat operatorul de telefonie mobilă folosind un serviciu REST terț.
Backend-ul platformei a fost scris în Java și implementat ca o aplicație Spring Boot. Inițial am plănuit să folosim Postgres pentru a stoca datele de administrare, dar, ca parte a hackathonului, am decis să ne limităm la un simplu H2 pentru a economisi timp. Pe backend, integrarea cu Bitbucket a fost implementată pentru a versiunea funcțiilor de îmbogățire a interogărilor și a scripturilor de reguli. Pentru integrarea cu depozitele Git la distanță, am folosit , care este un fel de wrapper peste comenzile CLI, permițându-vă să executați orice instrucțiuni git folosind o interfață software convenabilă. Deci am avut două depozite separate pentru funcții și reguli de îmbogățire, iar toate scripturile au fost împărțite în directoare. Prin interfața de utilizare a fost posibil să se selecteze cea mai recentă comitere a unui script dintr-o ramură arbitrară a depozitului. La efectuarea modificărilor codului prin panoul de administrare, comiterile codului modificat au fost create în arhivele de la distanță.
Pentru a ne implementa ideea, aveam nevoie de o infrastructură adecvată. Am decis să implementăm clusterul nostru Kubernetes în cloud. Alegerea noastră a fost Google Cloud Platform. Cadrul Fission fără server a fost instalat pe un cluster Kubernetes, pe care l-am implementat în Gcloud. Inițial, serviciul de îmbogățire a datelor sursă a fost implementat ca o aplicație Java separată, ambalată într-un Pod din clusterul k8s. Dar după o demonstrație preliminară a proiectului nostru în mijlocul hackatonului, ni s-a recomandat să facem serviciul de îmbogățire mai flexibil pentru a oferi posibilitatea de a alege cum să îmbogățim datele brute ale aplicațiilor primite. Și nu am avut de ales decât să facem serviciul de îmbogățire și Serverless.
Pentru a lucra cu Fission, am folosit Fission CLI, care trebuie instalat deasupra Kubernetes CLI. Implementarea funcțiilor într-un cluster k8s este destul de simplă; trebuie doar să atribuiți o rută internă și intrare la funcție pentru a permite traficul de intrare dacă este nevoie de acces în afara clusterului. De obicei, implementarea unei singure funcții nu durează mai mult de 10 secunde.
Prezentarea finală a proiectului și rezumatul
Pentru a demonstra cum funcționează sistemul nostru, am plasat un formular simplu pe un server la distanță unde puteți depune o cerere pentru unul dintre produsele băncii. Pentru a solicita, a trebuit să introduceți inițialele, data nașterii și numărul de telefon.
Datele din formularul de client au ajuns la controlor, care a trimis simultan solicitări pentru toate regulile disponibile, îmbogățind anterior datele conform condițiilor specificate și le-a salvat într-o stocare comună. În total, am implementat trei funcții care iau decizii privind aplicațiile primite și 4 servicii de îmbogățire a datelor. După depunerea cererii, clientul a primit decizia noastră:
Pe langa refuz sau aprobare, clientul a primit si o lista cu alte produse, solicitari pentru care am trimis in paralel. Așa am demonstrat posibilitatea vânzării încrucișate în platforma noastră.
Au fost disponibile un total de 3 produse bancare fictive:
- Credit.
- jucărie
- Credit ipotecar.
În timpul demonstrației, am implementat funcții pregătite și scripturi de îmbogățire pentru fiecare serviciu.
Fiecare regulă necesita propriul set de date de intrare. Deci, pentru a aproba o ipotecă, am calculat semnul zodiacal al clientului și am conectat acest lucru cu logica calendarului lunar. Pentru a aproba o jucărie, am verificat dacă clientul a împlinit vârsta majoratului, iar pentru a emite un împrumut, am trimis o solicitare către un serviciu extern deschis pentru determinarea operatorului de telefonie mobilă și s-a luat o decizie în acest sens.
Am încercat să facem demonstrația noastră interesantă și interactivă, toți cei prezenți au putut să acceseze formularul nostru și să verifice disponibilitatea serviciilor noastre fictive pentru ei. Și chiar la sfârșitul prezentării, am demonstrat analiza cererilor primite, care a arătat câte persoane au folosit serviciul nostru, numărul de aprobări și refuzuri.
Pentru a colecta analize online, am implementat suplimentar un instrument BI cu sursă deschisă și l-am înșurubat pe unitatea noastră de depozitare. Metabase vă permite să construiți ecrane cu analize pe datele care ne interesează; trebuie doar să înregistrați o conexiune la baza de date, să selectați tabele (în cazul nostru, colecții de date, deoarece am folosit MongoDB) și să specificați câmpurile care ne interesează. .
Drept urmare, am obținut un prototip bun de platformă de luare a deciziilor, iar în timpul demonstrației, fiecare ascultător și-a putut verifica personal performanța. O soluție interesantă, un prototip terminat și o demonstrație de succes ne-au permis să câștigăm, în ciuda concurenței puternice din partea altor echipe. Sunt sigur că se poate scrie și un articol interesant despre proiectul fiecărei echipe.
Sursa: www.habr.com