Počevši od prošle godine, naša kompanija je počela sa organizacijom hakatona. Prvo ovakvo takmičenje je bilo veoma uspešno, o tome smo pisali u . Drugi hakaton je održan u februaru 2019. godine i nije bio ništa manje uspešan. O ciljevima održavanja potonjeg ne tako davno organizator.
Učesnici su dobili prilično zanimljiv zadatak sa potpunom slobodom u odabiru tehnološkog paketa za njegovu implementaciju. Bilo je potrebno implementirati platformu za donošenje odluka za praktičnu implementaciju funkcija ocjenjivanja kupaca koje bi mogle raditi s brzim protokom aplikacija, izdržati velika opterećenja, a sam sistem je bio lako skalabilan.
Zadatak je netrivijalan i može se riješiti na više načina, u što smo se uvjerili tokom demonstracije završnih prezentacija projekata učesnika. Na hakatonu je bilo 6 timova po 5 ljudi, svi učesnici su imali dobre projekte, ali se naša platforma pokazala kao najkonkurentnija. Imamo veoma interesantan projekat, o kojem bih želeo da pričam u ovom članku.
Naše rješenje je platforma zasnovana na arhitekturi bez servera unutar Kubernetesa, što smanjuje vrijeme potrebno za uvođenje novih funkcija u proizvodnju. Omogućava analitičarima da napišu kod u okruženju koje im odgovara i da ga implementira u proizvodnju bez učešća inženjera i programera.
Šta je bodovanje
Tinkoff.ru, kao i mnoge moderne kompanije, ima bodovanje kupaca. Bodovanje je sistem procjene kupaca zasnovan na statističkim metodama analize podataka.
Na primjer, klijent nam se obraća sa zahtjevom da mu izdamo kredit ili otvorimo kod nas individualni račun. Ako planiramo da mu izdamo kredit, onda moramo procijeniti njegovu solventnost, a ako je račun individualni poduzetnik, onda moramo biti sigurni da klijent neće obavljati lažne transakcije.
Osnova za donošenje ovakvih odluka su matematički modeli koji analiziraju kako podatke iz same aplikacije, tako i podatke iz našeg skladišta. Osim bodovanja, slične statističke metode se mogu koristiti i u službi generiranja pojedinačnih 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 osnovu rezultata analize istorijskih podataka, povećati stopu konverzije korišćenja usluge.
Posjedujemo mnoštvo podataka o odnosima s kupcima, a obim ovih informacija stalno raste. Da bi bodovanje funkcioniralo, obrada podataka također zahtijeva pravila (ili matematičke modele) koja vam omogućavaju da brzo odlučite kome ćete odobriti aplikaciju, kome odbiti, a kome ponuditi još nekoliko proizvoda, procjenjujući njihov potencijalni interes.
Za ovaj zadatak već koristimo specijalizovani sistem donošenja odluka , koja na osnovu pravila koja postavljaju analitičari, tehnolozi i programeri odlučuje da li će klijentu odobriti ili odbiti određeni bankarski proizvod.
Na tržištu postoje mnoga gotova rješenja, kako modeli bodovanja tako i sami sistemi donošenja odluka. U našoj kompaniji koristimo jedan od ovih sistema. Ali posao raste, diverzificira se, povećava se i broj klijenata i broj ponuđenih proizvoda, a uz to se pojavljuju i ideje kako unaprijediti postojeći proces donošenja odluka. Sigurno ljudi koji rade sa postojećim sistemom imaju mnogo ideja kako da ga učine jednostavnijim, boljim, praktičnijim, ali ponekad su ideje izvana korisne. Novi Hakaton je organizovan sa ciljem prikupljanja zdravih ideja.
Zadatak
Hakaton je održan 23. februara. Učesnicima je ponuđen borbeni zadatak: da razviju sistem odlučivanja koji mora da ispuni niz uslova.
Rečeno nam je kako postojeći sistem funkcioniše i koje poteškoće se javljaju tokom njegovog rada, kao i kojim poslovnim ciljevima razvijena platforma treba da teži. Sistem mora imati brzo vrijeme za izlazak 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 aplikacija, vrijeme donošenja odluka treba težiti na minimumu. Takođe, sistem koji se razvija mora imati mogućnosti unakrsne prodaje kako bi klijentu dao priliku da kupi druge proizvode kompanije ako ih mi odobrimo i imaju potencijalni interes od strane klijenta.
Jasno je da je nemoguće preko noći napisati gotov projekat koji će sigurno krenuti u proizvodnju, a prilično je teško pokriti cijeli sistem, pa smo zamoljeni da implementiramo barem dio. Utvrđen je niz zahtjeva koje prototip mora zadovoljiti. Bilo je moguće pokušati i pokriti sve zahtjeve u cijelosti, i detaljno raditi na pojedinačnim dijelovima platforme koja se razvija.
Što se tiče tehnologije, svim učesnicima je data potpuna sloboda izbora. Bilo je moguće koristiti bilo koji koncept i tehnologije: prijenos podataka, strojno učenje, izvor događaja, veliki podaci i drugo.
Naše rešenje
Nakon malo razmišljanja, odlučili smo da bi FaaS rješenje bilo idealno za završetak zadatka.
Za ovo rješenje bilo je potrebno pronaći odgovarajući okvir bez servera za implementaciju pravila sistema odlučivanja koji se razvija. Budući da Tinkoff aktivno koristi Kubernetes za upravljanje infrastrukturom, pogledali smo nekoliko gotovih rješenja zasnovanih na njemu, o čemu ću vam više reći kasnije.
Kako bismo pronašli najefikasnije rješenje, pogledali smo proizvod koji se razvija očima njegovih korisnika. Glavni korisnici našeg sistema su analitičari uključeni u izradu pravila. Pravila moraju biti raspoređena na server, ili, kao u našem slučaju, raspoređena u oblaku, za naknadno donošenje odluka. Iz perspektive analitičara, tok posla izgleda ovako:
- Analitičar piše skriptu, pravilo ili ML model na osnovu podataka iz skladišta. U okviru hakatona odlučili smo da koristimo Mongodb, ali izbor sistema za skladištenje podataka ovde nije bitan.
- Nakon testiranja razvijenih pravila na istorijskim podacima, analitičar postavlja svoj kod na admin panel.
- Da bi se osiguralo upravljanje verzijama, sav kod će ići u Git spremišta.
- Preko admin panela biće moguće implementirati kod u oblak kao poseban funkcionalni modul bez servera.
Početni podaci od klijenata moraju proći kroz specijalizovanu uslugu obogaćivanja koja je osmišljena da obogati početni zahtev podacima iz skladišta. Bilo je važno implementirati ovu uslugu na način da radi sa jednim spremištem (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. Čak postoje .
Nakon što smo odvagali sve prednosti i nedostatke, odabrali smo . Ovaj okvir bez servera je prilično jednostavan za upravljanje i ispunjava 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 koji postoji Fission okruženje. uključuje Python, JS, Go, JVM i mnoge druge popularne jezike i tehnologije.
Fission je također sposoban za obavljanje funkcija podijeljenih u nekoliko datoteka, prethodno upakovanih u arhivu. Rad Fisije u Kubernetes klasteru osiguravaju specijalizovani podovi, kojima upravlja sam okvir. Za interakciju sa modulima 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 da dobijemo rešenje koje bi omogućilo analitičarima da implementiraju razvijene skripte pravila bez učešća inženjera i programera. Opisani pristup takođe eliminiše potrebu da programeri prepisuju kod analitičara na drugi jezik. Na primjer, za trenutni sistem odlučivanja koji koristimo, moramo pisati pravila na visokospecijaliziranim tehnologijama i jezicima, čiji je obim izuzetno ograničen, a postoji i jaka ovisnost o aplikacijskom serveru, 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 sistem.
U našem predloženom rješenju, nema potrebe za otpuštanjem pravila; kod se može lako implementirati pritiskom na dugme. Takođe, upravljanje infrastrukturom u Kubernetesu vam omogućava da ne razmišljate o učitavanju i skaliranju; takvi problemi se rešavaju iz kutije. A upotreba jednog skladišta podataka eliminiše potrebu za poređenjem podataka u realnom vremenu sa istorijskim podacima, što pojednostavljuje rad analitičara.
Šta imamo
Pošto smo na hakaton došli sa gotovim rešenjem (u našim fantazijama), sve što smo trebali da uradimo je da sve naše misli pretvorimo u redove koda.
Ključ uspjeha na svakom hackathonu je priprema i dobro napisan plan. Stoga je prvo što smo uradili bilo da odlučimo od kojih modula će se sastojati arhitektura našeg sistema i koje tehnologije ćemo koristiti.
Arhitektura našeg projekta bila je sljedeća:
Ovaj dijagram prikazuje dvije ulazne tačke, analitičara (glavnog korisnika našeg sistema) i klijenta.
Proces rada je ovako strukturiran. 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 preko administratorske aplikacije. Razmotrimo kako će se raspoređena funkcija pozvati i donijeti odluke o dolaznim zahtjevima klijenata:
- Klijent ispunjava obrazac na web stranici i šalje svoj zahtjev kontroloru. Aplikacija o kojoj treba donijeti odluku dolazi na sistemski ulaz i evidentira se u bazi podataka u izvornom obliku.
- Zatim se sirovi zahtjev šalje na obogaćivanje, ako je potrebno. Početni zahtjev možete dopuniti podacima iz vanjskih servisa i iz skladišta. Rezultirajući obogaćeni upit se također pohranjuje u bazi podataka.
- Pokreće se funkcija analitičara, koja uzima obogaćeni upit kao ulaz i proizvodi rješenje koje se također upisuje u skladište.
Odlučili smo da koristimo MongoDB kao skladište u našem sistemu zbog dokumentno orijentisanog skladištenja podataka u obliku JSON dokumenata, pošto su usluge obogaćivanja, uključujući i originalni zahtev, agregirale sve podatke preko REST kontrolera.
Dakle, imali smo XNUMX sata da implementiramo platformu. Uloge smo prilično uspješno rasporedili, 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 sistema kontrole verzija pisanih skripti, birati opcije za obogaćivanje ulaznih podataka i uređivati skripte pravila online.
- Backend administrator, uključujući REST API za front i integraciju sa VCS.
- Postavljanje infrastrukture u Google Cloud i razvoj servisa za obogaćivanje izvornih podataka.
- Modul za integraciju admin aplikacije sa serverskim okvirom za naknadnu implementaciju pravila.
- Skripte pravila za testiranje performansi čitavog sistema i agregaciju analitike na dolaznim aplikacijama (donijetim odlukama) za završnu demonstraciju.
Krenimo redom.
Naš frontend je napisan u Angular 7 koristeći bankarski UI Kit. Konačna verzija admin panela je izgledala ovako:
Pošto je bilo malo vremena, pokušali smo da implementiramo samo ključnu funkcionalnost. Da biste postavili funkciju u Kubernetes klaster, bilo je potrebno odabrati događaj (usluga za koju se pravilo mora postaviti u oblak) i kod funkcije koja implementira logiku donošenja odluka. Za svaku implementaciju pravila za odabranu uslugu napisali smo dnevnik ovog događaja. U admin panelu možete vidjeti dnevnike svih događaja.
Sav kod funkcije je pohranjen u udaljeno Git spremište, koje je također moralo biti postavljeno na admin panelu. Za verziju koda, sve funkcije su pohranjene u različitim granama spremišta. Administrativni panel također pruža mogućnost prilagođavanja pisanih skripti, tako da prije implementacije funkcije u produkciju možete ne samo provjeriti pisani kod, već i napraviti potrebne izmjene.
Osim funkcija pravila, implementirali smo i mogućnost postepenog obogaćivanja izvornih podataka pomoću funkcija obogaćivanja, čiji su kod bili i skripte u kojima je bilo moguće otići u skladište podataka, pozvati servise trećih strana i izvršiti preliminarne proračune. . Da bismo demonstrirali naše rješenje, izračunali smo horoskopski znak klijenta koji je napustio zahtjev i odredili njegovog mobilnog operatera koristeći REST servis treće strane.
Pozadina platforme je napisana u Javi i implementirana kao Spring Boot aplikacija. Prvobitno smo planirali koristiti Postgres za pohranjivanje administratorskih podataka, ali, kao dio hakatona, odlučili smo se ograničiti na jednostavan H2 kako bismo uštedjeli vrijeme. Na backend-u je implementirana integracija sa Bitbucket-om za verziju funkcija obogaćivanja upita i skripti pravila. Za integraciju sa udaljenim Git repozitorijumima, koristili smo , koji je neka vrsta omotača CLI komandi, omogućavajući vam da izvršite bilo koje git instrukcije koristeći pogodan softverski interfejs. Tako smo imali dva odvojena spremišta za funkcije i pravila obogaćivanja, a sve skripte su bile podijeljene u direktorije. Preko korisničkog sučelja bilo je moguće odabrati najnovije urezivanje skripte proizvoljne grane spremišta. Prilikom izmjena koda preko admin panela, kreirana su urezivanja promijenjenog koda u udaljenim spremištima.
Za realizaciju naše ideje bila nam je potrebna odgovarajuća infrastruktura. Odlučili smo da naš Kubernetes klaster postavimo u oblak. Naš izbor je bila Google Cloud Platforma. Fission serverless framework instaliran je na Kubernetes klasteru, koji smo postavili u Gcloud. U početku, usluga obogaćivanja izvornih podataka bila je implementirana kao zasebna Java aplikacija umotana u Pod unutar k8s klastera. Ali nakon preliminarne demonstracije našeg projekta usred hakatona, preporučeno nam je da uslugu Enrichment učinimo fleksibilnijom kako bismo pružili mogućnost izbora kako obogatiti sirove podatke dolaznih aplikacija. I nismo imali izbora nego da uslugu obogaćivanja učinimo i bez servera.
Za rad sa Fissionom, koristili smo Fission CLI, koji se mora instalirati na Kubernetes CLI. Postavljanje funkcija u k8s klaster je prilično jednostavno; samo trebate dodijeliti internu rutu i ulaz funkciji kako biste omogućili dolazni promet ako je potreban pristup izvan klastera. Implementacija jedne funkcije obično ne traje više od 10 sekundi.
Završna prezentacija projekta i sumiranje
Kako bismo demonstrirali kako naš sistem funkcionira, postavili smo jednostavan obrazac na udaljeni server 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 klijentskog obrasca išli su do kontrolora, koji je istovremeno slao zahtjeve za sva dostupna pravila, prethodno obogativši podatke prema navedenim uslovima i pohranivši ih u zajedničko skladište. Ukupno smo implementirali tri funkcije koje donose odluke o dolaznim aplikacijama i 4 usluge obogaćivanja podataka. Nakon podnošenja prijave, klijent je dobio našu odluku:
Pored odbijanja ili odobrenja, klijent je dobio i listu drugih proizvoda, za koje smo zahtjeve slali paralelno. Tako smo demonstrirali mogućnost unakrsne prodaje na našoj platformi.
Na raspolaganju su bila ukupno 3 fiktivna bankarska proizvoda:
- Kredit.
- Igračka
- Hipoteka.
Tokom demonstracije, implementirali 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 to sa logikom lunarnog kalendara. Da bismo odobrili igračku, provjerili smo da li je klijent punoljetan, 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 do naše forme i provjeriti dostupnost naših izmišljenih usluga za njih. I na samom kraju prezentacije demonstrirali smo analitiku pristiglih prijava koja je pokazala koliko je ljudi koristilo našu uslugu, broj odobrenja i odbijenica.
Da bismo prikupljali analitiku na mreži, dodatno smo implementirali BI alat otvorenog koda i pričvrstio ga na našu skladišnu jedinicu. Metabase vam omogućava da napravite ekrane sa analitikom na podacima koji nas zanimaju; potrebno je samo registrovati vezu sa bazom podataka, odabrati tabele (u našem slučaju zbirke podataka, pošto smo koristili MongoDB) i navesti polja koja nas zanimaju .
Kao rezultat, dobili smo dobar prototip platforme za donošenje odluka, a tokom demonstracije svaki slušalac je mogao lično da proveri njen učinak. Zanimljivo rješenje, gotov prototip i uspješna demonstracija omogućili su nam pobjedu, uprkos jakoj konkurenciji drugih timova. Siguran sam da se o projektu svakog tima može napisati i zanimljiv članak.
izvor: www.habr.com