Od minulého roka začala naša spoločnosť organizovať hackatóny. Prvá takáto súťaž bola veľmi úspešná, písali sme o nej v r . Druhý hackathon sa uskutočnil vo februári 2019 a bol nemenej úspešný. O cieľoch držať to posledné nie je to tak dávno organizátor.
Účastníci dostali pomerne zaujímavú úlohu s úplnou voľnosťou pri výbere technologického zásobníka na jej implementáciu. Bolo potrebné implementovať rozhodovaciu platformu pre pohodlné nasadenie zákazníckych skóringových funkcií, ktorá by dokázala pracovať s rýchlym tokom aplikácií, odolala veľkej záťaži a samotný systém bol jednoducho škálovateľný.
Úloha je netriviálna a dá sa vyriešiť mnohými spôsobmi, ako sme sa presvedčili pri ukážke záverečných prezentácií projektov účastníkov. Na hackathone bolo 6 tímov po 5 ľudí, všetci účastníci mali dobré projekty, ale naša platforma sa ukázala ako najkonkurencieschopnejšia. Máme veľmi zaujímavý projekt, o ktorom by som chcel hovoriť v tomto článku.
Naše riešenie je platforma založená na architektúre bez servera v rámci Kubernetes, čo skracuje čas potrebný na uvedenie nových funkcií do produkcie. Umožňuje analytikom písať kód v prostredí, ktoré im vyhovuje a nasadiť ho do produkcie bez účasti inžinierov a vývojárov.
Čo je bodovanie
Tinkoff.ru, rovnako ako mnoho moderných spoločností, má hodnotenie zákazníkov. Scoring je systém hodnotenia zákazníkov založený na štatistických metódach analýzy dát.
Klient sa na nás napríklad obráti so žiadosťou, aby sme mu poskytli úver alebo si u nás otvorili individuálny podnikateľský účet. Ak mu plánujeme poskytnúť pôžičku, musíme posúdiť jeho platobnú schopnosť, a ak je účtom individuálny podnikateľ, musíme si byť istí, že klient nebude vykonávať podvodné transakcie.
Základom pre takéto rozhodnutia sú matematické modely, ktoré analyzujú tak dáta zo samotnej aplikácie, ako aj dáta z nášho úložiska. Okrem bodovania je možné podobné štatistické metódy využiť aj v službe generovania individuálnych odporúčaní na nové produkty pre našich klientov.
Spôsob takéhoto hodnotenia môže akceptovať rôzne vstupné údaje. A v určitom okamihu môžeme na vstup pridať nový parameter, ktorý na základe výsledkov analýzy historických údajov zvýši mieru konverzie používania služby.
Disponujeme množstvom údajov o vzťahoch so zákazníkmi a objem týchto informácií neustále rastie. Na to, aby bodovanie fungovalo, si spracovanie údajov vyžaduje aj pravidlá (alebo matematické modely), ktoré vám umožnia rýchlo sa rozhodnúť, komu žiadosť schválite, koho odmietnete a komu ponúknete niekoľko ďalších produktov, pričom zhodnotíte ich potenciálny záujem.
Pre danú úlohu už používame špecializovaný systém rozhodovania , ktorá na základe pravidiel stanovených analytikmi, technológmi a vývojármi rozhoduje o schválení alebo odmietnutí konkrétneho bankového produktu klientovi.
Na trhu je množstvo hotových riešení, či už skórovacích modelov, ako aj samotných rozhodovacích systémov. Jeden z týchto systémov používame aj v našej spoločnosti. Ale biznis rastie, diverzifikuje sa, zvyšuje sa počet klientov aj ponúkaných produktov a spolu s tým vznikajú nápady, ako zlepšiť existujúci rozhodovací proces. Ľudia pracujúci s existujúcim systémom majú určite veľa nápadov, ako to urobiť jednoduchšie, lepšie, pohodlnejšie, ale niekedy sú užitočné nápady zvonku. Nový Hackathon bol organizovaný s cieľom zbierať dobré nápady.
Úloha
Hackaton sa konal 23. februára. Účastníkom bola ponúknutá bojová úloha: vyvinúť systém rozhodovania, ktorý musel spĺňať množstvo podmienok.
Bolo nám povedané, ako funguje existujúci systém a aké ťažkosti vznikajú pri jeho prevádzke, ako aj aké obchodné ciele by mala vyvíjaná platforma sledovať. Systém musí mať rýchly čas uvedenia na trh pre vývoj pravidiel, aby sa pracovný kódex analytikov dostal do výroby čo najrýchlejšie. A pre prichádzajúci tok žiadostí by mal byť čas na rozhodovanie minimálny. Vyvíjaný systém musí tiež disponovať možnosťami krížového predaja, aby mal klient možnosť zakúpiť si ďalšie produkty spoločnosti, ak sú nami schválené a majú potenciálny záujem zo strany klienta.
Je jasné, že nie je možné cez noc napísať hotový projekt, ktorý sa určite dostane do výroby, a pokryť celý systém je dosť náročné, preto sme boli požiadaní o implementáciu aspoň jeho časti. Bolo stanovených niekoľko požiadaviek, ktoré musí prototyp spĺňať. Bolo možné pokúsiť sa jednak pokryť všetky požiadavky v ich celistvosti, jednak detailne pracovať na jednotlivých sekciách vyvíjanej platformy.
Čo sa týka technológie, všetci účastníci mali úplnú slobodu výberu. Bolo možné použiť akékoľvek koncepty a technológie: Streamovanie dát, strojové učenie, event sourcing, veľké dáta a iné.
Naše riešenie
Po malom brainstormingu sme sa rozhodli, že riešenie FaaS by bolo ideálne na dokončenie úlohy.
Pre toto riešenie bolo potrebné nájsť vhodný Serverless framework na implementáciu pravidiel vyvíjaného rozhodovacieho systému. Keďže Tinkoff aktívne využíva Kubernetes na správu infraštruktúry, pozreli sme sa na niekoľko hotových riešení založených na ňom, viac vám o tom poviem neskôr.
Aby sme našli najefektívnejšie riešenie, pozreli sme sa na vyvíjaný produkt očami jeho užívateľov. Hlavnými používateľmi nášho systému sú analytici zapojení do vývoja pravidiel. Pre následné rozhodovanie musia byť pravidlá nasadené na server, alebo ako v našom prípade nasadené v cloude. Z pohľadu analytika vyzerá pracovný postup takto:
- Analytik napíše skript, pravidlo alebo model ML na základe údajov zo skladu. V rámci hackathonu sme sa rozhodli použiť Mongodb, no výber systému ukladania dát tu nie je dôležitý.
- Po otestovaní vyvinutých pravidiel na historických údajoch analytik nahrá svoj kód na panel správcu.
- Aby sa zabezpečilo vytváranie verzií, všetok kód pôjde do repozitárov Git.
- Cez admin panel bude možné nasadiť kód v cloude ako samostatný funkčný Serverless modul.
Prvotné dáta od klientov musia prejsť cez špecializovanú službu Enrichment, ktorá je určená na obohatenie prvotnej požiadavky o dáta zo skladu. Dôležité bolo implementovať túto službu tak, aby fungovala s jedným úložiskom (z ktorého analytik berie dáta pri vývoji pravidiel) a udržiavala jednotnú dátovú štruktúru.
Ešte pred hackathonom sme sa rozhodli pre Serverless framework, ktorý budeme používať. Dnes je na trhu pomerne veľa technológií, ktoré tento prístup implementujú. Najpopulárnejšie riešenia v rámci architektúry Kubernetes sú Fission, Open FaaS a Kubeless. Existujú dokonca .
Po zvážení všetkých pre a proti sme sa vybrali . Tento bezserverový rámec je pomerne jednoduchý na správu a spĺňa požiadavky danej úlohy.
Ak chcete pracovať s Fission, musíte pochopiť dva základné pojmy: funkciu a prostredie. Funkcia je časť kódu napísaná v jednom z jazykov, pre ktoré existuje prostredie Fission. zahŕňa Python, JS, Go, JVM a mnoho ďalších populárnych jazykov a technológií.
Fission je tiež schopný vykonávať funkcie rozdelené do niekoľkých súborov, vopred zabalených do archívu. Prevádzku Fission v klastri Kubernetes zabezpečujú špecializované pody, ktoré spravuje samotný framework. Na interakciu s klastrovými modulmi musí byť každej funkcii priradená vlastná trasa, ktorej môžete odovzdať parametre GET alebo telo požiadavky v prípade požiadavky POST.
V dôsledku toho sme plánovali získať riešenie, ktoré by umožnilo analytikom nasadiť vyvinuté skripty pravidiel bez účasti inžinierov a vývojárov. Opísaný prístup tiež eliminuje potrebu vývojárov prepisovať kód analytika do iného jazyka. Napríklad pre súčasný rozhodovací systém, ktorý používame, musíme písať pravidlá vo vysoko špecializovaných technológiách a jazykoch, ktorých rozsah je extrémne obmedzený a je tu tiež veľká závislosť od aplikačného servera, keďže všetky návrhy bankových pravidiel sú nasadené v jedinom prostredí. V dôsledku toho je pre nasadenie nových pravidiel potrebné uvoľniť celý systém.
V našom navrhovanom riešení nie je potrebné uvoľňovať pravidlá, kód je možné jednoducho nasadiť kliknutím na tlačidlo. Správa infraštruktúry v Kubernetes vám tiež umožňuje nemyslieť na zaťaženie a škálovanie; takéto problémy sú vyriešené hneď po vybalení. A použitie jedného dátového skladu eliminuje potrebu porovnávať dáta v reálnom čase s historickými dátami, čo zjednodušuje prácu analytika.
Čo sme dostali
Keďže sme na hackathon prišli s hotovým riešením (v našich predstavách), stačilo nám všetky myšlienky previesť do riadkov kódu.
Kľúčom k úspechu na každom hackathone je príprava a dobre napísaný plán. Preto sme sa najprv rozhodli, z akých modulov bude pozostávať naša systémová architektúra a aké technológie použijeme.
Architektúra nášho projektu bola nasledovná:
Tento diagram zobrazuje dva vstupné body, analytika (hlavného používateľa nášho systému) a klienta.
Pracovný proces je štruktúrovaný takto. Analytik pre svoj model vyvinie funkciu pravidiel a funkciu obohatenia údajov, uloží svoj kód do úložiska Git a nasadí svoj model do cloudu prostredníctvom aplikácie správcu. Uvažujme, ako sa bude nasadená funkcia volať, a rozhodnime sa o prichádzajúcich požiadavkách od klientov:
- Klient vyplní formulár na webovej stránke a odošle svoju požiadavku prevádzkovateľovi. Aplikácia, o ktorej je potrebné rozhodnúť, prichádza na vstup systému a je zaznamenaná v databáze v pôvodnej podobe.
- Ďalej sa v prípade potreby odošle surová žiadosť na obohatenie. Prvotnú požiadavku môžete doplniť dátami z externých služieb aj z úložiska. Výsledný obohatený dotaz je tiež uložený v databáze.
- Spustí sa funkcia analytika, ktorá berie ako vstup obohatený dotaz a vytvára riešenie, ktoré sa tiež zapíše do úložiska.
MongoDB sme sa rozhodli použiť ako úložisko v našom systéme z dôvodu dokumentovo orientovaného ukladania údajov vo forme dokumentov JSON, keďže služby obohatenia, vrátane pôvodnej požiadavky, agregovali všetky údaje cez REST radiče.
Na implementáciu platformy sme teda mali XNUMX hodín. Úlohy sme rozdelili celkom úspešne, každý člen tímu mal v našom projekte svoju vlastnú oblasť zodpovednosti:
- Front-endové administrátorské panely pre prácu analytika, prostredníctvom ktorých si mohol stiahnuť pravidlá zo systému správy verzií písaných skriptov, vybrať možnosti na obohatenie vstupných údajov a upraviť skripty pravidiel online.
- Backend admin, vrátane REST API pre front a integráciu s VCS.
- Nastavenie infraštruktúry v Google Cloud a vývoj služby na obohatenie zdrojových údajov.
- Modul pre integráciu admin aplikácie s rámcom Serverless pre následné nasadenie pravidiel.
- Skripty pravidiel pre testovanie výkonu celého systému a agregáciu analytiky na prichádzajúcich aplikáciách (prijaté rozhodnutia) pre finálnu ukážku.
Začnime v poriadku.
Náš frontend bol napísaný v Angular 7 pomocou súpravy bankového používateľského rozhrania. Finálna verzia administračného panela vyzerala takto:
Keďže času bolo málo, snažili sme sa implementovať len kľúčovú funkcionalitu. Pre nasadenie funkcie v klastri Kubernetes bolo potrebné vybrať udalosť (službu, pre ktorú je potrebné nasadiť pravidlo v cloude) a kód funkcie, ktorá implementuje logiku rozhodovania. Pre každé nasadenie pravidla pre vybranú službu sme spísali protokol tejto udalosti. V administračnom paneli ste mohli vidieť protokoly všetkých udalostí.
Všetok funkčný kód bol uložený vo vzdialenom úložisku Git, ktoré bolo tiež potrebné nastaviť na paneli správcu. Pre verziu kódu boli všetky funkcie uložené v rôznych vetvách úložiska. Administračný panel tiež poskytuje možnosť úprav napísaných skriptov, takže pred nasadením funkcie do produkcie môžete nielen skontrolovať napísaný kód, ale aj vykonať potrebné zmeny.
Okrem funkcií pravidiel sme implementovali aj možnosť postupného obohacovania zdrojových dát pomocou funkcií Enrichment, ktorých kódom boli aj skripty, v ktorých bolo možné prejsť do dátového skladu, volať služby tretích strán a vykonávať predbežné výpočty . Na ukážku nášho riešenia sme vypočítali znamenie zverokruhu klienta, ktorý zanechal požiadavku, a určili sme mu mobilného operátora pomocou služby REST tretej strany.
Backend platformy bol napísaný v jazyku Java a implementovaný ako aplikácia Spring Boot. Pôvodne sme plánovali použiť Postgres na ukladanie správcovských údajov, ale v rámci hackathonu sme sa rozhodli obmedziť sa na jednoduchý H2, aby sme ušetrili čas. Na backende bola implementovaná integrácia s Bitbucket na verziu funkcií obohatenia dotazov a skriptov pravidiel. Na integráciu so vzdialenými úložiskami Git sme použili , čo je druh obalu nad príkazmi CLI, ktorý vám umožňuje vykonávať akékoľvek inštrukcie git pomocou pohodlného softvérového rozhrania. Mali sme teda dve samostatné úložiská pre funkcie a pravidlá obohatenia a všetky skripty boli rozdelené do adresárov. Prostredníctvom používateľského rozhrania bolo možné vybrať najnovšie odovzdanie skriptu ľubovoľnej vetvy úložiska. Pri vykonávaní zmien v kóde cez administračný panel sa vo vzdialených úložiskách vytvorili odovzdania zmeneného kódu.
Na realizáciu našej myšlienky sme potrebovali vhodnú infraštruktúru. Rozhodli sme sa nasadiť náš klaster Kubernetes v cloude. Našou voľbou bola platforma Google Cloud Platform. Bezserverový rámec Fission bol nainštalovaný na klastri Kubernetes, ktorý sme nasadili v Gcloud. Pôvodne bola služba obohatenia zdrojových údajov implementovaná ako samostatná Java aplikácia zabalená do podu vnútri klastra k8s. Ale po predbežnej demonštrácii nášho projektu uprostred hackathonu nám bolo odporučené, aby sme službu Enrichment urobili flexibilnejšou, aby sme poskytli možnosť vybrať si, ako obohatiť nespracované dáta prichádzajúcich aplikácií. A nemali sme inú možnosť, ako urobiť službu obohatenia aj bez serverov.
Na prácu s Fission sme použili Fission CLI, ktoré musí byť nainštalované na vrchu Kubernetes CLI. Nasadenie funkcií do klastra k8s je celkom jednoduché, stačí funkcii priradiť internú cestu a vstup, aby sa umožnila prichádzajúca prevádzka, ak je potrebný prístup mimo klastra. Nasadenie jednej funkcie zvyčajne netrvá dlhšie ako 10 sekúnd.
Záverečná prezentácia projektu a zhrnutie
Na ukážku fungovania nášho systému sme na vzdialený server umiestnili jednoduchý formulár, kde si môžete podať žiadosť o niektorý z produktov banky. Ak chcete požiadať, museli ste zadať svoje iniciály, dátum narodenia a telefónne číslo.
Údaje z klientskeho formulára smerovali do kontrolóra, ktorý súčasne odoslal požiadavky na všetky dostupné pravidlá, pričom údaje predtým obohatil podľa zadaných podmienok a uložil ich do spoločného úložiska. Celkovo sme nasadili tri funkcie, ktoré rozhodujú o prichádzajúcich aplikáciách a 4 služby obohacovania dát. Po odoslaní žiadosti klient obdržal naše rozhodnutie:
Klient okrem odmietnutia alebo schválenia dostal aj zoznam ďalších produktov, na ktoré sme paralelne posielali požiadavky. Takto sme demonštrovali možnosť krížového predaja na našej platforme.
Celkovo boli k dispozícii 3 fiktívne bankové produkty:
- Kredit.
- hračka
- Hypotéka.
Počas demonštrácie sme pre každú službu nasadili pripravené funkcie a obohacujúce skripty.
Každé pravidlo vyžadovalo vlastný súbor vstupných údajov. Na schválenie hypotéky sme vypočítali znamenie zverokruhu klienta a spojili ho s logikou lunárneho kalendára. Na schválenie hračky sme skontrolovali plnoletosť klienta a na poskytnutie pôžičky sme poslali žiadosť na externú otvorenú službu na určenie mobilného operátora a bolo o nej rozhodnuté.
Snažili sme sa, aby naša ukážka bola zaujímavá a interaktívna, každý prítomný mohol prejsť na náš formulár a skontrolovať si dostupnosť našich fiktívnych služieb pre nich. A na samom konci prezentácie sme predviedli analýzu prijatých žiadostí, ktorá ukázala, koľko ľudí využilo našu službu, počet schválení a zamietnutí.
Na zhromažďovanie analýz online sme dodatočne nasadili nástroj BI s otvoreným zdrojom a priskrutkovali ho k našej úložnej jednotke. Metabáza vám umožňuje vytvárať obrazovky s analýzami údajov, ktoré nás zaujímajú; stačí zaregistrovať pripojenie k databáze, vybrať tabuľky (v našom prípade zbierky údajov, keďže sme použili MongoDB) a špecifikovať oblasti, ktoré nás zaujímajú. .
Získali sme tak dobrý prototyp rozhodovacej platformy a počas demonštrácie si každý poslucháč mohol osobne skontrolovať jej výkon. Zaujímavé riešenie, hotový prototyp a úspešná ukážka nám umožnili vyhrať aj napriek silnej konkurencii iných tímov. Som si istý, že aj o projekte každého tímu sa dá napísať zaujímavý článok.
Zdroj: hab.com