A partesi di l'annu passatu, a nostra cumpagnia hà cuminciatu à urganizà hackathons. U primu tali cuncorsu hè statu assai successu, avemu scrittu annantu à questu . U sicondu hackathon hè accadutu in ferraghju 2019 è ùn hè micca menu successu. Riguardu à i scopi di mantene l'ultime micca tantu tempu fà urganizatore.
I participanti sò stati datu un compitu piuttostu interessante cù una libertà completa in a scelta di una pila di tecnulugia per a so implementazione. Era necessariu implementà una piattaforma di decisione per una implementazione còmoda di funzioni di puntuazione di u cliente chì puderia travaglià cù un flussu veloce di applicazioni, sustene carichi pesanti, è u sistema stessu era facilmente scalabile.
U compitu ùn hè micca triviale è pò esse risoltu in parechje manere, cum'è eramu cunvinti durante a manifestazione di e presentazioni finali di i prughjetti di i participanti. Ci era 6 squadre di 5 persone à l'hackathon, tutti i participanti avianu boni prughjetti, ma a nostra piattaforma hè stata a più cumpetitiva. Avemu un prughjettu assai interessante, chì vogliu parlà in questu articulu.
A nostra suluzione hè una piattaforma basata nantu à l'architettura Serverless in Kubernetes, chì riduce u tempu chì ci vole à purtà novi funziunalità à a produzzione. Permette à l'analista di scrive codice in un ambiente cunvene per elli è implementà in a produzzione senza a participazione di ingegneri è sviluppatori.
Ciò chì hè puntuatu
Tinkoff.ru, cum'è parechje cumpagnie muderne, hà puntuazione di i clienti. Scoring hè un sistema di valutazione di i clienti basatu annantu à metudi statistichi di analisi di dati.
Per esempiu, un cliente si rivolta à noi cù una dumanda per issuà ellu un prestitu, o apre un contu entrepreneur individuale cun noi. Se pensamu à emette un prestitu, allora avemu bisognu di valutà a so solvibilità, è se u contu hè un entrepreneur individuale, allora avemu da esse sicuru chì u cliente ùn hà micca fattu transazzione fraudulenta.
A basa per piglià tali decisioni sò mudelli matematichi chì analizanu i dati da l'applicazione stessa è i dati da u nostru almacenamentu. In più di scoring, metudi statistici simili ponu ancu esse aduprati in u serviziu di generazione di cunsiglii individuali per novi prudutti per i nostri clienti.
U metudu di tali valutazione pò accettà una varietà di dati di input. È in un certu puntu pudemu aghjunghje un novu paràmetru à l'input, chì, basatu nantu à i risultati di l'analisi nantu à e dati storichi, aumenterà a rata di cunversione di usu di u serviziu.
Tenemu una ricchezza di dati nantu à e relazioni cù i clienti, è u voluminu di sta informazione hè in constantemente crescente. Per u puntuazione per travaglià, u trattamentu di dati richiede ancu e regule (o mudelli matematichi) chì permettenu di decide rapidamente quale appruvà una dumanda, quale ricusà, è quale offre un coppiu di più prudutti, valutendu u so interessu potenziale.
Per u compitu in manu, avemu digià aduprà un sistema di decisione specializatu , chì, basatu nantu à e regule stabilite da analisti, tecnulugichi è sviluppatori, decide di appruvà o ricusà un pruduttu bancariu particulari à u cliente.
Ci sò parechje suluzioni pronti nantu à u mercatu, sia mudelli di scoring sia sistemi di decisione stessi. Avemu aduprà unu di sti sistemi in a nostra cumpagnia. Ma l'affari cresce, si diversifica, sia u numeru di i clienti sia u numeru di prudutti offerti sò in crescita, è cun questu, spuntanu idee nantu à cumu migliurà u prucessu di decisione esistenti. Di sicuru, e persone chì travaglianu cù u sistema esistenti anu parechje idee nantu à cumu fà più simplice, megliu, più convenientu, ma qualchì volta l'idee da fora sò utili. U Novu Hackathon hè statu urganizatu cù u scopu di cullà idee sonu.
Task
U hackathon hè statu fattu u 23 di ferraghju. I participanti sò stati pruposti un compitu di cummattimentu: per sviluppà un sistema di decisione chì avia da scuntrà una quantità di cundizioni.
Ci hè statu dettu cumu funziona u sistema esistenti è quali difficultà surghjenu durante u so funziunamentu, è ancu chì scopi di cummerciale deve perseguite a piattaforma sviluppata. U sistema deve avè un rapidu time-to-market per u sviluppu di e regule per chì u codice di travagliu di l'analisti entra in produzzione u più prestu pussibule. È per u flussu entrante di applicazioni, u tempu di decisione deve tende à u minimu. Inoltre, u sistema chì hè sviluppatu deve avè capacità di vendita incrociata per dà à u cliente l'uppurtunità di cumprà altri prudutti di a cumpagnia s'ellu sò appruvati da noi è avè un interessu potenziale da u cliente.
Hè chjaru chì hè impussibile di scrive un prughjettu prontu à liberazione per a notte chì certamenti entrerà in produzzione, è hè abbastanza difficiule di copre tuttu u sistema, cusì ci hè statu dumandatu à implementà almenu una parte di questu. Una quantità di esigenze sò state stabilite chì u prototipu deve suddisfà. Hè statu pussibule di pruvà sia per copre tutte e esigenze in a so sanu, sia per travaglià in dettagliu nantu à e sezioni individuali di a piattaforma sviluppata.
In quantu à a tecnulugia, tutti i participanti anu datu una libertà completa di scelta. Hè statu pussibule di utilizà qualsiasi cuncetti è tecnulugia: Streaming di dati, apprendimentu di machine, sourcing event, big data è altri.
A nostra suluzione
Dopu un pocu di brainstorming, avemu decisu chì una suluzione FaaS seria l'ideale per cumpiendu u compitu.
Per sta suluzione, era necessariu di truvà un framework Serverless adattatu per implementà e regule di u sistema di decisione chì hè sviluppatu. Siccomu Tinkoff usa attivamente Kubernetes per a gestione di l'infrastruttura, avemu guardatu parechje soluzioni pronte basate nantu à questu; Vi dicu più nantu à questu più tardi.
Per truvà a suluzione più efficace, avemu vistu u pruduttu sviluppatu à traversu l'ochji di i so utilizatori. I principali utilizatori di u nostru sistema sò analisti implicati in u sviluppu di e regule. E regule deve esse implementate à u servitore, o, cum'è in u nostru casu, implementate in u nuvulu, per a decisione sussegwente. Da a perspettiva di un analista, u flussu di travagliu hè cusì:
- L'analista scrive un script, regula, o mudellu ML basatu nantu à e dati da u magazzinu. Comu parte di l'hackathon, avemu decisu di utilizà Mongodb, ma l'scelta di u sistema di almacenamiento di dati ùn hè micca impurtante quì.
- Dopu avè pruvatu e regule sviluppate nantu à e dati storichi, l'analista carica u so codice à u panel admin.
- Per assicurà a versione, tuttu u codice andarà à i repositori Git.
- Per mezu di u pannellu di amministrazione, serà pussibule implementà u codice in u nuvulu cum'è un modulu senza Serverless funziunale separatu.
I dati iniziali da i clienti devenu passà per un serviziu di arricchimentu specializatu cuncepitu per arricchisce a dumanda iniziale cù dati da u magazzinu. Hè stata impurtante di implementà stu serviziu in tale manera chì travaglià cù un repository unicu (da quale l'analista piglia dati in u sviluppu di e regule) per mantene una struttura di dati unificata.
Ancu prima di l'hackathon, avemu decisu di u framework Serverless chì avemu aduprà. Oghje, ci sò assai tecnulugia in u mercatu chì implementanu stu approcciu. E soluzioni più populari in l'architettura Kubernetes sò Fission, Open FaaS è Kubeless. Ci sò ancu .
Dopu à pisà tutti i vantaghji è i contra, avemu sceltu . Stu framework Serverless hè abbastanza faciule da gestisce è risponde à i requisiti di u compitu.
Per travaglià cù Fission, avete bisognu di capiscenu dui cuncetti basi: funzione è ambiente. Una funzione hè un pezzu di codice scrittu in una di e lingue per quale ci hè un ambiente Fission. include Python, JS, Go, JVM è parechje altre lingue è tecnulugia populari.
Fission hè ancu capaci di eseguisce funzioni divisu in parechji schedari, pre-imballate in un archiviu. L'operazione di Fission in un cluster Kubernetes hè assicurata da pods specializati, chì sò gestiti da u quadru stessu. Per interagisce cù u cluster pods, ogni funzione deve esse assignata a so propria strada, è à quale pudete passà i parametri GET o dumandà u corpu in u casu di una dumanda POST.
In u risultatu, avemu previstu di ottene una soluzione chì permette à l'analista di implementà script di regule sviluppati senza a participazione di ingegneri è sviluppatori. L'approcciu descrittu elimina ancu a necessità per i sviluppatori di riscrive u codice di l'analista in una altra lingua. Per esempiu, per u sistema di decisione attuale chì usemu, avemu da scrive regule in tecnulugii è lingue altamente specializate, u scopu di quale hè estremamente limitatu, è ci hè ancu una forte dipendenza da u servitore di l'applicazioni, postu chì tutti i prughjetti di e regule bancarie. sò disposti in un ambiente unicu. In u risultatu, per implementà novi regule, hè necessariu di liberà tuttu u sistema.
In a nostra suluzione pruposta, ùn ci hè bisognu di liberà e regule; u codice pò esse facilmente implementatu à u clicu di un buttone. Inoltre, a gestione di l'infrastruttura in Kubernetes permette micca di pensà à a carica è à a scala; tali prublemi sò risolti fora di a scatula. È l'usu di un unicu magazzinu di dati elimina a necessità di paragunà dati in tempu reale cù dati storichi, chì simplificà u travagliu di l'analista.
Chì avemu avutu
Siccomu avemu ghjuntu à l'hackathon cù una suluzione pronta (in i nostri fantasii), tuttu ciò chì duvemu fà era cunvertisce tutti i nostri pinsamenti in linee di codice.
A chjave per u successu in ogni hackathon hè a preparazione è un pianu ben scrittu. Dunque, a prima cosa chì avemu fattu era decide di quali moduli a nostra architettura di sistema si compone di e tecnulugia chì avemu aduprà.
L'architettura di u nostru prughjettu era cusì:
Stu diagramma mostra dui punti di entrata, l'analista (l'utilizatore principale di u nostru sistema) è u cliente.
U prucessu di travagliu hè strutturatu cusì. L'analista sviluppa una funzione di regula è una funzione d'arricchimentu di dati per u so mudellu, guarda u so codice in un repository Git, è implementa u so mudellu à u nuvulu attraversu l'applicazione amministratore. Cunsideremu cumu si chjamarà a funzione implementata è pigliate decisioni nantu à e richieste entrate da i clienti:
- U cliente compie un furmulariu nantu à u situ web è manda a so dumanda à u controller. Una applicazione nantu à quale una decisione deve esse fatta vene à l'input di u sistema è hè arregistrata in a basa di dati in a so forma originale.
- In seguitu, a dumanda prima hè mandata per arricchimentu, se ne necessariu. Pudete supplementà a dumanda iniziale cù dati da i servizii esterni è da u almacenamentu. A ricerca arricchita risultante hè ancu almacenata in a basa di dati.
- A funzione di l'analista hè lanciata, chì piglia una dumanda arricchita cum'è input è pruduce una suluzione, chì hè ancu scritta à l'almacenamiento.
Avemu decisu d'utilizà MongoDB cum'è un almacenamentu in u nostru sistema per via di l'almacenamiento documentatu di dati in forma di documenti JSON, postu chì i servizii di arricchimentu, cumpresa a dumanda originale, aggregate tutte e dati attraversu i controller REST.
Dunque, avemu avutu XNUMX ore per implementà a piattaforma. Avemu distribuitu i roli abbastanza bè; ogni membru di a squadra avia a so propria zona di rispunsabilità in u nostru prughjettu:
- Pannelli admin front-end per u travagliu di l'analista, attraversu quale puderia scaricà regule da u sistema di cuntrollu di versione di script scritti, selezziunà l'opzioni per arricchisce i dati di input è edità script di regula in linea.
- Amministratore di backend, cumprese l'API REST per u fronte è integrazione cù VCS.
- Stabbilimentu di l'infrastruttura in Google Cloud è sviluppà un serviziu per arricchisce i dati di fonte.
- Un modulu per integrà l'applicazione admin cù u framework Serverless per a implementazione successiva di e regule.
- Scripts di regule per pruvà a prestazione di tuttu u sistema è aggregazione di l'analitiche nantu à l'applicazioni entranti (decisioni prese) per a dimostrazione finale.
Cuminciamu in ordine.
U nostru frontend hè statu scrittu in Angular 7 utilizendu u Kit UI bancariu. A versione finale di u pannellu di amministrazione pareva cusì:
Siccomu ci era pocu tempu, avemu pruvatu à implementà solu a funziunalità chjave. Per implementà una funzione in un cluster Kubernetes, era necessariu di selezziunà un avvenimentu (un serviziu per quale una regula deve esse implementata in u nuvulu) è u codice di a funzione chì implementa a logica di decisione. Per ogni implementazione di una regula per u serviziu sceltu, avemu scrittu un logu di questu avvenimentu. In u panel admin pudete vede logs di tutti l'avvenimenti.
Tuttu u codice di funzione hè stata guardata in un repository Git remotu, chì ancu deve esse stabilitu in u panel admin. Per versionà u codice, tutte e funzioni sò state guardate in diverse rami di u repository. U pannellu admin furnisce ancu a capacità di fà aghjustamenti à i script scritti, perchè prima di implementà una funzione à a produzzione, pudete micca solu verificà u codice scrittu, ma ancu fà i cambiamenti necessarii.
In più di e funzioni di e regule, avemu ancu implementatu a capacità di arricchisce gradualmente i dati fonte cù e funzioni di arricchimentu, u codice di quale era ancu script in quale era pussibule andà in u magazzinu di dati, chjamate servizii di terzu è eseguisce calculi preliminari. . Per dimustrà a nostra suluzione, avemu calculatu u signu di u zodiacu di u cliente chì abbandunò a dumanda è hà determinatu u so operatore mobile utilizendu un serviziu REST di terzu.
U backend di a piattaforma hè statu scrittu in Java è implementatu cum'è una applicazione Spring Boot. Inizialmente, avemu pensatu à aduprà Postgres per almacenà e dati di l'amministratore, ma, cum'è parte di l'hackathon, avemu decisu di limità à un H2 simplice per risparmià tempu. In u backend, l'integrazione cù Bitbucket hè stata implementata per versionà e funzioni d'arricchimentu di e dumande è i script di regula. Per l'integrazione cù i repositori Git remoti, avemu usatu , chì hè un tipu di wrapper nantu à i cumandamenti CLI, chì vi permette di eseguisce qualsiasi struzzioni git utilizendu una interfaccia di software còmuda. Allora avemu avutu dui repositori separati per e funzioni di arricchimentu è e regule, è tutti i scripts eranu spartuti in cartulari. Per mezu di l'UI era pussibule di selezziunà l'ultimu commit di un script di un ramu arbitrariu di u repository. Quandu fate cambiamenti à u codice per mezu di u pannellu admin, i cummissioni di u codice cambiatu sò stati creati in repositori remoti.
Per implementà a nostra idea, avemu bisognu di infrastruttura adatta. Avemu decisu di implementà u nostru cluster Kubernetes in u nuvulu. A nostra scelta era Google Cloud Platform. U framework senza server Fission hè statu stallatu nantu à un cluster Kubernetes, chì avemu implementatu in Gcloud. Inizialmente, u serviziu di arricchimentu di dati di fonte hè statu implementatu cum'è una applicazione Java separata impannillata in un Pod in u cluster k8s. Ma dopu una dimostrazione preliminare di u nostru prughjettu in u mezzu di l'hackathon, ci hè statu cunsigliatu per fà u serviziu di arricchimentu più flexible per furnisce l'uppurtunità di sceglie cumu arricchisce i dati prima di l'applicazioni entranti. È ùn avemu avutu altra scelta ma di fà u serviziu di arricchimentu ancu Serverless.
Per travaglià cù Fission, avemu usatu u Fission CLI, chì deve esse installatu nantu à u Kubernetes CLI. L'implementazione di funzioni in un cluster k8s hè abbastanza simplice; basta à assignà una strada interna è entrata à a funzione per permette u trafficu entrante se l'accessu fora di u cluster hè necessariu. L'implementazione di una funzione ùn dura micca più di 10 seconde.
Presentazione finale di u prugettu è riassuntu
Per dimustrà u funziunamentu di u nostru sistema, avemu postu una forma simplice nantu à un servitore remotu induve pudete mandà una dumanda per unu di i prudutti di u bancu. Per dumandà, duvete inserisce e vostre iniziali, data di nascita è numeru di telefunu.
I dati da a forma di u cliente sò andati à u controller, chì simultaneamente hà mandatu dumande per tutte e regule dispunibili, avè arricchitu prima i dati secondu e cundizioni specificate, è salvatu in un almacenamiento cumunu. In totale, avemu implementatu trè funzioni chì facenu decisioni nantu à l'applicazioni in entrata è 4 servizii di arricchimentu di dati. Dopu avè mandatu l'applicazione, u cliente hà ricevutu a nostra decisione:
In più di u rifiutu o l'appruvazioni, u cliente hà ancu ricevutu una lista di altri prudutti, dumande per quale avemu mandatu in parallelu. Hè cusì chì avemu dimustratu a pussibilità di vendita incruciata in a nostra piattaforma.
Ci era un totale di 3 prudutti bancari fittizi dispunibili:
- Creditu.
- Toy
- Mortgage.
Durante a manifestazione, avemu implementatu funzioni preparate è script di arricchimentu per ogni serviziu.
Ogni regula necessitava u so propiu set di dati di input. Allora, per appruvà una ipoteka, avemu calculatu u signu di u zodiacu di u cliente è cunnessu questu cù a logica di u calendariu lunar. Per appruvà un ghjoculu, avemu verificatu chì u cliente avia righjuntu l'età di a maiurità, è per emette un prestitu, avemu mandatu una dumanda à un serviziu apertu esternu per a determinazione di l'operatore cellulare, è una decisione hè stata presa.
Avemu pruvatu à fà a nostra manifestazione interessante è interattiva, tutti i prisenti puderanu andà à a nostra forma è verificà a dispunibilità di i nostri servizii fittiziali per elli. È à a fine di a presentazione, avemu dimustratu l'analitiche di l'applicazioni ricevute, chì dimustrava quante persone anu utilizatu u nostru serviziu, u numeru di appruvazioni è i rifiuti.
Per cullà l'analitiche in linea, avemu ancu implementatu un strumentu BI open source è l'hà avvitatu à a nostra unità di almacenamento. Metabase permette di custruisce schermi cù analitiche nantu à e dati chì ci interessanu; basta à registrà una cunnessione à a basa di dati, selezziunate e tavule (in u nostru casu, cullezzione di dati, postu chì avemu usatu MongoDB), è specificà i campi di interessu per noi. .
In u risultatu, avemu un bonu prototipu di una piattaforma di decisione, è durante a manifestazione, ogni ascoltatore puderia cuntrollà personalmente a so prestazione. Una suluzione interessante, un prototipu finitu è una dimostrazione di successu ci hà permessu di vince, malgradu a forte cumpetizione di l'altri squadre. Sò sicuru chì un articulu interessante pò ancu esse scrittu annantu à u prugettu di ogni squadra.
Source: www.habr.com