Fra sidste år begyndte vores virksomhed at organisere hackathons. Den første sådanne konkurrence var meget vellykket, vi skrev om den i . Det andet hackathon fandt sted i februar 2019 og var ikke mindre vellykket. Om målene med at holde sidstnævnte for ikke så længe siden arrangør.
Deltagerne fik en ret interessant opgave med fuld frihed til at vælge en teknologistack til implementeringen. Det var nødvendigt at implementere en beslutningstagningsplatform til bekvem implementering af kundescoringsfunktioner, der kunne arbejde med et hurtigt flow af applikationer, modstå store belastninger, og selve systemet var let skalerbart.
Opgaven er ikke-triviel og kan løses på mange måder, som vi blev overbevist om under demonstrationen af de afsluttende præsentationer af deltagernes projekter. Der var 6 hold af 5 personer til hackathon, alle deltagere havde gode projekter, men vores platform viste sig at være den mest konkurrencedygtige. Vi har et meget interessant projekt, som jeg gerne vil tale om i denne artikel.
Vores løsning er en platform baseret på serverløs arkitektur inde i Kubernetes, hvilket reducerer den tid, det tager at bringe nye funktioner til produktion. Det giver analytikere mulighed for at skrive kode i et miljø, der er praktisk for dem, og implementere det i produktion uden deltagelse af ingeniører og udviklere.
Hvad er scoring
Tinkoff.ru har, som mange moderne virksomheder, kundescoring. Scoring er et kundevurderingssystem baseret på statistiske metoder til dataanalyse.
For eksempel henvender en klient sig til os med en anmodning om at udstede et lån til ham eller åbne en individuel iværksætterkonto hos os. Hvis vi planlægger at udstede et lån til ham, skal vi vurdere hans solvens, og hvis kontoen er en individuel iværksætter, skal vi være sikre på, at kunden ikke vil udføre svigagtige transaktioner.
Grundlaget for at træffe sådanne beslutninger er matematiske modeller, der analyserer både data fra selve applikationen og data fra vores lager. Ud over scoring kan lignende statistiske metoder også bruges til at generere individuelle anbefalinger til nye produkter til vores kunder.
Metoden til en sådan vurdering kan acceptere en række inputdata. Og på et tidspunkt kan vi tilføje en ny parameter til inputtet, som baseret på resultaterne af analyser på historiske data vil øge konverteringsraten ved at bruge tjenesten.
Vi har et væld af data om kunderelationer, og mængden af denne information vokser konstant. For at score skal fungere, kræver databehandling også regler (eller matematiske modeller), der giver dig mulighed for hurtigt at beslutte, hvem der skal godkende en ansøgning, hvem der skal afslå, og hvem der skal tilbyde et par produkter mere, og vurdere deres potentielle interesse.
Til opgaven bruger vi allerede et specialiseret beslutningssystem , som ud fra de regler, der er fastsat af analytikere, teknologer og udviklere, beslutter, om kunden skal godkende eller afvise et bestemt bankprodukt.
Der findes mange færdige løsninger på markedet, både scoringsmodeller og selve beslutningssystemer. Vi bruger et af disse systemer i vores virksomhed. Men forretningen vokser, diversificerer sig, både antallet af kunder og antallet af tilbudte produkter stiger, og sideløbende med dette opstår der ideer til, hvordan man kan forbedre den eksisterende beslutningsproces. Folk, der arbejder med det eksisterende system, har sikkert mange ideer til, hvordan man kan gøre det enklere, bedre, mere bekvemt, men nogle gange er ideer udefra nyttige. New Hackathon blev arrangeret med det formål at indsamle gode ideer.
Opgave
Hackathonet blev afholdt den 23. februar. Deltagerne fik tilbudt en kampopgave: At udvikle et beslutningssystem, der skulle opfylde en række betingelser.
Vi fik at vide, hvordan det eksisterende system fungerer, og hvilke vanskeligheder der opstår under driften, samt hvilke forretningsmål den udviklede platform skal forfølge. Systemet skal have en hurtig time-to-market til at udvikle regler, så analytikernes arbejdskodeks kommer i produktion så hurtigt som muligt. Og for den indkommende strøm af ansøgninger bør beslutningstiden være til et minimum. Desuden skal systemet, der udvikles, have krydssalgsmuligheder for at give kunden mulighed for at købe andre firmaprodukter, hvis de er godkendt af os og har potentiel interesse fra kunden.
Det er klart, at det er umuligt at skrive et udgivelsesklar projekt fra den ene dag til den anden, som helt sikkert vil gå i produktion, og det er ret svært at dække hele systemet, så vi blev bedt om at implementere i hvert fald en del af det. Der blev opstillet en række krav, som prototypen skal opfylde. Det var muligt at forsøge både at dække alle kravene i deres helhed, og at arbejde detaljeret på individuelle sektioner af platformen under udvikling.
Med hensyn til teknologi fik alle deltagere fuldstændig valgfrihed. Det var muligt at bruge alle koncepter og teknologier: Datastreaming, machine learning, event sourcing, big data og andre.
Vores løsning
Efter lidt brainstorming besluttede vi, at en FaaS-løsning ville være ideel til at løse opgaven.
Til denne løsning var det nødvendigt at finde et passende Serverless framework til at implementere reglerne for det beslutningssystem, der blev udviklet. Da Tinkoff aktivt bruger Kubernetes til infrastrukturstyring, kiggede vi på flere færdige løsninger baseret på det; jeg fortæller dig mere om det senere.
For at finde den mest effektive løsning har vi set på produktet, der udvikles, gennem brugernes øjne. Hovedbrugerne af vores system er analytikere involveret i regeludvikling. Reglerne skal implementeres på serveren eller, som i vores tilfælde, implementeres i skyen til efterfølgende beslutningstagning. Fra en analytikers perspektiv ser arbejdsgangen således ud:
- Analytikeren skriver et script, en regel eller en ML-model baseret på data fra lageret. Som en del af hackathonet besluttede vi at bruge Mongodb, men valget af datalagringssystem er ikke vigtigt her.
- Efter at have testet de udviklede regler om historiske data, uploader analytikeren sin kode til adminpanelet.
- For at sikre versionering vil al kode gå til Git repositories.
- Gennem admin panelet vil det være muligt at implementere koden i skyen som et separat funktionelt serverløst modul.
Indledende data fra kunder skal passere gennem en specialiseret berigelsestjeneste designet til at berige den indledende anmodning med data fra lageret. Det var vigtigt at implementere denne service på en sådan måde, at den ville arbejde med et enkelt lager (hvorfra analytikeren tager data, når han udvikler regler) for at opretholde en samlet datastruktur.
Allerede før hackathonet besluttede vi os for den serverløse ramme, som vi ville bruge. I dag er der en hel del teknologier på markedet, der implementerer denne tilgang. De mest populære løsninger inden for Kubernetes-arkitekturen er Fission, Open FaaS og Kubeless. Der er endda .
Efter at have vejet alle fordele og ulemper, valgte vi . Denne serverløse ramme er ret nem at administrere og opfylder opgavens krav.
For at arbejde med Fission skal du forstå to grundlæggende begreber: funktion og miljø. En funktion er et stykke kode skrevet på et af de sprog, som der er et Fission-miljø for. inkluderer Python, JS, Go, JVM og mange andre populære sprog og teknologier.
Fission er også i stand til at udføre funktioner opdelt i flere filer, færdigpakket i et arkiv. Driften af Fission i en Kubernetes-klynge sikres af specialiserede pods, som styres af selve rammen. For at interagere med cluster pods skal hver funktion tildeles sin egen rute, og som du kan sende GET-parametre eller anmodningstekst til i tilfælde af en POST-anmodning.
Som et resultat planlagde vi at opnå en løsning, der ville give analytikere mulighed for at implementere udviklede regelscripts uden deltagelse af ingeniører og udviklere. Den beskrevne tilgang eliminerer også behovet for, at udviklere skal omskrive analytikerkoden til et andet sprog. For eksempel, for det nuværende beslutningssystem, vi bruger, skal vi skrive regler i højt specialiserede teknologier og sprog, hvis omfang er ekstremt begrænset, og der er også en stærk afhængighed af applikationsserveren, da alle udkast til bankregler er installeret i et enkelt miljø. Som følge heraf er det nødvendigt at frigive hele systemet for at implementere nye regler.
I vores foreslåede løsning er der ingen grund til at frigive regler; koden kan nemt implementeres med et klik på en knap. Også infrastrukturstyring i Kubernetes giver dig mulighed for ikke at tænke på belastning og skalering; sådanne problemer løses ud af boksen. Og brugen af et enkelt datavarehus eliminerer behovet for at sammenligne realtidsdata med historiske data, hvilket forenkler analytikerens arbejde.
Hvad vi fik
Da vi kom til hackathonet med en færdig løsning (i vores fantasier), var det eneste, vi skulle gøre, at konvertere alle vores tanker til kodelinjer.
Nøglen til succes ved ethvert hackathon er forberedelse og en velskrevet plan. Derfor var det første, vi gjorde, at beslutte, hvilke moduler vores systemarkitektur skulle bestå af, og hvilke teknologier vi ville bruge.
Arkitekturen af vores projekt var som følger:
Dette diagram viser to indgangspunkter, analytikeren (hovedbrugeren af vores system) og klienten.
Arbejdsprocessen er struktureret sådan. Analytikeren udvikler en regelfunktion og en databerigelsesfunktion til sin model, gemmer sin kode i et Git-lager og implementerer sin model til skyen gennem administratorapplikationen. Lad os overveje, hvordan den implementerede funktion vil blive kaldt og træffe beslutninger om indkommende anmodninger fra klienter:
- Klienten udfylder en formular på hjemmesiden og sender sin anmodning til den registeransvarlige. En ansøgning, som der skal tages stilling til, kommer til systemets input og registreres i databasen i sin oprindelige form.
- Dernæst sendes råanmodningen til berigelse, hvis det er nødvendigt. Du kan supplere den indledende anmodning med data både fra eksterne tjenester og fra lageret. Den resulterende berigede forespørgsel gemmes også i databasen.
- Analytikerfunktionen lanceres, som tager en beriget forespørgsel som input og producerer en løsning, som også skrives til lageret.
Vi besluttede at bruge MongoDB som et lager i vores system på grund af den dokumentorienterede lagring af data i form af JSON-dokumenter, da berigelsestjenesterne, inklusive den oprindelige anmodning, aggregerede alle data gennem REST-controllere.
Så vi havde XNUMX timer til at implementere platformen. Vi fordelte rollerne ganske vellykket; hvert teammedlem havde sit eget ansvarsområde i vores projekt:
- Front-end admin paneler for analytikerens arbejde, hvorigennem han kunne downloade regler fra versionskontrolsystemet for skrevne scripts, vælge muligheder for at berige inputdata og redigere regelscripts online.
- Backend admin, inklusive REST API til fronten og integration med VCS.
- Opsætning af infrastruktur i Google Cloud og udvikling af en service til berigelse af kildedata.
- Et modul til at integrere admin-applikationen med Serverless-rammeværket til efterfølgende implementering af regler.
- Scripts af regler for test af ydeevnen af hele systemet og aggregering af analyser på indkommende applikationer (beslutninger truffet) til den endelige demonstration.
Lad os starte i orden.
Vores frontend blev skrevet i Angular 7 ved hjælp af bank-UI Kit. Den endelige version af administratorpanelet så således ud:
Da der var lidt tid, forsøgte vi kun at implementere nøglefunktionaliteten. For at implementere en funktion i Kubernetes-klyngen var det nødvendigt at vælge en hændelse (en tjeneste, for hvilken der skal implementeres en regel i skyen) og koden for den funktion, der implementerer beslutningslogikken. For hver implementering af en regel for den valgte tjeneste skrev vi en log over denne hændelse. I admin panelet kunne du se logfiler over alle hændelser.
Al funktionskode blev gemt i et eksternt Git-lager, som også skulle indstilles i admin-panelet. For at versionere koden blev alle funktioner gemt i forskellige grene af depotet. Admin-panelet giver også mulighed for at foretage justeringer af skrevne scripts, så før du implementerer en funktion til produktion, kan du ikke kun kontrollere den skrevne kode, men også foretage de nødvendige ændringer.
Udover regelfunktionerne implementerede vi også muligheden for gradvist at berige kildedataene ved hjælp af berigelsesfunktioner, hvis kode også var scripts, hvor det var muligt at gå til datavarehuset, ringe til tredjepartstjenester og udføre foreløbige beregninger . For at demonstrere vores løsning, beregnede vi stjernetegnet for den klient, der forlod anmodningen, og bestemte sin mobiloperatør ved hjælp af en tredjeparts REST-tjeneste.
Backend af platformen blev skrevet i Java og implementeret som en Spring Boot-applikation. Vi planlagde oprindeligt at bruge Postgres til at gemme administratordata, men som en del af hackathonet besluttede vi at begrænse os til en simpel H2 for at spare tid. På backend blev integration med Bitbucket implementeret for at versionere forespørgselsberigelsesfunktionerne og regelscripts. Til integration med eksterne Git-lagre brugte vi , som er en slags indpakning over CLI-kommandoer, der giver dig mulighed for at udføre enhver git-instruktion ved hjælp af en praktisk softwaregrænseflade. Så vi havde to separate arkiver til berigelsesfunktioner og regler, og alle scripts blev opdelt i mapper. Gennem brugergrænsefladen var det muligt at vælge den seneste commit af et script fra en vilkårlig gren af depotet. Når der blev foretaget ændringer i koden gennem adminpanelet, blev der oprettet commits for den ændrede kode i fjernlager.
For at implementere vores idé havde vi brug for passende infrastruktur. Vi besluttede at implementere vores Kubernetes-klynge i skyen. Vores valg var Google Cloud Platform. Fission-serverløse rammer blev installeret på en Kubernetes-klynge, som vi implementerede i Gcloud. Oprindeligt blev kildedataberigelsestjenesten implementeret som en separat Java-applikation pakket ind i en Pod inde i k8s-klyngen. Men efter en foreløbig demonstration af vores projekt midt i hackathonet, blev vi anbefalet at gøre Enrichment-tjenesten mere fleksibel for at give mulighed for at vælge, hvordan man beriger rådataene fra indkommende applikationer. Og vi havde intet andet valg end at gøre berigelsestjenesten også serverløs.
Til at arbejde med Fission brugte vi Fission CLI, som skal installeres oven på Kubernetes CLI. Det er ret simpelt at implementere funktioner i en k8s-klynge; du skal blot tildele en intern rute og indgang til funktionen for at tillade indgående trafik, hvis der er behov for adgang uden for klyngen. Implementering af én funktion tager typisk ikke mere end 10 sekunder.
Afsluttende præsentation af projektet og opsummering
For at demonstrere, hvordan vores system fungerer, har vi placeret en simpel formular på en ekstern server, hvor du kan indsende en ansøgning til et af bankens produkter. For at anmode om, skulle du indtaste dine initialer, fødselsdato og telefonnummer.
Data fra klientformularen gik til controlleren, som samtidig sendte anmodninger om alle tilgængelige regler, efter at have beriget dataene i henhold til de specificerede betingelser og gemt dem i et fælles lager. I alt implementerede vi tre funktioner, der træffer beslutninger om indkommende applikationer og 4 databerigelsestjenester. Efter indsendelse af ansøgningen modtog kunden vores afgørelse:
Udover afslag eller godkendelse modtog kunden også en liste over andre produkter, forespørgsler som vi sendte sideløbende. Sådan demonstrerede vi muligheden for krydssalg i vores platform.
Der var i alt 3 fiktive bankprodukter tilgængelige:
- Kredit.
- legetøj
- Pant.
Under demonstrationen implementerede vi forberedte funktioner og berigelsesscripts for hver tjeneste.
Hver regel krævede sit eget sæt inputdata. Så for at godkende et realkreditlån beregnede vi kundens stjernetegn og forbandt dette med månekalenderens logik. For at godkende et legetøj kontrollerede vi, at klienten var myndig, og for at udstede et lån sendte vi en anmodning til en ekstern åben tjeneste for at bestemme mobiloperatøren, og der blev truffet en beslutning om det.
Vi forsøgte at gøre vores demonstration interessant og interaktiv, alle tilstedeværende kunne gå til vores formular og tjekke tilgængeligheden af vores fiktive tjenester til dem. Og til allersidst i præsentationen demonstrerede vi analyser af modtagne ansøgninger, som viste, hvor mange der brugte vores service, antallet af godkendelser og afslag.
For at indsamle analyser online har vi desuden implementeret et open source BI-værktøj og skruet den fast på vores opbevaringsenhed. Metabase giver dig mulighed for at bygge skærmbilleder med analyser på de data, der interesserer os; du skal blot registrere en forbindelse til databasen, vælge tabeller (i vores tilfælde dataindsamlinger, da vi brugte MongoDB) og specificere de områder, der interesserer os .
Som et resultat fik vi en god prototype af en beslutningsplatform, og under demonstrationen kunne hver lytter personligt tjekke dens præstationer. En interessant løsning, en færdig prototype og en vellykket demonstration gjorde det muligt for os at vinde, trods stærk konkurrence fra andre hold. Jeg er sikker på, at der også kan skrives en interessant artikel om hvert teams projekt.
Kilde: www.habr.com