Od lanskega leta smo v našem podjetju začeli organizirati hackathone. Prvo tovrstno tekmovanje je bilo zelo uspešno, o njem smo pisali v . Drugi hackathon je potekal februarja 2019 in ni bil nič manj uspešen. O ciljih držanja slednjega ne tako dolgo nazaj organizator.
Udeleženci so dobili precej zanimivo nalogo s popolno svobodo pri izbiri tehnološkega sklada za njeno izvedbo. Treba je bilo uvesti platformo za sprejemanje odločitev za priročno uvajanje funkcij točkovanja strank, ki bi lahko delovale s hitrim pretokom aplikacij, vzdržale velike obremenitve, sam sistem pa je bil enostavno prilagodljiv.
Naloga je netrivialna in jo je mogoče rešiti na več načinov, o čemer smo se prepričali ob demonstraciji končnih predstavitev projektov udeležencev. Na hackathonu je sodelovalo 6 ekip po 5 ljudi, vsi udeleženci so imeli dobre projekte, vendar se je naša platforma izkazala za najbolj konkurenčno. Imamo zelo zanimiv projekt, o katerem bi rad govoril v tem članku.
Naša rešitev je platforma, ki temelji na brezstrežniški arhitekturi znotraj Kubernetesa, kar skrajša čas, potreben za prenos novih funkcij v proizvodnjo. Analitikom omogoča, da napišejo kodo v okolju, ki jim ustreza, in jo uvedejo v proizvodnjo brez sodelovanja inženirjev in razvijalcev.
Kaj je točkovanje
Tinkoff.ru, tako kot mnoga sodobna podjetja, ima točkovanje strank. Točkovanje je sistem ocenjevanja strank, ki temelji na statističnih metodah analize podatkov.
Na primer, stranka se obrne na nas z zahtevo, da mu izdamo posojilo ali odpremo račun samostojnega podjetnika pri nas. Če mu nameravamo izdati posojilo, potem moramo oceniti njegovo plačilno sposobnost, in če je račun samostojni podjetnik posameznik, potem moramo biti prepričani, da stranka ne bo izvajala goljufivih transakcij.
Osnova za sprejemanje tovrstnih odločitev so matematični modeli, ki analizirajo tako podatke iz same aplikacije kot tudi podatke iz naše hrambe. Poleg točkovanja lahko podobne statistične metode uporabimo tudi pri storitvi generiranja individualnih priporočil za nove izdelke za naše naročnike.
Metoda takšne ocene lahko sprejme različne vhodne podatke. In na neki točki lahko v vnos dodamo nov parameter, ki bo na podlagi rezultatov analize zgodovinskih podatkov povečal stopnjo konverzije uporabe storitve.
Imamo ogromno podatkov o odnosih s strankami in količina teh informacij nenehno narašča. Da bi točkovanje delovalo, obdelava podatkov zahteva tudi pravila (ali matematične modele), ki vam omogočajo, da se hitro odločite, komu odobriti prijavo, komu zavrniti in komu ponuditi še nekaj izdelkov ter oceniti njihov potencialni interes.
Za obravnavano nalogo že uporabljamo specializiran sistem odločanja , ki se na podlagi pravil, ki jih postavljajo analitiki, tehnologi in razvijalci, odloči, ali bo komitentu odobril ali zavrnil določen bančni produkt.
Na trgu je veliko že pripravljenih rešitev, tako modelov točkovanja kot samih sistemov odločanja. Enega od teh sistemov uporabljamo v našem podjetju. Toda posel raste, se diverzificira, povečujeta se tako število strank kot število ponujenih produktov, s tem pa se porajajo ideje, kako izboljšati obstoječi proces odločanja. Zagotovo imajo ljudje, ki delajo z obstoječim sistemom, veliko idej, kako ga narediti enostavnejšega, boljšega, priročnejšega, a včasih so ideje od zunaj koristne. New Hackathon je bil organiziran z namenom zbiranja dobrih idej.
Naloga
Hackathon je potekal 23. februarja. Udeležencem je bila ponujena bojna naloga: razviti sistem odločanja, ki je moral izpolnjevati številne pogoje.
Povedali smo, kako deluje obstoječi sistem in kakšne težave se pojavljajo pri njegovem delovanju ter kakšne poslovne cilje naj bi zasledovala razvita platforma. Sistem mora imeti hiter čas do trga za razvoj pravil, tako da delovna koda analitikov pride v proizvodnjo čim hitreje. In za dohodni tok vlog bi moral biti čas odločanja minimalen. Prav tako mora sistem, ki se razvija, imeti zmožnosti navzkrižne prodaje, da stranki omogoči nakup drugih izdelkov podjetja, če jih odobrimo mi in imajo potencialno zanimanje stranke.
Jasno je, da je nemogoče čez noč napisati pripravljen projekt, ki bo zagotovo šel v produkcijo, in kar težko je pokriti celoten sistem, zato smo bili pozvani, da implementiramo vsaj del. Postavljene so bile številne zahteve, ki jih mora prototip izpolnjevati. Možno je bilo poskusiti tako pokriti vse zahteve v celoti, kot tudi podrobno obdelati posamezne dele platforme v razvoju.
Kar zadeva tehnologijo, so vsi udeleženci imeli popolno svobodo izbire. Uporabiti je bilo mogoče vse koncepte in tehnologije: pretakanje podatkov, strojno učenje, pridobivanje dogodkov, veliki podatki in druge.
Naša rešitev
Po kratkem razmišljanju smo se odločili, da bi bila rešitev FaaS idealna za dokončanje naloge.
Za to rešitev je bilo treba najti primeren brezstrežniški okvir za implementacijo pravil sistema odločanja v razvoju. Ker Tinkoff aktivno uporablja Kubernetes za upravljanje infrastrukture, smo si ogledali več že pripravljenih rešitev, ki temeljijo na njem; več o tem vam bom povedal kasneje.
Da bi našli najučinkovitejšo rešitev, smo izdelek, ki se razvija, pogledali skozi oči njegovih uporabnikov. Glavni uporabniki našega sistema so analitiki, ki sodelujejo pri razvoju pravil. Pravila morajo biti razporejena na strežnik ali, kot v našem primeru, razporejena v oblaku za kasnejše odločanje. Z vidika analitika je potek dela videti takole:
- Analitik na podlagi podatkov iz skladišča napiše skripto, pravilo ali model ML. V okviru hackathona smo se odločili za Mongodb, vendar izbira sistema za shranjevanje podatkov tu ni pomembna.
- Po testiranju razvitih pravil na zgodovinskih podatkih analitik naloži svojo kodo v skrbniško ploščo.
- Za zagotovitev različic bo vsa koda šla v repozitorije Git.
- Prek skrbniške plošče bo mogoče kodo namestiti v oblak kot ločen funkcionalni modul brez strežnika.
Začetni podatki strank morajo iti skozi specializirano obogatitveno storitev, namenjeno obogatitvi začetne zahteve s podatki iz skladišča. Pomembno je bilo implementirati to storitev tako, da bo delovala z enim samim repozitorijem (iz katerega analitik jemlje podatke pri razvoju pravil), da bo ohranila enotno strukturo podatkov.
Že pred hackathonom smo se odločili za Serverless framework, ki ga bomo uporabljali. Danes je na trgu kar nekaj tehnologij, ki izvajajo ta pristop. Najbolj priljubljene rešitve znotraj arhitekture Kubernetes so Fission, Open FaaS in Kubeless. Obstajajo celo .
Po tehtanju vseh prednosti in slabosti smo izbrali . To ogrodje brez strežnika je precej enostavno za upravljanje in izpolnjuje zahteve naloge.
Za delo s Fission morate razumeti dva osnovna pojma: funkcijo in okolje. Funkcija je del kode, napisan v enem od jezikov, za katere obstaja okolje Fission. vključuje Python, JS, Go, JVM in številne druge priljubljene jezike in tehnologije.
Fission je sposoben izvajati tudi funkcije, razdeljene na več datotek, vnaprej zapakiranih v arhiv. Delovanje Fission v gruči Kubernetes zagotavljajo specializirani podi, ki jih upravlja samo ogrodje. Za interakcijo s sklopi gruč mora biti vsaki funkciji dodeljena lastna pot, ki ji lahko posredujete parametre GET ali telo zahteve v primeru zahteve POST.
Posledično smo načrtovali pridobitev rešitve, ki bi analitikom omogočila uvajanje razvitih skriptov pravil brez sodelovanja inženirjev in razvijalcev. Opisani pristop tudi odpravlja potrebo, da bi razvijalci prepisali analitično kodo v drug jezik. Na primer, za trenutni sistem odločanja, ki ga uporabljamo, moramo pravila napisati v visoko specializiranih tehnologijah in jezikih, katerih obseg je izjemno omejen, obstaja pa tudi močna odvisnost od aplikacijskega strežnika, saj vsi osnutki bančnih pravil so razporejeni v enem samem okolju. Posledično je za uvedbo novih pravil potrebno sprostiti celoten sistem.
V naši predlagani rešitvi ni potrebe po izdaji pravil; kodo je mogoče preprosto namestiti s klikom na gumb. Tudi upravljanje infrastrukture v Kubernetesu vam omogoča, da ne razmišljate o obremenitvi in skaliranju; takšne težave so rešene takoj. In uporaba enotnega podatkovnega skladišča odpravlja potrebo po primerjavi podatkov v realnem času z zgodovinskimi podatki, kar poenostavi delo analitika.
Kar imamo
Ker smo na hackathon prišli z že pripravljeno rešitvijo (v naših fantazijah), smo morali vse svoje misli pretvoriti v vrstice kode.
Ključ do uspeha na vsakem hackathonu sta priprava in dobro napisan načrt. Zato smo se najprej odločili, iz katerih modulov bo sestavljena naša sistemska arhitektura in katere tehnologije bomo uporabili.
Arhitektura našega projekta je bila naslednja:
Ta diagram prikazuje dve vstopni točki, analitika (glavnega uporabnika našega sistema) in odjemalca.
Delovni proces je strukturiran tako. Analitik razvije funkcijo pravila in funkcijo obogatitve podatkov za svoj model, shrani svojo kodo v repozitorij Git in prek skrbniške aplikacije razmesti svoj model v oblak. Razmislimo, kako bo razporejena funkcija klicana in sprejemamo odločitve o dohodnih zahtevah odjemalcev:
- Stranka izpolni obrazec na spletni strani in pošlje zahtevo upravljavcu. Vloga, o kateri se je treba odločiti, pride na vhod sistema in se v izvorni obliki zabeleži v bazi podatkov.
- Nato se neobdelana zahteva pošlje v obogatitev, če je potrebno. Začetno zahtevo lahko dopolnite s podatki tako iz zunanjih storitev kot iz pomnilnika. Nastala obogatena poizvedba se prav tako shrani v bazo podatkov.
- Zažene se analitična funkcija, ki kot vhod sprejme obogateno poizvedbo in izdela rešitev, ki se prav tako zapiše v shrambo.
Za uporabo MongoDB kot shrambe v našem sistemu smo se odločili zaradi dokumentno usmerjenega shranjevanja podatkov v obliki dokumentov JSON, saj so obogatitvene storitve, vključno s prvotno zahtevo, vse podatke agregirale preko krmilnikov REST.
Tako smo imeli XNUMX ur časa za implementacijo platforme. Vloge smo dokaj uspešno porazdelili, vsak član ekipe je imel v našem projektu svoje področje odgovornosti:
- Front-end skrbniške plošče za delo analitika, preko katerih je lahko prenašal pravila iz sistema za nadzor različic pisnih skriptov, izbiral možnosti obogatitve vhodnih podatkov in urejal skripte pravil na spletu.
- Backend admin, vključno z REST API za sprednjo stran in integracijo z VCS.
- Postavitev infrastrukture v Google Cloud in razvoj storitve za obogatitev izvornih podatkov.
- Modul za integracijo skrbniške aplikacije z ogrodjem brez strežnika za kasnejšo uvedbo pravil.
- Skripte pravil za testiranje delovanja celotnega sistema in združevanje analitike o prejetih aplikacijah (sprejetih odločitvah) za končno predstavitev.
Začnimo v redu.
Naš vmesnik je bil napisan v Angular 7 z uporabo bančnega uporabniškega vmesnika. Končna različica skrbniške plošče je izgledala takole:
Ker je bilo časa malo, smo poskušali implementirati le ključne funkcionalnosti. Za uvedbo funkcije v gruči Kubernetes je bilo potrebno izbrati dogodek (storitev, za katero je potrebno v oblaku razmestiti pravilo) in kodo funkcije, ki implementira logiko odločanja. Za vsako uvedbo pravila za izbrano storitev smo zapisali dnevnik tega dogodka. V skrbniški plošči si lahko ogledate dnevnike vseh dogodkov.
Vsa funkcijska koda je bila shranjena v oddaljenem repozitoriju Git, ki ga je bilo prav tako treba nastaviti v skrbniški plošči. Za različico kode so bile vse funkcije shranjene v različnih vejah repozitorija. Skrbniška plošča nudi tudi možnost prilagajanja napisanih skriptov, tako da pred uvedbo funkcije v produkcijo ne morete samo preveriti napisane kode, ampak tudi izvesti potrebne spremembe.
Poleg pravilnih funkcij smo implementirali tudi možnost postopnega obogatitve izvornih podatkov z obogatitvenimi funkcijami, katerih koda so bile tudi skripte, v katerih je bilo mogoče iti v podatkovno skladišče, klicati storitve tretjih oseb in izvajati predizračune. . Za predstavitev naše rešitve smo izračunali zodiakalni znak stranke, ki je zapustila zahtevo, in določili njegovega mobilnega operaterja s pomočjo storitve REST tretje osebe.
Zaledje platforme je bilo napisano v Javi in implementirano kot aplikacija Spring Boot. Sprva smo nameravali uporabiti Postgres za shranjevanje skrbniških podatkov, vendar smo se kot del hackathona odločili, da se omejimo na preprost H2, da bi prihranili čas. V ozadju je bila implementirana integracija z Bitbucket za različico funkcij obogatitve poizvedb in skriptov pravil. Za integracijo z oddaljenimi repozitoriji Git smo uporabili , ki je nekakšen ovoj nad ukazi CLI, ki vam omogoča izvajanje poljubnih navodil git z uporabo priročnega programskega vmesnika. Tako smo imeli dve ločeni repozitoriji za obogatitvene funkcije in pravila, vsi skripti pa so bili razdeljeni v imenike. Prek uporabniškega vmesnika je bilo mogoče izbrati zadnjo objavo skripta poljubne veje skladišča. Pri spreminjanju kode prek skrbniške plošče so bile objave spremenjene kode ustvarjene v oddaljenih repozitorijih.
Za uresničitev naše zamisli smo potrebovali ustrezno infrastrukturo. Odločili smo se, da našo gručo Kubernetes postavimo v oblak. Naša izbira je bila Google Cloud Platform. Brezstrežniško ogrodje Fission je bilo nameščeno na gručo Kubernetes, ki smo jo namestili v Gcloud. Sprva je bila storitev obogatitve izvornih podatkov implementirana kot ločena aplikacija Java, zavita v Pod znotraj gruče k8s. Toda po predhodni predstavitvi našega projekta sredi hackathona so nam priporočili, da naredimo storitev obogatitve bolj prilagodljivo, da bi zagotovili možnost izbire, kako obogatiti neobdelane podatke dohodnih aplikacij. In nismo imeli druge izbire, kot da storitev obogatitve naredimo tudi brez strežnika.
Za delo s Fission smo uporabili Fission CLI, ki mora biti nameščen na vrhu Kubernetes CLI. Namestitev funkcij v gručo k8s je precej preprosta; funkciji morate samo dodeliti notranjo pot in vstop, da omogočite dohodni promet, če je potreben dostop zunaj gruče. Uvajanje ene funkcije običajno ne traja več kot 10 sekund.
Končna predstavitev projekta in povzetek
Za predstavitev delovanja našega sistema smo na oddaljenem strežniku postavili preprost obrazec, kjer lahko oddate vlogo za enega od produktov banke. Za zahtevo ste morali vnesti svoje začetnice, datum rojstva in telefonsko številko.
Podatki iz obrazca odjemalca so šli do upravljavca, ki je hkrati pošiljal zahteve po vseh razpoložljivih pravilih, pri čemer je podatke predhodno obogatil glede na podane pogoje in jih shranil v skupno shrambo. Skupno smo uvedli tri funkcije, ki odločajo o prejetih aplikacijah in 4 storitve obogatitve podatkov. Po oddaji prijave je naročnik prejel našo odločitev:
Poleg zavrnitve ali odobritve je stranka prejela tudi seznam drugih izdelkov, povpraševanja po katerih smo pošiljali vzporedno. Tako smo prikazali možnost navzkrižne prodaje v naši platformi.
Na voljo so bili skupaj 3 fiktivni bančni produkti:
- Kredit.
- Igrača
- Hipoteka.
Med predstavitvijo smo razmestili pripravljene funkcije in obogatitvene skripte za vsako storitev.
Vsako pravilo je zahtevalo svoj niz vhodnih podatkov. Tako smo za odobritev hipoteke izračunali horoskopsko znamenje stranke in ga povezali z logiko luninega koledarja. Za odobritev igrače smo preverili, ali je stranka polnoletna, za izdajo posojila pa smo poslali zahtevo zunanji odprti službi za določitev mobilnega operaterja in o tem je bila sprejeta odločitev.
Poskušali smo narediti našo predstavitev zanimivo in interaktivno, vsi prisotni so lahko šli na naš obrazec in preverili dostopnost naših izmišljenih storitev za njih. Čisto na koncu predstavitve pa smo prikazali še analitiko prejetih prijav, iz katere je razvidno, koliko ljudi uporablja našo storitev, število odobritev in zavrnitev.
Za zbiranje analitike na spletu smo dodatno uvedli odprtokodno orodje BI in ga privili na našo skladiščno enoto. Metabase omogoča izdelavo zaslonov z analitiko na podatkih, ki nas zanimajo, le registrirati morate povezavo z bazo, izbrati tabele (v našem primeru zbirke podatkov, saj smo uporabili MongoDB) in določiti polja, ki nas zanimajo. .
Kot rezultat smo dobili dober prototip platforme za odločanje, med demonstracijo pa je lahko vsak poslušalec osebno preveril njeno delovanje. Zanimiva rešitev, dodelan prototip in uspešna demonstracija so nam omogočili zmago kljub močni konkurenci drugih ekip. Prepričan sem, da se da tudi o projektu vsake ekipe napisati zanimiv članek.
Vir: www.habr.com