Od prošle godine naša tvrtka počela je organizirati hackathone. Prvo takvo natjecanje bilo je vrlo uspješno, pisali smo o tome u . Drugi hackathon održan je u veljači 2019. i nije bio ništa manje uspješan. O ciljevima održavanja potonjeg ne tako davno organizator.
Sudionici su dobili prilično zanimljiv zadatak uz potpunu slobodu u odabiru tehnološkog skupa za njegovu implementaciju. Bilo je potrebno implementirati platformu za donošenje odluka za prikladnu implementaciju funkcija bodovanja kupaca koja može raditi s brzim protokom aplikacija, izdržati velika opterećenja, a sam sustav je lako skalabilan.
Zadatak nije trivijalan i može se riješiti na mnogo načina, u što smo se uvjerili tijekom demonstracije završnih prezentacija projekata sudionika. Na hackathonu je bilo 6 timova od po 5 ljudi, svi su sudionici imali dobre projekte, ali se naša platforma pokazala najkonkurentnijom. Imamo vrlo zanimljiv projekt o kojem bih želio govoriti u ovom članku.
Naše rješenje je platforma temeljena na arhitekturi bez poslužitelja unutar Kubernetesa, što smanjuje vrijeme potrebno za uvođenje novih značajki u proizvodnju. Omogućuje analitičarima da pišu kod u okruženju koje im odgovara i da ga implementiraju u proizvodnju bez sudjelovanja inženjera i programera.
Što je bodovanje
Tinkoff.ru, kao i mnoge moderne tvrtke, ima bodovanje kupaca. Scoring je sustav procjene kupaca koji se temelji na statističkim metodama analize podataka.
Na primjer, klijent nam se obrati sa zahtjevom da mu izdamo kredit ili otvorimo kod nas račun samostalnog poduzetnika. Ako mu planiramo izdati zajam, tada moramo procijeniti njegovu solventnost, a ako je račun samostalni poduzetnik, tada moramo biti sigurni da klijent neće provoditi lažne transakcije.
Temelj za donošenje takvih odluka su matematički modeli koji analiziraju kako podatke iz same aplikacije tako i podatke iz naše pohrane. Osim bodovanja, slične statističke metode mogu se koristiti iu službi generiranja individualnih preporuka za nove proizvode za naše klijente.
Metoda takve procjene može prihvatiti različite ulazne podatke. I u nekom trenutku možemo dodati novi parametar na ulaz, koji će na temelju rezultata analize povijesnih podataka povećati stopu konverzije korištenja usluge.
Posjedujemo obilje podataka o odnosima s klijentima, a količina tih informacija neprestano raste. Da bi bodovanje funkcioniralo, obrada podataka također zahtijeva pravila (ili matematičke modele) koja vam omogućuju da brzo odlučite kome odobriti aplikaciju, koga odbiti, a kome ponuditi još nekoliko proizvoda, procjenjujući njihov potencijalni interes.
Za zadatak koji je pred nama već koristimo specijalizirani sustav odlučivanja , koji na temelju pravila koje postavljaju analitičari, tehnolozi i programeri odlučuje hoće li klijentu odobriti ili odbiti određeni bankarski proizvod.
Na tržištu postoji mnogo gotovih rješenja, kako modela bodovanja tako i samih sustava odlučivanja. Jedan od ovih sustava koristimo u našoj tvrtki. Ali posao raste, diverzificira se, povećava se i broj klijenata i broj proizvoda u ponudi, a uz to se pojavljuju i ideje kako poboljšati postojeći proces donošenja odluka. Zasigurno ljudi koji rade s postojećim sustavom imaju mnogo ideja kako ga učiniti jednostavnijim, boljim, praktičnijim, ali ponekad su ideje izvana korisne. New Hackathon organiziran je s ciljem prikupljanja dobrih ideja.
Zadatak
Hackathon je održan 23. veljače. Sudionicima je ponuđena borbena zadaća: razviti sustav odlučivanja koji je morao zadovoljiti niz uvjeta.
Rečeno nam je kako funkcionira postojeći sustav i koje poteškoće nastaju tijekom njegovog rada, kao i kojim poslovnim ciljevima razvijena platforma treba težiti. Sustav mora imati brzo vrijeme izlaska na tržište za razvoj pravila kako bi radni kod analitičara ušao u proizvodnju što je prije moguće. A za dolazni tok zahtjeva, vrijeme donošenja odluka trebalo bi biti minimalno. Također, sustav koji se razvija mora imati mogućnosti unakrsne prodaje kako bi se klijentu dala prilika za kupnju drugih proizvoda tvrtke ako ih mi odobrimo i ako imaju potencijalni interes klijenta.
Jasno je da je nemoguće preko noći napisati gotov projekt koji će sigurno ići u produkciju, a dosta je teško pokriti cijeli sustav, pa smo zamoljeni da implementiramo barem dio. Postavljen je niz zahtjeva koje prototip mora zadovoljiti. Bilo je moguće pokušati kako pokriti sve zahtjeve u cijelosti, tako i detaljno raditi na pojedinim dijelovima platforme koja se razvija.
Što se tiče tehnologije, svi sudionici su imali potpunu slobodu izbora. Bilo je moguće koristiti sve koncepte i tehnologije: strujanje podataka, strojno učenje, izvor događaja, veliki podaci i druge.
Naše rješenje
Nakon malo razmišljanja, odlučili smo da bi FaaS rješenje bilo idealno za dovršenje zadatka.
Za ovo rješenje bilo je potrebno pronaći odgovarajući Serverless framework za implementaciju pravila sustava odlučivanja koji se razvija. Budući da Tinkoff aktivno koristi Kubernetes za upravljanje infrastrukturom, pogledali smo nekoliko gotovih rješenja koja se temelje na njemu, o čemu ću vam više reći kasnije.
Kako bismo pronašli najučinkovitije rješenje, proizvod koji se razvija promatrali smo očima njegovih korisnika. Glavni korisnici našeg sustava su analitičari uključeni u razvoj pravila. Pravila moraju biti implementirana na server, ili, kao u našem slučaju, implementirana u oblak, za naknadno donošenje odluka. Iz perspektive analitičara, tijek rada izgleda ovako:
- Analitičar piše skriptu, pravilo ili ML model na temelju podataka iz skladišta. U sklopu hackathona odlučili smo se za Mongodb, no izbor sustava za pohranu podataka ovdje nije bitan.
- Nakon testiranja razvijenih pravila na povijesnim podacima, analitičar učitava svoj kod na administrativnu ploču.
- Kako bi se osigurala verzija, sav kod će ići u Git repozitorije.
- Kroz administrativnu ploču bit će moguće implementirati kod u oblak kao zaseban funkcionalni modul bez poslužitelja.
Početni podaci od klijenata moraju proći kroz specijaliziranu uslugu obogaćivanja namijenjenu obogaćivanju početnog zahtjeva podacima iz skladišta. Bilo je važno implementirati ovu uslugu na način da radi s jednim repozitorijem (iz kojeg analitičar uzima podatke prilikom izrade pravila) kako bi se održala jedinstvena struktura podataka.
Još prije hackathona odlučili smo se za Serverless framework koji ćemo koristiti. Danas na tržištu postoji dosta tehnologija koje implementiraju ovaj pristup. Najpopularnija rješenja unutar Kubernetes arhitekture su Fission, Open FaaS i Kubeless. Postoje čak .
Nakon što smo odvagnuli sve prednosti i nedostatke, odabrali smo . Ovim okvirom bez poslužitelja prilično je lako upravljati i zadovoljava zahtjeve zadatka.
Da biste radili s Fissionom, morate razumjeti dva osnovna koncepta: funkciju i okruženje. Funkcija je dio koda napisan na jednom od jezika za koje postoji okruženje Fission. uključuje Python, JS, Go, JVM i mnoge druge popularne jezike i tehnologije.
Fission također može obavljati funkcije podijeljene u nekoliko datoteka, unaprijed zapakiranih u arhivu. Rad Fissiona u Kubernetes klasteru osiguravaju specijalizirani moduli kojima upravlja sam okvir. Za interakciju s podovima klastera, svakoj funkciji mora biti dodijeljena vlastita ruta kojoj možete proslijediti GET parametre ili tijelo zahtjeva u slučaju POST zahtjeva.
Kao rezultat toga, planirali smo dobiti rješenje koje bi omogućilo analitičarima da implementiraju razvijene skripte pravila bez sudjelovanja inženjera i programera. Opisani pristup također eliminira potrebu programera da prepisuju kod analitičara na drugi jezik. Na primjer, za trenutni sustav donošenja odluka koji koristimo, moramo pisati pravila na visoko specijaliziranim tehnologijama i jezicima, čiji je opseg iznimno ograničen, a postoji i snažna ovisnost o aplikacijskom poslužitelju, budući da svi nacrti bankovnih pravila raspoređeni su u jednom okruženju. Kao rezultat toga, za implementaciju novih pravila potrebno je osloboditi cijeli sustav.
U našem predloženom rješenju nema potrebe za objavljivanjem pravila; kod se može jednostavno implementirati jednim pritiskom na gumb. Također, upravljanje infrastrukturom u Kubernetesu omogućuje vam da ne razmišljate o učitavanju i skaliranju; takvi se problemi rješavaju odmah. A korištenje jedinstvenog skladišta podataka eliminira potrebu za usporedbom podataka u stvarnom vremenu s povijesnim podacima, što pojednostavljuje rad analitičara.
Što imamo
Budući da smo na hackathon došli s gotovim rješenjem (u našim fantazijama), sve što smo trebali učiniti je pretvoriti sve naše misli u linije koda.
Ključ uspjeha na svakom hackathonu je priprema i dobro napisan plan. Stoga smo prvo odlučili od kojih modula će se sastojati arhitektura našeg sustava i koje ćemo tehnologije koristiti.
Arhitektura našeg projekta bila je sljedeća:
Ovaj dijagram prikazuje dvije ulazne točke, analitičara (glavnog korisnika našeg sustava) i klijenta.
Proces rada je strukturiran ovako. Analitičar razvija funkciju pravila i funkciju obogaćivanja podataka za svoj model, pohranjuje svoj kod u Git repozitorij i postavlja svoj model u oblak putem administratorske aplikacije. Razmotrimo kako će se implementirana funkcija pozvati i donosimo odluke o dolaznim zahtjevima klijenata:
- Klijent ispunjava obrazac na web stranici i šalje svoj zahtjev kontroloru. Zahtjev o kojem je potrebno odlučiti dolazi na ulaz sustava i u izvornom se obliku evidentira u bazi podataka.
- Zatim se sirovi zahtjev šalje na obogaćivanje, ako je potrebno. Početni zahtjev možete dopuniti podacima iz vanjskih usluga i iz pohrane. Rezultirajući obogaćeni upit također se pohranjuje u bazu podataka.
- Pokreće se funkcija analitičara, koja uzima obogaćeni upit kao ulaz i proizvodi rješenje, koje se također upisuje u pohranu.
Odlučili smo koristiti MongoDB kao pohranu u našem sustavu zbog dokumentno orijentirane pohrane podataka u obliku JSON dokumenata, budući da su usluge obogaćivanja, uključujući izvorni zahtjev, agregirale sve podatke preko REST kontrolera.
Dakle, imali smo XNUMX sata za implementaciju platforme. Dosta smo uspješno raspodijelili uloge, svaki član tima je imao svoje područje odgovornosti u našem projektu:
- Front-end admin paneli za rad analitičara, preko kojih je mogao preuzimati pravila iz sustava kontrole verzija pisanih skripti, birati opcije za obogaćivanje ulaznih podataka i online uređivati skripte pravila.
- Backend admin, uključujući REST API za prednju stranu i integraciju s VCS-om.
- Postavljanje infrastrukture u Google Cloudu i razvoj usluge za obogaćivanje izvornih podataka.
- Modul za integraciju administrativne aplikacije s okvirom bez poslužitelja za naknadnu implementaciju pravila.
- Skripte pravila za testiranje performansi cijelog sustava i agregacija analitike o pristiglim prijavama (donesene odluke) za konačnu demonstraciju.
Krenimo redom.
Naše sučelje napisano je u Angularu 7 pomoću bankovnog korisničkog sučelja. Konačna verzija admin ploče izgledala je ovako:
Budući da je bilo malo vremena, pokušali smo implementirati samo ključne funkcionalnosti. Za implementaciju funkcije u Kubernetes klaster bilo je potrebno odabrati događaj (uslugu za koju je potrebno implementirati pravilo u oblaku) i kod funkcije koja implementira logiku odlučivanja. Za svaku implementaciju pravila za odabranu uslugu, napisali smo dnevnik ovog događaja. Na administrativnoj ploči možete vidjeti zapisnike svih događaja.
Sav funkcijski kod bio je pohranjen u udaljenom Git repozitoriju, koji je također morao biti postavljen u administratorskoj ploči. Za verziju koda, sve funkcije su pohranjene u različitim granama repozitorija. Administratorska ploča također pruža mogućnost prilagođavanja pisanih skripti, tako da prije postavljanja funkcije u produkciju možete ne samo provjeriti pisani kod, već i izvršiti potrebne izmjene.
Osim funkcija pravila, također smo implementirali mogućnost postupnog obogaćivanja izvornih podataka korištenjem Enrichment funkcija, čiji su kod također bile skripte u kojima je bilo moguće ići u skladište podataka, pozivati servise trećih strana i vršiti preliminarne izračune . Kako bismo demonstrirali naše rješenje, izračunali smo horoskopski znak klijenta koji je ostavio zahtjev i odredili njegovog mobilnog operatera koristeći REST uslugu treće strane.
Pozadina platforme napisana je u Javi i implementirana kao Spring Boot aplikacija. U početku smo planirali koristiti Postgres za pohranjivanje administratorskih podataka, ali smo se, u sklopu hackathona, odlučili ograničiti na jednostavan H2 kako bismo uštedjeli vrijeme. Na pozadini je implementirana integracija s Bitbucketom za verziju funkcija obogaćivanja upita i skripti pravila. Za integraciju s udaljenim Git spremištima koristili smo , koji je vrsta omota preko CLI naredbi, omogućujući vam da izvršite bilo koje git instrukcije koristeći prikladno softversko sučelje. Tako smo imali dva odvojena spremišta za funkcije obogaćivanja i pravila, a sve su skripte bile podijeljene u direktorije. Preko korisničkog sučelja bilo je moguće odabrati najnovije izdavanje skripte proizvoljne grane spremišta. Prilikom mijenjanja koda putem administrativne ploče, commitovi promijenjenog koda kreirani su u udaljenim spremištima.
Za realizaciju naše ideje bila nam je potrebna odgovarajuća infrastruktura. Odlučili smo postaviti naš Kubernetes klaster u oblak. Naš izbor je bila Google Cloud Platform. Okvir Fission bez poslužitelja instaliran je na Kubernetes klaster, koji smo postavili u Gcloud. U početku je usluga obogaćivanja izvornih podataka bila implementirana kao zasebna Java aplikacija umotana u Pod unutar k8s klastera. Ali nakon preliminarne demonstracije našeg projekta usred hackathona, preporučeno nam je da uslugu obogaćivanja učinimo fleksibilnijom kako bismo pružili mogućnost odabira načina obogaćivanja neobrađenih podataka dolaznih aplikacija. I nismo imali drugog izbora nego uslugu obogaćivanja također učiniti bez poslužitelja.
Za rad s Fissionom koristili smo Fission CLI, koji se mora instalirati povrh Kubernetes CLI-ja. Implementacija funkcija u k8s klaster prilično je jednostavna; samo trebate dodijeliti internu rutu i ulaz funkciji kako biste omogućili dolazni promet ako je potreban pristup izvan klastera. Uvođenje jedne funkcije obično ne traje više od 10 sekundi.
Završna prezentacija projekta i podvođenje sažetaka
Kako bismo demonstrirali kako funkcionira naš sustav, postavili smo jednostavan obrazac na udaljeni poslužitelj gdje možete podnijeti zahtjev za jedan od proizvoda banke. Da biste zatražili, morali ste unijeti svoje inicijale, datum rođenja i broj telefona.
Podaci iz obrasca klijenta išli su kontroloru koji je istovremeno slao zahtjeve za sva dostupna pravila, prethodno obogativši podatke prema zadanim uvjetima, te ih spremivši u zajedničku pohranu. Ukupno smo implementirali tri funkcije koje donose odluke o dolaznim aplikacijama i 4 usluge obogaćivanja podataka. Nakon predaje zahtjeva, klijent je dobio našu odluku:
Osim odbijanja ili odobrenja, klijent je dobio i popis drugih proizvoda za koje smo paralelno slali zahtjeve. Tako smo pokazali mogućnost unakrsne prodaje na našoj platformi.
Bila su dostupna ukupno 3 fiktivna bankovna proizvoda:
- Kreditna.
- igračka
- Hipoteka.
Tijekom demonstracije postavili smo pripremljene funkcije i skripte za obogaćivanje za svaku uslugu.
Svako pravilo je zahtijevalo vlastiti skup ulaznih podataka. Dakle, da bismo odobrili hipoteku, izračunali smo horoskopski znak klijenta i povezali ga s logikom lunarnog kalendara. Za odobrenje igračke provjerili smo punoljetnost klijenta, a za izdavanje kredita poslali smo zahtjev vanjskom otvorenom servisu za određivanje mobilnog operatera i o tome je donesena odluka.
Potrudili smo se da naša demonstracija bude zanimljiva i interaktivna, svi prisutni su mogli otići na naš obrazac i provjeriti dostupnost naših izmišljenih usluga za njih. I na samom kraju prezentacije prikazali smo analitiku pristiglih prijava iz koje je vidljivo koliko je ljudi koristilo našu uslugu, broj odobrenja i odbijenica.
Kako bismo prikupljali analitiku online, dodatno smo implementirali BI alat otvorenog koda i pričvrstili ga za našu jedinicu za pohranu. Metabase vam omogućuje izradu ekrana s analitikom na podacima koji nas zanimaju, samo trebate registrirati vezu s bazom podataka, odabrati tablice (u našem slučaju zbirke podataka, budući da smo koristili MongoDB) i specificirati polja koja nas zanimaju .
Kao rezultat toga, dobili smo dobar prototip platforme za donošenje odluka, a tijekom demonstracije svaki je slušatelj mogao osobno provjeriti njezinu izvedbu. Zanimljivo rješenje, gotov prototip i uspješna demonstracija omogućili su nam pobjedu, unatoč jakoj konkurenciji drugih timova. Siguran sam da se i o projektu svakog tima može napisati zanimljiv članak.
Izvor: www.habr.com