Od loňského roku začala naše společnost pořádat hackathony. První taková soutěž byla velmi úspěšná, psali jsme o ní v . Druhý hackathon proběhl v únoru 2019 a byl neméně úspěšný. O cílech držet to druhé není tak dávno organizátor.
Účastníci dostali poměrně zajímavý úkol s naprostou svobodou ve výběru technologického zásobníku pro jeho implementaci. Bylo nutné implementovat rozhodovací platformu pro pohodlné nasazení zákaznických scoringových funkcí, které by mohly pracovat s rychlým tokem aplikací, odolávat velké zátěži a samotný systém byl snadno škálovatelný.
Úkol je netriviální a lze jej vyřešit mnoha způsoby, jak jsme se přesvědčili při ukázce závěrečných prezentací projektů účastníků. Na hackathonu bylo 6 týmů po 5 lidech, všichni účastníci měli dobré projekty, ale naše platforma se ukázala jako nejvíce konkurenceschopná. Máme velmi zajímavý projekt, o kterém bych rád hovořil v tomto článku.
Naše řešení je platforma založená na bezserverové architektuře uvnitř Kubernetes, což zkracuje dobu potřebnou k uvedení nových funkcí do produkce. Umožňuje analytikům psát kód v prostředí, které jim vyhovuje, a nasazovat jej do produkce bez účasti inženýrů a vývojářů.
Co je bodování
Tinkoff.ru, stejně jako mnoho moderních společností, má hodnocení zákazníků. Scoring je systém hodnocení zákazníků založený na statistických metodách analýzy dat.
Klient se na nás například obrátí s žádostí o poskytnutí úvěru nebo o založení individuálního podnikatelského účtu u nás. Pokud mu plánujeme poskytnout úvěr, musíme posoudit jeho solventnost, a pokud je účet individuální podnikatel, musíme si být jisti, že klient nebude provádět podvodné transakce.
Základem pro taková rozhodnutí jsou matematické modely, které analyzují jak data ze samotné aplikace, tak data z našeho úložiště. Kromě bodování lze podobné statistické metody využít i ve službě generování individuálních doporučení na nové produkty pro naše klienty.
Metoda takového hodnocení může přijímat různé vstupní údaje. A v určitém okamžiku můžeme na vstup přidat nový parametr, který na základě výsledků analýzy na historických datech zvýší konverzní poměr používání služby.
Máme velké množství dat o vztazích se zákazníky a objem těchto informací neustále roste. Aby bodování fungovalo, vyžaduje zpracování dat také pravidla (nebo matematické modely), které vám umožní rychle se rozhodnout, komu žádost schválit, koho odmítnout a komu nabídnout několik dalších produktů, a posoudit jejich potenciální zájem.
Pro daný úkol již používáme specializovaný systém rozhodování , která na základě pravidel nastavených analytiky, technology a vývojáři rozhoduje o schválení či zamítnutí konkrétního bankovního produktu klientovi.
Na trhu je mnoho hotových řešení, jak skórovacích modelů, tak samotných rozhodovacích systémů. Jeden z těchto systémů používáme i v naší společnosti. Ale byznys roste, diverzifikuje se, zvyšuje se jak počet klientů, tak i počet nabízených produktů a spolu s tím se objevují nápady, jak zlepšit stávající rozhodovací proces. Lidé pracující se stávajícím systémem mají jistě mnoho nápadů, jak jej zjednodušit, zlepšit, pohodlněji, ale někdy se hodí nápady zvenčí. Nový Hackathon byl organizován s cílem shromáždit dobré nápady.
Úkol
Hackathon se konal 23. února. Účastníkům byl nabídnut bojový úkol: vyvinout systém rozhodování, který musel splňovat řadu podmínek.
Bylo nám řečeno, jak stávající systém funguje a jaké potíže vznikají při jeho provozu, a také jaké obchodní cíle by měla vyvíjená platforma sledovat. Systém musí mít rychlý čas uvedení na trh pro vývoj pravidel, aby se pracovní kodex analytiků dostal do výroby co nejrychleji. A v případě příchozího toku žádostí by doba rozhodování měla směřovat k minimu. Vyvíjený systém musí mít také možnosti křížového prodeje, aby měl klient možnost zakoupit si další produkty společnosti, pokud jsou námi schváleny a mají potenciální zájem ze strany klienta.
Je jasné, že není možné napsat přes noc hotový projekt, který se jistě dostane do výroby, a obsáhnout celý systém je poměrně obtížné, proto jsme byli požádáni o implementaci alespoň části. Byla stanovena řada požadavků, které musí prototyp splňovat. Bylo možné si vyzkoušet jak pokrýt všechny požadavky v celém rozsahu, tak detailně pracovat na jednotlivých sekcích vyvíjené platformy.
Pokud jde o technologii, všichni účastníci měli naprostou svobodu volby. Bylo možné použít libovolné koncepty a technologie: Streamování dat, strojové učení, event sourcing, velká data a další.
Naše řešení
Po krátkém brainstormingu jsme se rozhodli, že řešení FaaS by bylo ideální pro dokončení úkolu.
Pro toto řešení bylo nutné najít vhodný Serverless framework pro implementaci pravidel vyvíjeného rozhodovacího systému. Vzhledem k tomu, že Tinkoff aktivně využívá Kubernetes pro správu infrastruktury, podívali jsme se na několik hotových řešení založených na něm, o tom vám povím později.
Abychom našli nejúčinnější řešení, podívali jsme se na vyvíjený produkt očima jeho uživatelů. Hlavními uživateli našeho systému jsou analytici zabývající se vývojem pravidel. Pro následné rozhodování je nutné pravidla nasadit na server, nebo jako v našem případě nasadit v cloudu. Z pohledu analytika vypadá pracovní postup takto:
- Analytik napíše skript, pravidlo nebo model ML na základě dat ze skladu. V rámci hackathonu jsme se rozhodli použít Mongodb, ale výběr systému ukládání dat zde není důležitý.
- Po otestování vyvinutých pravidel na historických datech nahraje analytik svůj kód do panelu administrátora.
- Aby bylo zajištěno verzování, veškerý kód půjde do repozitářů Git.
- Prostřednictvím admin panelu bude možné nasadit kód v cloudu jako samostatný funkční modul Serverless.
Prvotní data od klientů musí projít specializovanou službou Enrichment navrženou tak, aby obohatila prvotní požadavek o data ze skladu. Důležité bylo implementovat tuto službu tak, aby fungovala s jediným úložištěm (ze kterého analytik bere data při vývoji pravidel) a udržovala jednotnou datovou strukturu.
Ještě před hackathonem jsme se rozhodli pro framework Serverless, který budeme používat. Dnes je na trhu poměrně hodně technologií, které tento přístup implementují. Nejoblíbenější řešení v rámci architektury Kubernetes jsou Fission, Open FaaS a Kubeless. Existují dokonce .
Po zvážení všech pro a proti jsme vybrali . Tento bezserverový framework se celkem snadno spravuje a splňuje požadavky daného úkolu.
Chcete-li pracovat s Fission, musíte pochopit dva základní pojmy: funkce a prostředí. Funkce je část kódu napsaná v jednom z jazyků, pro které existuje prostředí Fission. zahrnuje Python, JS, Go, JVM a mnoho dalších populárních jazyků a technologií.
Fission je také schopen provádět funkce rozdělené do několika souborů, předem zabalených do archivu. Provoz Fission v clusteru Kubernetes zajišťují specializované pody, které jsou spravovány samotným frameworkem. Pro interakci s clusterovými moduly musí být každé funkci přiřazena vlastní trasa a do které můžete předat parametry GET nebo tělo požadavku v případě požadavku POST.
V důsledku toho jsme plánovali získat řešení, které umožní analytikům nasadit vyvinuté skripty pravidel bez účasti inženýrů a vývojářů. Popsaný přístup také eliminuje potřebu vývojářů přepisovat analytický kód do jiného jazyka. Například pro současný rozhodovací systém, který používáme, musíme psát pravidla ve vysoce specializovaných technologiích a jazycích, jejichž rozsah je extrémně omezený, a je zde také velká závislost na aplikačním serveru, protože všechny návrhy bankovních pravidel jsou nasazeny v jediném prostředí. V důsledku toho je pro nasazení nových pravidel nutné uvolnit celý systém.
V námi navrženém řešení není potřeba uvolňovat pravidla, kód lze snadno nasadit kliknutím na tlačítko. Správa infrastruktury v Kubernetes vám také umožňuje nemyslet na zatížení a škálování; takové problémy jsou vyřešeny ihned po vybalení. A použití jediného datového skladu eliminuje potřebu porovnávat data v reálném čase s historickými daty, což analytikům zjednodušuje práci.
Co jsme dostali
Vzhledem k tomu, že jsme na hackathon přišli s hotovým řešením (v našich fantaziích), nezbývalo než převést všechny naše myšlenky do řádků kódu.
Klíčem k úspěchu na každém hackathonu je příprava a dobře napsaný plán. Proto jsme se nejprve rozhodli, z jakých modulů se bude architektura našeho systému skládat a jaké technologie použijeme.
Architektura našeho projektu byla následující:
Tento diagram ukazuje dva vstupní body, analytika (hlavního uživatele našeho systému) a klienta.
Pracovní proces je takto strukturován. Analytik pro svůj model vyvine funkci pravidel a funkci obohacování dat, uloží svůj kód do úložiště Git a nasadí svůj model do cloudu prostřednictvím aplikace správce. Podívejme se, jak bude nasazená funkce volána, a učiníme rozhodnutí o příchozích požadavcích od klientů:
- Klient vyplní formulář na webu a odešle svůj požadavek správci. Aplikace, o které je třeba rozhodnout, přichází na vstup systému a je zaznamenána v databázi v původní podobě.
- Dále je v případě potřeby odeslán nezpracovaný požadavek k obohacení. Prvotní požadavek můžete doplnit o data jak z externích služeb, tak z úložiště. Výsledný obohacený dotaz je také uložen v databázi.
- Spustí se funkce analytika, která vezme jako vstup obohacený dotaz a vytvoří řešení, které se také zapíše do úložiště.
MongoDB jsme se rozhodli použít jako úložiště v našem systému z důvodu dokumentově orientovaného ukládání dat ve formě dokumentů JSON, protože služby obohacení, včetně původního požadavku, agregovaly všechna data přes REST řadiče.
Na implementaci platformy jsme tedy měli XNUMX hodin. Role jsme rozdělili celkem úspěšně, každý člen týmu měl v našem projektu svou vlastní oblast odpovědnosti:
- Frontendové administrátorské panely pro práci analytika, přes které mohl stahovat pravidla ze systému správy verzí psaných skriptů, vybírat možnosti pro obohacení vstupních dat a upravovat skripty pravidel online.
- Backend admin, včetně REST API pro frontu a integrace s VCS.
- Nastavení infrastruktury v Google Cloud a vývoj služby pro obohacení zdrojových dat.
- Modul pro integraci admin aplikace s frameworkem Serverless pro následné nasazení pravidel.
- Skripty pravidel pro testování výkonu celého systému a agregaci analytiků na příchozích aplikacích (přijatá rozhodnutí) pro finální demonstraci.
Začněme v pořádku.
Náš frontend byl napsán v Angular 7 pomocí sady bankovního uživatelského rozhraní. Finální verze administračního panelu vypadala takto:
Protože bylo málo času, snažili jsme se implementovat pouze klíčovou funkcionalitu. Pro nasazení funkce v clusteru Kubernetes bylo nutné vybrat událost (službu, pro kterou je potřeba nasadit pravidlo v cloudu) a kód funkce, která implementuje rozhodovací logiku. Pro každé nasazení pravidla pro vybranou službu jsme sepsali protokol této události. V administračním panelu jste mohli vidět protokoly všech událostí.
Veškerý funkční kód byl uložen ve vzdáleném úložišti Git, které bylo také nutné nastavit v admin panelu. Pro verzi kódu byly všechny funkce uloženy v různých větvích úložiště. Administrační panel také poskytuje možnost provádět úpravy napsaných skriptů, takže před nasazením funkce do produkce můžete nejen zkontrolovat napsaný kód, ale také provést potřebné změny.
Kromě funkcí pravidel jsme implementovali i možnost postupného obohacování zdrojových dat pomocí funkcí Enrichment, jejichž kódem byly i skripty, ve kterých bylo možné přejít do datového skladu, volat služby třetích stran a provádět předběžné výpočty . Pro demonstraci našeho řešení jsme vypočítali znamení zvěrokruhu klienta, který opustil požadavek, a určili jeho mobilního operátora pomocí služby REST třetí strany.
Backend platformy byl napsán v Javě a implementován jako aplikace Spring Boot. Původně jsme plánovali používat Postgres k ukládání administrátorských dat, ale v rámci hackathonu jsme se rozhodli omezit se na jednoduchý H2, abychom ušetřili čas. Na backendu byla implementována integrace s Bitbucket pro verzi funkcí pro obohacení dotazů a skriptů pravidel. Pro integraci se vzdálenými repozitáři Git jsme použili , což je druh obalu přes příkazy CLI, který vám umožňuje provádět jakékoli instrukce git pomocí pohodlného softwarového rozhraní. Měli jsme tedy dvě samostatná úložiště pro funkce a pravidla obohacování a všechny skripty byly rozděleny do adresářů. Prostřednictvím uživatelského rozhraní bylo možné vybrat nejnovější odevzdání skriptu libovolné větve úložiště. Při provádění změn v kódu prostřednictvím panelu správce se ve vzdálených úložištích vytvořily odevzdání změněného kódu.
K realizaci našeho nápadu jsme potřebovali vhodnou infrastrukturu. Rozhodli jsme se nasadit náš cluster Kubernetes v cloudu. Naše volba byla Google Cloud Platform. Bezserverový framework Fission byl nainstalován na clusteru Kubernetes, který jsme nasadili v Gcloudu. Zpočátku byla služba obohacení zdrojových dat implementována jako samostatná Java aplikace zabalená v podu uvnitř clusteru k8s. Ale po předběžné ukázce našeho projektu uprostřed hackathonu nám bylo doporučeno, abychom službu Enrichment učinili flexibilnější, abychom si mohli vybrat, jak obohatit nezpracovaná data příchozích aplikací. A nezbylo nám nic jiného, než udělat službu obohacení také bez serveru.
Pro práci s Fission jsme použili rozhraní Fission CLI, které je nutné nainstalovat na rozhraní Kubernetes CLI. Nasazení funkcí do clusteru k8s je poměrně jednoduché, stačí funkci přiřadit interní směrování a vstup, aby byl povolen příchozí provoz, pokud je potřeba přístup mimo cluster. Nasazení jedné funkce obvykle netrvá déle než 10 sekund.
Závěrečná prezentace projektu a shrnutí
Abychom demonstrovali, jak náš systém funguje, umístili jsme na vzdálený server jednoduchý formulář, kde můžete podat žádost o některý z produktů banky. Chcete-li požádat, museli jste zadat své iniciály, datum narození a telefonní číslo.
Data z klientského formuláře putovala do správce, který současně odeslal požadavky na všechna dostupná pravidla, předem obohatil data podle zadaných podmínek a uložil je do společného úložiště. Celkem jsme nasadili tři funkce, které rozhodují o příchozích aplikacích, a 4 služby obohacování dat. Po odeslání žádosti klient obdržel naše rozhodnutí:
Kromě zamítnutí či schválení klient obdržel i seznam dalších produktů, na které jsme paralelně zasílali požadavky. Takto jsme demonstrovali možnost křížového prodeje na naší platformě.
K dispozici byly celkem 3 fiktivní bankovní produkty:
- Kredit.
- Hračička
- Hypoteční.
Během ukázky jsme nasadili připravené funkce a obohacovací skripty pro každou službu.
Každé pravidlo vyžadovalo vlastní sadu vstupních dat. Abychom schválili hypotéku, vypočítali jsme klientovo znamení zvěrokruhu a spojili to s logikou lunárního kalendáře. Pro schválení hračky jsme zkontrolovali plnoletost klienta a pro vystavení půjčky jsme zaslali žádost na externí otevřenou službu na určení mobilního operátora a bylo o ní rozhodnuto.
Snažili jsme se, aby naše ukázka byla zajímavá a interaktivní, každý přítomný mohl přejít na náš formulář a ověřit si dostupnost našich fiktivních služeb pro ně. A na úplný závěr prezentace jsme předvedli analýzu přijatých žádostí, která ukázala, kolik lidí naši službu využilo, počet schválení a zamítnutí.
Abychom shromažďovali analýzy online, nasadili jsme navíc open source nástroj BI a přišrouboval ji k naší úložné jednotce. Metabase vám umožňuje vytvářet obrazovky s analytikou na datech, která nás zajímají; stačí zaregistrovat připojení k databázi, vybrat tabulky (v našem případě kolekce dat, protože jsme použili MongoDB) a specifikovat pole, která nás zajímají. .
Ve výsledku jsme získali dobrý prototyp rozhodovací platformy a během ukázky si každý posluchač mohl osobně ověřit její výkon. Zajímavé řešení, hotový prototyp a úspěšná ukázka nám umožnily zvítězit i přes silnou konkurenci ostatních týmů. Jsem si jistý, že o projektu každého týmu lze také napsat zajímavý článek.
Zdroj: www.habr.com