Cégünk a tavalyi évtől elkezdte hackathonok szervezését. Az első ilyen verseny nagyon jól sikerült, ben írtunk róla . A második hackathon 2019 februárjában zajlott, és nem volt kevésbé sikeres. Az utóbbi megtartásának céljairól nem is olyan régen szervező.
A résztvevők egy meglehetősen érdekes feladatot kaptak, teljes szabadsággal a megvalósításhoz szükséges technológiai halom kiválasztásában. Az ügyfélpontozási funkciók kényelmes telepítéséhez olyan döntéshozatali platformot kellett megvalósítani, amely képes működni az alkalmazások gyors áramlásával, ellenállni a nagy terhelésnek, és maga a rendszer is könnyen méretezhető.
A feladat nem triviális és sokféleképpen megoldható, erről a résztvevők projektjei záróprezentációinak bemutatóján is meggyőződtünk. A hackathonon 6 5 fős csapat vett részt, minden résztvevőnek volt jó projektje, de a mi platformunk bizonyult a legversenyképesebbnek. Van egy nagyon érdekes projektünk, amelyről ebben a cikkben szeretnék beszélni.
Megoldásunk a Kubernetesen belüli szerver nélküli architektúrára épülő platform, amely csökkenti az új funkciók éles verzióba való bevezetéséhez szükséges időt. Lehetővé teszi az elemzők számára, hogy kódot írjanak egy számukra kényelmes környezetben, és mérnökök és fejlesztők részvétele nélkül telepítsék azt a termelésbe.
Mi a pontozás
A Tinkoff.ru, mint sok modern cég, rendelkezik ügyfélpontozással. A pontozás statisztikai adatelemzési módszereken alapuló ügyfélértékelési rendszer.
Például egy ügyfél azzal a kéréssel fordul hozzánk, hogy adjunk neki kölcsönt, vagy nyissunk nálunk egyéni vállalkozói számlát. Ha hitelt tervezünk neki, akkor fel kell mérnünk a fizetőképességét, ha pedig egyéni vállalkozó a számla, akkor biztosnak kell lennünk abban, hogy az ügyfél nem fog csalárd tranzakciókat lebonyolítani.
Az ilyen döntések meghozatalának alapját olyan matematikai modellek képezik, amelyek mind az alkalmazásból, mind a tárhelyünkből származó adatokat elemzik. A pontozáson túl hasonló statisztikai módszerek is alkalmazhatók abban a szolgáltatásban, hogy egyedi ajánlásokat készítsünk új termékekre ügyfeleink számára.
Az ilyen értékelés módszere sokféle bemeneti adatot képes fogadni. Valamikor pedig hozzáadhatunk egy új paramétert a bemenethez, ami a historikus adatok elemzésének eredményei alapján növeli a szolgáltatás igénybevételének konverziós arányát.
Rengeteg adattal rendelkezünk az ügyfélkapcsolatokról, és ezek mennyisége folyamatosan növekszik. Ahhoz, hogy a pontozás működjön, az adatfeldolgozáshoz olyan szabályok (vagy matematikai modellek) is szükségesek, amelyek segítségével gyorsan el lehet dönteni, hogy ki hagyjon jóvá egy kérelmet, kit utasítson el, és kinek ajánljon fel még pár terméket, felmérve potenciális érdeklődését.
Az adott feladathoz már speciális döntéshozatali rendszert használunk , amely az elemzők, technológusok és fejlesztők által felállított szabályok alapján dönti el, hogy az adott banki terméket jóváhagyja vagy megtagadja az ügyféltől.
Számos kész megoldás létezik a piacon, mind a pontozási modellek, mind maguk a döntéshozatali rendszerek. Cégünknél ezen rendszerek egyikét használjuk. De az üzlet növekszik, diverzifikálódik, növekszik mind az ügyfelek, mind a kínált termékek száma, ezzel együtt pedig ötletek is születnek a meglévő döntési folyamat javítására. Bizonyára sok ötlete van a meglévő rendszerrel dolgozóknak, hogyan lehetne egyszerűbbé, jobbá, kényelmesebbé tenni, de néha hasznosak a kívülről jövő ötletek. A New Hackathont azzal a céllal szervezték meg, hogy jó ötleteket gyűjtsenek.
Feladat
A hackathon február 23-án került megrendezésre. A résztvevők harci feladatot kaptak: olyan döntési rendszer kidolgozását, amelynek számos feltételnek meg kellett felelnie.
Elmondtuk, hogyan működik a meglévő rendszer, milyen nehézségek merülnek fel a működése során, illetve milyen üzleti célokat kell követnie a kifejlesztett platformnak. A rendszernek gyors piacra lépési idővel kell rendelkeznie a szabályok kidolgozásához, hogy az elemzők munkakódja a lehető leggyorsabban gyártásba kerüljön. A beérkező kérelmek áramlásánál pedig a döntéshozatali időnek a minimálisra kell csökkennie. Ezenkívül a fejlesztés alatt álló rendszernek keresztértékesítési képességekkel kell rendelkeznie ahhoz, hogy az ügyfélnek lehetősége legyen más céges termékek vásárlására is, ha azok jóváhagyásra kerülnek, és az ügyfél potenciális érdeklődést mutat.
Egyértelmű, hogy nem lehet egyik napról a másikra olyan megjelenésre kész projektet írni, amely minden bizonnyal gyártásba kerül, és meglehetősen nehéz lefedni a teljes rendszert, ezért megkértek minket, hogy legalább egy részét megvalósítsuk. Számos követelményt állapítottak meg, amelyeknek a prototípusnak meg kell felelnie. Megpróbálható volt mind az összes követelmény teljes körű lefedése, mind a fejlesztés alatt álló platform egyes részein részletesen dolgozni.
Ami a technológiát illeti, minden résztvevő teljes választási szabadságot kapott. Bármilyen koncepciót és technológiát lehetett használni: adatfolyam, gépi tanulás, eseményforrás, big data és mások.
A mi megoldásunk
Kis ötletelés után úgy döntöttünk, hogy egy FaaS megoldás lenne ideális a feladat elvégzéséhez.
Ehhez a megoldáshoz megfelelő Serverless keretrendszert kellett találni a fejlesztés alatt álló döntéshozatali rendszer szabályainak megvalósításához. Mivel a Tinkoff aktívan használja a Kuberneteset infrastruktúra-menedzsmentre, több kész megoldást is megvizsgáltunk az alapján, erről majd később mesélek.
A leghatékonyabb megoldás megtalálásához a fejlesztés alatt álló terméket a felhasználók szemével néztük meg. Rendszerünk fő felhasználói a szabályfejlesztéssel foglalkozó elemzők. A szabályokat telepíteni kell a szerverre, vagy – mint esetünkben – a felhőben kell telepíteni a későbbi döntéshozatalhoz. Elemző szemszögéből a munkafolyamat így néz ki:
- Az elemző a raktárból származó adatok alapján szkriptet, szabályt vagy ML-modellt ír. A hackathon keretében a Mongodb használata mellett döntöttünk, de az adattároló rendszer megválasztása itt nem lényeges.
- A kidolgozott szabályok előzményadatokon történő tesztelése után az elemző feltölti a kódját az adminisztrációs panelre.
- A verziószámítás biztosítása érdekében az összes kód a Git-tárolókba kerül.
- Az adminisztrációs panelen keresztül lehetővé válik a kód telepítése a felhőben, mint külön funkcionális szerver nélküli modul.
Az ügyfelektől származó kezdeti adatoknak egy speciális bővítési szolgáltatáson kell keresztülmenniük, amely a kezdeti kérést a raktárból származó adatokkal gazdagítja. Fontos volt, hogy ezt a szolgáltatást úgy valósítsuk meg, hogy az egyetlen tárhellyel működjön (ahonnan az elemző a szabályok kidolgozásakor adatokat vesz fel), hogy az egységes adatstruktúra megmaradjon.
Még a hackathon előtt eldöntöttük, hogy a Serverless keretrendszert használjuk. Ma meglehetősen sok technológia van a piacon, amely megvalósítja ezt a megközelítést. A Kubernetes architektúrán belül a legnépszerűbb megoldások a Fission, az Open FaaS és a Kubeless. Vannak még .
Miután mérlegeltük az előnyöket és hátrányokat, választottunk . Ez a szerver nélküli keretrendszer meglehetősen könnyen kezelhető, és megfelel a feladat követelményeinek.
A Fission használatához két alapvető fogalmat kell megértenie: a funkciót és a környezetet. A függvény egy kódrészlet, amely azon nyelvek valamelyikén van írva, amelyhez létezik Fission környezet. tartalmazza a Python, JS, Go, JVM és sok más népszerű nyelvet és technológiát.
A Fission több fájlra bontott, archívumba előre csomagolt funkciók ellátására is képes. A Fission működését egy Kubernetes klaszterben speciális podok biztosítják, amelyeket maga a keretrendszer kezel. A fürt podokkal való interakcióhoz minden funkcióhoz saját útvonalat kell rendelni, amelyhez POST kérés esetén GET paramétereket vagy kéréstörzset adhat át.
Ennek eredményeként egy olyan megoldás megszerzését terveztük, amely lehetővé teszi az elemzők számára, hogy mérnökök és fejlesztők részvétele nélkül telepítsenek kifejlesztett szabályszkripteket. A leírt megközelítés azt is kiküszöböli, hogy a fejlesztők átírják az elemzői kódot egy másik nyelvre. Például az általunk használt jelenlegi döntéshozatali rendszerhez nagyon speciális technológiákon és nyelveken kell szabályokat írnunk, amelyek hatóköre rendkívül korlátozott, és erős az alkalmazásszervertől való függés is, hiszen minden banki szabálytervezet egyetlen környezetben vannak telepítve. Ennek eredményeként az új szabályok telepítéséhez a teljes rendszert fel kell szabadítani.
Javasolt megoldásunkban nincs szükség szabályok kiadására, a kód egyszerűen, egy gombnyomással telepíthető. Ezenkívül a Kubernetes infrastruktúra-kezelése lehetővé teszi, hogy ne gondoljon a terhelésre és a méretezésre; az ilyen problémák azonnal megoldódnak. Az egyetlen adattárház használata pedig szükségtelenné teszi a valós idejű adatok és a múltbeli adatok összehasonlítását, ami leegyszerűsíti az elemző munkáját.
Amit kaptunk
Mivel kész megoldással (fantáziánkban) érkeztünk a hackathonra, így már csak minden gondolatunkat kódsorokká kellett konvertálni.
A siker kulcsa minden hackathonon a felkészülés és a jól megírt terv. Ezért az első dolgunk az volt, hogy eldöntsük, milyen modulokból álljon rendszerarchitektúránk, és milyen technológiákat használunk.
Projektünk felépítése a következő volt:
Ez a diagram két belépési pontot mutat, az elemzőt (rendszerünk fő felhasználóját) és az ügyfelet.
A munkafolyamat a következőképpen épül fel. Az elemző kifejleszt egy szabályfüggvényt és egy adatdúsító függvényt a modelljéhez, tárolja a kódját egy Git tárolóban, és az adminisztrátori alkalmazáson keresztül telepíti modelljét a felhőbe. Nézzük meg, hogyan hívják meg a telepített függvényt, és döntsünk az ügyfelektől érkező kérésekről:
- Az ügyfél kitölt egy űrlapot a weboldalon és elküldi kérelmét az adatkezelőnek. A rendszerbemenetre érkezik az az alkalmazás, amelyről döntést kell hozni, és eredeti formájában rögzítésre kerül az adatbázisban.
- Ezután a nyers kérelmet elküldik dúsításra, ha szükséges. A kezdeti kérést kiegészítheti mind a külső szolgáltatásokból, mind a tárolóból származó adatokkal. Az eredményül kapott bővített lekérdezés szintén az adatbázisban tárolódik.
- Elindul az elemző funkció, amely egy bővített lekérdezést vesz bemenetként, és egy megoldást készít, amely szintén a tárolóba kerül.
Úgy döntöttünk, hogy a MongoDB-t használjuk tárolóként rendszerünkben az adatok JSON-dokumentumok formájú dokumentum-orientált tárolása miatt, mivel a gazdagító szolgáltatások, beleértve az eredeti kérést is, minden adatot REST vezérlőkön keresztül összesítettek.
Tehát XNUMX óránk volt a platform bevezetésére. Sikeresen osztottuk el a szerepeket, projektünkben minden csapattagnak megvolt a maga felelőssége:
- Front-end adminisztrációs panelek az elemző munkájához, amelyeken keresztül szabályokat tölthetett le az írott szkriptek verziókezelő rendszeréből, kiválaszthatta a bemeneti adatok gazdagításának lehetőségeit és online szerkeszthette a szabályszkripteket.
- Háttérrendszergazda, beleértve az előlapi REST API-t és a VCS-vel való integrációt.
- Infrastruktúra beállítása a Google Cloudban és szolgáltatás fejlesztése a forrásadatok gazdagításához.
- Modul az adminisztrációs alkalmazás és a kiszolgáló nélküli keretrendszer integrálásához a szabályok későbbi telepítéséhez.
- Szabályszkriptek a teljes rendszer teljesítményének teszteléséhez és a beérkező alkalmazások elemzéseinek összesítése (meghozott döntések) a végső demonstrációhoz.
Kezdjük sorrendben.
A frontendünket Angular 7-ben írtuk a banki UI Kit segítségével. Az adminisztrációs panel végleges verziója így nézett ki:
Mivel kevés volt az idő, igyekeztünk csak a legfontosabb funkciókat megvalósítani. A Kubernetes-fürtben egy funkció üzembe helyezéséhez ki kellett választani egy eseményt (olyan szolgáltatást, amelyhez szabályt kell telepíteni a felhőben) és a döntési logikát megvalósító függvény kódját. A kiválasztott szolgáltatáshoz tartozó szabály minden egyes telepítéséhez naplót írtunk erről az eseményről. Az adminisztrációs panelen láthatta az összes esemény naplóját.
Az összes funkciókód egy távoli Git tárolóban volt tárolva, amit szintén be kellett állítani az adminisztrációs panelen. A kód verziózásához az összes funkciót a tároló különböző ágaiban tárolták. Az adminisztrációs panelen lehetőség nyílik az írott szkriptek módosítására is, így egy funkció éles üzembe helyezése előtt nem csak az írott kódot ellenőrizheti, hanem a szükséges módosításokat is elvégezheti.
A szabályfüggvények mellett a forrásadatok fokozatos gazdagításának lehetőségét is megvalósítottuk a gazdagító függvények segítségével, amelyek kódja egyben olyan szkriptek is voltak, amelyekben az adattárházba lehetett menni, külső szolgáltatásokat hívni és előzetes számításokat végezni. . Megoldásunk bemutatásához kiszámítottuk a kérést elhagyó ügyfél csillagjegyét, és harmadik fél REST szolgáltatásával meghatároztuk mobilszolgáltatóját.
A platform hátterét Java nyelven írták, és Spring Boot alkalmazásként valósították meg. Kezdetben azt terveztük, hogy a Postgres-t használjuk az adminisztrátori adatok tárolására, de a hackathon részeként úgy döntöttünk, hogy az időmegtakarítás érdekében egy egyszerű H2-re korlátozzuk magunkat. A háttérben a Bitbucket integrációt valósították meg a lekérdezésbővítő funkciók és a szabályszkriptek verziózásához. A távoli Git-tárolókkal való integrációhoz használtuk , amely egyfajta burkoló a CLI parancsok felett, lehetővé téve bármilyen git utasítás végrehajtását egy kényelmes szoftveres felület segítségével. Így két külön tárolónk volt a gazdagító funkciók és szabályok számára, és az összes szkriptet könyvtárakba osztották. A felhasználói felületen keresztül lehetőség volt kiválasztani a tároló tetszőleges ágának szkriptjének legfrissebb véglegesítését. Amikor az adminisztrációs panelen keresztül módosítja a kódot, a módosított kód véglegesítése távoli tárolókban jött létre.
Elképzelésünk megvalósításához megfelelő infrastruktúrára volt szükségünk. Úgy döntöttünk, hogy Kubernetes-fürtünket a felhőben helyezzük üzembe. A mi választásunk a Google Cloud Platform volt. A Fission szerver nélküli keretrendszert egy Kubernetes-fürtre telepítettük, amelyet a Gcloudban telepítettünk. Kezdetben a forrásadat-dúsító szolgáltatást külön Java-alkalmazásként valósították meg, a k8s-fürtben lévő Pod-ba csomagolva. De miután a hackathon közepén bemutattuk a projektünket, azt javasolták, hogy tegyük rugalmasabbá az Enrichment szolgáltatást, hogy lehetőséget adjunk a beérkező alkalmazások nyers adatainak gazdagítására. És nem volt más választásunk, mint hogy a gazdagító szolgáltatást is szerver nélkülivé tegyük.
A Fission használatához a Fission CLI-t használtuk, amelyet a Kubernetes CLI tetejére kell telepíteni. A függvények telepítése egy k8s-fürtbe meglehetősen egyszerű; csak egy belső útvonalat és belépést kell hozzárendelnie a funkcióhoz, hogy engedélyezze a bejövő forgalmat, ha a fürtön kívüli hozzáférésre van szükség. Egy funkció telepítése általában nem tart tovább 10 másodpercnél.
A projekt záró bemutatása és összegzése
Rendszerünk működésének bemutatására egy egyszerű űrlapot helyeztünk el egy távoli szerveren, ahol a bank valamelyik termékére jelentkezhet. Az igényléshez meg kellett adni a kezdőbetűket, a születési dátumot és a telefonszámot.
Az ügyfélűrlap adatai az adatkezelőhöz kerültek, amely egyidejűleg kérelmet küldött az összes rendelkezésre álló szabályra, előzetesen a megadott feltételeknek megfelelően gazdagította az adatokat, és elmentette azokat egy közös tárhelyre. Összesen három olyan funkciót telepítettünk, amelyek döntéseket hoznak a bejövő alkalmazásokról, és 4 adatgazdagító szolgáltatást. A kérelem benyújtását követően az ügyfél megkapta döntésünket:
Az ügyfél az elutasításon, jóváhagyáson túlmenően más termékek listáját is megkapta, melyre vonatkozó igényeket párhuzamosan küldtünk. Így mutattuk be platformunkon a keresztértékesítés lehetőségét.
Összesen 3 fiktív banki termék volt elérhető:
- Hitel.
- játékszer
- Jelzálog.
A bemutató során az egyes szolgáltatásokhoz előkészített funkciókat és gazdagító szkripteket telepítettünk.
Minden szabályhoz saját bemeneti adatkészletre volt szükség. Tehát a jelzáloghitel jóváhagyásához kiszámítottuk az ügyfél csillagjegyét, és ezt összekapcsoltuk a holdnaptár logikájával. A játék jóváhagyásához ellenőriztük, hogy az ügyfél elérte-e a nagykorúságot, a kölcsön kibocsátásához pedig külső nyílt szolgáltatáshoz kérést küldtünk a mobilszolgáltató meghatározására, amelyről döntés született.
Igyekeztünk érdekessé, interaktívvá tenni bemutatónkat, minden jelenlévő felléphetett az űrlapunkra, és ellenőrizhette kitalált szolgáltatásaink elérhetőségét. Az előadás legvégén pedig a beérkezett kérelmek elemzését mutattuk be, amelyből kiderült, hányan vették igénybe szolgáltatásunkat, hányan vették igénybe a jóváhagyásokat és az elutasításokat.
Az elemzések online gyűjtéséhez egy nyílt forráskódú BI-eszközt is telepítettünk és rácsavarozta a tárolóegységünkre. A Metabase lehetővé teszi, hogy a minket érdeklő adatokról analitikus képernyőket építsünk, csak regisztrálni kell az adatbázishoz való kapcsolatot, kiválasztani a táblákat (esetünkben adatgyűjtéseket, mivel MongoDB-t használtunk), és meg kell adni a minket érdeklő mezőket. .
Ennek eredményeként egy jó döntési platform prototípusát kaptuk, és a bemutató során minden hallgató személyesen ellenőrizhette annak teljesítményét. Egy érdekes megoldás, egy kész prototípus és egy sikeres bemutató lehetővé tette számunkra, hogy a többi csapat erős versenye ellenére nyerjünk. Biztos vagyok benne, hogy minden csapat projektjéről is lehet érdekes cikket írni.
Forrás: will.com