Fra og med i fjor begynte selskapet vårt å organisere hackathons. Den første slike konkurransen var veldig vellykket, vi skrev om den i . Det andre hackathonet fant sted i februar 2019 og var ikke mindre vellykket. Om målene med å holde sistnevnte for ikke så lenge siden arrangør.
Deltakerne fikk en ganske interessant oppgave med full frihet til å velge en teknologistabel for implementeringen. Det var nødvendig å implementere en beslutningsplattform for praktisk distribusjon av kundescoringsfunksjoner som kunne fungere med en rask flyt av applikasjoner, tåle store belastninger, og selve systemet var enkelt skalerbart.
Oppgaven er ikke-triviell og kan løses på mange måter, som vi ble overbevist om under demonstrasjonen av sluttpresentasjonene av deltakernes prosjekter. Det var 6 lag på 5 personer på hackathon, alle deltakerne hadde gode prosjekter, men plattformen vår viste seg å være den mest konkurransedyktige. Vi har et veldig interessant prosjekt, som jeg gjerne vil snakke om i denne artikkelen.
Vår løsning er en plattform basert på serverløs arkitektur inne i Kubernetes, som reduserer tiden det tar å bringe nye funksjoner til produksjon. Det lar analytikere skrive kode i et miljø som er praktisk for dem og distribuere den til produksjon uten deltakelse fra ingeniører og utviklere.
Hva er scoring
Tinkoff.ru, som mange moderne selskaper, har kundescoring. Scoring er et kundevurderingssystem basert på statistiske metoder for dataanalyse.
For eksempel, en klient henvender seg til oss med en forespørsel om å gi ham et lån, eller åpne en individuell gründerkonto hos oss. Hvis vi planlegger å gi ham et lån, må vi vurdere soliditeten hans, og hvis kontoen er en individuell gründer, må vi være sikre på at klienten ikke vil utføre uredelige transaksjoner.
Grunnlaget for å ta slike beslutninger er matematiske modeller som analyserer både dataene fra selve applikasjonen og dataene fra lagringen vår. I tillegg til scoring, kan lignende statistiske metoder også brukes i tjenesten for å generere individuelle anbefalinger for nye produkter for våre kunder.
Metoden for en slik vurdering kan akseptere en rekke inputdata. Og på et tidspunkt kan vi legge til en ny parameter til input, som, basert på resultatene av analyse på historiske data, vil øke konverteringsfrekvensen ved bruk av tjenesten.
Vi har et vell av data om kundeforhold, og volumet av denne informasjonen vokser stadig. For at scoring skal fungere, krever databehandling også regler (eller matematiske modeller) som lar deg raskt bestemme hvem du skal godkjenne en søknad, hvem du skal avslå, og hvem du skal tilby et par produkter til, for å vurdere deres potensielle interesse.
For den aktuelle oppgaven bruker vi allerede et spesialisert beslutningssystem , som, basert på reglene satt av analytikere, teknologer og utviklere, bestemmer om de skal godkjenne eller avslå et bestemt bankprodukt til kunden.
Det finnes mange ferdige løsninger på markedet, både scoringsmodeller og selve beslutningssystemer. Vi bruker et av disse systemene i vår bedrift. Men virksomheten vokser, diversifiserer seg, både antall kunder og antall produkter som tilbys øker, og sammen med dette dukker det opp ideer om hvordan man kan forbedre den eksisterende beslutningsprosessen. Folk som jobber med det eksisterende systemet har sikkert mange ideer om hvordan de kan gjøre det enklere, bedre, mer praktisk, men noen ganger er ideer utenfra nyttige. The New Hackathon ble organisert med sikte på å samle gode ideer.
Oppgave
Hackathonet ble arrangert 23. februar. Deltakerne ble tilbudt en kampoppgave: å utvikle et beslutningssystem som måtte oppfylle en rekke betingelser.
Vi ble fortalt hvordan det eksisterende systemet fungerer og hvilke vanskeligheter som oppstår under driften, samt hvilke forretningsmål den utviklede plattformen skal forfølge. Systemet må ha en rask time-to-market for å utvikle regler slik at arbeidskoden til analytikere kommer i produksjon så raskt som mulig. Og for den innkommende søknadsstrømmen bør beslutningstiden være til et minimum. Dessuten må systemet som utvikles ha krysssalgsmuligheter for å gi kunden mulighet til å kjøpe andre bedriftsprodukter dersom de er godkjent av oss og har potensiell interesse fra kunden.
Det er klart at det er umulig å skrive et utgivelsesklart prosjekt over natten som helt sikkert vil gå i produksjon, og det er ganske vanskelig å dekke hele systemet, så vi ble bedt om å implementere i det minste en del av det. Det ble etablert en rekke krav som prototypen skal tilfredsstille. Det var mulig å prøve både å dekke alle kravene i sin helhet, og å jobbe i detalj på enkeltseksjoner av plattformen som ble utviklet.
Når det gjelder teknologi, fikk alle deltakerne full valgfrihet. Det var mulig å bruke hvilke som helst konsepter og teknologier: Datastrømming, maskinlæring, event sourcing, big data og andre.
Vår løsning
Etter en liten brainstorming bestemte vi oss for at en FaaS-løsning ville være ideell for å fullføre oppgaven.
For denne løsningen var det nødvendig å finne et passende serverløst rammeverk for å implementere reglene for beslutningssystemet som ble utviklet. Siden Tinkoff aktivt bruker Kubernetes for infrastrukturstyring, har vi sett på flere ferdige løsninger basert på det, jeg vil fortelle deg mer om det senere.
For å finne den mest effektive løsningen, så vi på produktet som ble utviklet gjennom øynene til brukerne. Hovedbrukerne av systemet vårt er analytikere som er involvert i regelutvikling. Reglene må distribueres til serveren, eller, som i vårt tilfelle, distribueres i skyen, for senere beslutningstaking. Fra en analytikers perspektiv ser arbeidsflyten slik ut:
- Analytikeren skriver et skript, en regel eller en ML-modell basert på data fra lageret. Som en del av hackathonet bestemte vi oss for å bruke Mongodb, men valget av datalagringssystem er ikke viktig her.
- Etter å ha testet de utviklede reglene for historiske data, laster analytikeren opp koden sin til adminpanelet.
- For å sikre versjonering vil all kode gå til Git-repositories.
- Gjennom adminpanelet vil det være mulig å distribuere koden i skyen som en egen funksjonell Serverløs modul.
Innledende data fra klienter må passere gjennom en spesialisert berikelsestjeneste designet for å berike den første forespørselen med data fra lageret. Det var viktig å implementere denne tjenesten på en slik måte at den ville fungere med et enkelt depot (som analytikeren henter data fra når han utvikler regler) for å opprettholde en enhetlig datastruktur.
Allerede før hackathonet bestemte vi oss for det serverløse rammeverket som vi skulle bruke. I dag er det ganske mange teknologier på markedet som implementerer denne tilnærmingen. De mest populære løsningene innenfor Kubernetes-arkitekturen er Fission, Open FaaS og Kubeless. Det er til og med .
Etter å ha veid alle fordeler og ulemper, valgte vi . Dette serverløse rammeverket er ganske enkelt å administrere og oppfyller kravene til oppgaven.
For å jobbe med Fission må du forstå to grunnleggende begreper: funksjon og miljø. En funksjon er et stykke kode skrevet på et av språkene det finnes et Fission-miljø for. inkluderer Python, JS, Go, JVM og mange andre populære språk og teknologier.
Fission er også i stand til å utføre funksjoner delt inn i flere filer, ferdigpakket i et arkiv. Driften av Fission i en Kubernetes-klynge sikres av spesialiserte pods, som administreres av selve rammeverket. For å samhandle med cluster pods, må hver funksjon tildeles sin egen rute, og som du kan sende GET-parametere eller forespørselstekst til i tilfelle en POST-forespørsel.
Som et resultat planla vi å skaffe en løsning som ville tillate analytikere å distribuere utviklede regelskript uten deltakelse fra ingeniører og utviklere. Den beskrevne tilnærmingen eliminerer også behovet for utviklere å omskrive analytikerkode til et annet språk. For eksempel, for det nåværende beslutningssystemet vi bruker, må vi skrive regler i høyt spesialiserte teknologier og språk, hvis omfang er ekstremt begrenset, og det er også en sterk avhengighet av applikasjonsserveren, siden alle utkast til bankregler er utplassert i ett enkelt miljø. Som et resultat, for å distribuere nye regler, er det nødvendig å frigi hele systemet.
I vår foreslåtte løsning er det ikke nødvendig å frigi regler; koden kan enkelt distribueres med et klikk på en knapp. Infrastrukturadministrasjon i Kubernetes lar deg også ikke tenke på belastning og skalering; slike problemer løses rett ut av boksen. Og bruken av ett enkelt datavarehus eliminerer behovet for å sammenligne sanntidsdata med historiske data, noe som forenkler analytikerens arbeid.
Hva vi fikk
Siden vi kom til hackathon med en ferdig løsning (i fantasiene våre), var det bare å gjøre om alle tankene våre til kodelinjer.
Nøkkelen til suksess på ethvert hackathon er forberedelse og en velskrevet plan. Derfor var det første vi gjorde å bestemme hvilke moduler vår systemarkitektur skulle bestå av og hvilke teknologier vi skulle bruke.
Arkitekturen til prosjektet vårt var som følger:
Dette diagrammet viser to inngangspunkter, analytikeren (hovedbrukeren av systemet vårt) og klienten.
Arbeidsprosessen er strukturert slik. Analytikeren utvikler en regelfunksjon og en databerikelsesfunksjon for modellen sin, lagrer koden sin i et Git-depot og distribuerer modellen til skyen gjennom administratorapplikasjonen. La oss vurdere hvordan den distribuerte funksjonen vil bli kalt og ta beslutninger om innkommende forespørsler fra klienter:
- Klienten fyller ut et skjema på nettsiden og sender sin forespørsel til kontrolløren. En søknad som må tas avgjørelse kommer til systeminngangen og registreres i databasen i sin opprinnelige form.
- Deretter sendes råforespørselen for berikelse, om nødvendig. Du kan supplere den første forespørselen med data både fra eksterne tjenester og fra lageret. Den resulterende berikede spørringen lagres også i databasen.
- Analytikerfunksjonen lanseres, som tar en beriket spørring som input og produserer en løsning, som også skrives til lagringen.
Vi bestemte oss for å bruke MongoDB som lagring i systemet vårt på grunn av dokumentorientert lagring av data i form av JSON-dokumenter, siden berikelsestjenestene, inkludert den opprinnelige forespørselen, aggregerte alle data gjennom REST-kontrollere.
Så vi hadde XNUMX timer på å implementere plattformen. Vi fordelte rollene ganske vellykket; hvert teammedlem hadde sitt eget ansvarsområde i prosjektet vårt:
- Front-end administrasjonspaneler for analytikerens arbeid, der han kunne laste ned regler fra versjonskontrollsystemet for skrevne skript, velge alternativer for å berike inndata og redigere regelskript på nettet.
- Backend admin, inkludert REST API for fronten og integrasjon med VCS.
- Sette opp infrastruktur i Google Cloud og utvikle en tjeneste for å berike kildedata.
- En modul for å integrere admin-applikasjonen med Serverless-rammeverket for påfølgende distribusjon av regler.
- Skript med regler for testing av ytelsen til hele systemet og aggregering av analyser på innkommende applikasjoner (beslutninger tatt) for den endelige demonstrasjonen.
La oss starte i orden.
Frontend vår ble skrevet i Angular 7 ved å bruke bank-UI-settet. Den endelige versjonen av administrasjonspanelet så slik ut:
Siden det var lite tid, prøvde vi å implementere bare nøkkelfunksjonaliteten. For å distribuere en funksjon i Kubernetes-klyngen, var det nødvendig å velge en hendelse (en tjeneste som en regel må distribueres for i skyen) og koden til funksjonen som implementerer beslutningslogikken. For hver distribusjon av en regel for den valgte tjenesten skrev vi en logg over denne hendelsen. I administrasjonspanelet kunne du se logger over alle hendelser.
All funksjonskode ble lagret i et eksternt Git-depot, som også måtte settes i adminpanelet. For å versjonere koden ble alle funksjoner lagret i forskjellige grener av depotet. Administrasjonspanelet gir også muligheten til å gjøre justeringer av skrevne skript, slik at du ikke bare kan sjekke den skrevne koden før du distribuerer en funksjon til produksjon, men også gjøre de nødvendige endringene.
I tillegg til regelfunksjonene implementerte vi også muligheten til å gradvis berike kildedataene ved hjelp av Enrichment-funksjoner, koden som også var skript der det var mulig å gå til datavarehuset, ringe tredjepartstjenester og utføre foreløpige beregninger . For å demonstrere løsningen vår beregnet vi stjernetegnet til klienten som forlot forespørselen og bestemte mobiloperatøren hans ved å bruke en tredjeparts REST-tjeneste.
Bakenden av plattformen ble skrevet i Java og implementert som en Spring Boot-applikasjon. Vi planla opprinnelig å bruke Postgres til å lagre admindata, men som en del av hackathonet bestemte vi oss for å begrense oss til en enkel H2 for å spare tid. På baksiden ble integrasjon med Bitbucket implementert for å versjonere søkeberikelsesfunksjonene og regelskriptene. For integrasjon med eksterne Git-lagre brukte vi , som er en slags innpakning over CLI-kommandoer, som lar deg utføre alle git-instruksjoner ved hjelp av et praktisk programvaregrensesnitt. Så vi hadde to separate arkiver for berikelsesfunksjoner og regler, og alle skriptene ble delt inn i kataloger. Gjennom brukergrensesnittet var det mulig å velge den siste commit av et skript av en vilkårlig gren av depotet. Når du gjorde endringer i koden gjennom administrasjonspanelet, ble commits for den endrede koden opprettet i eksterne repositories.
For å implementere ideen vår trengte vi egnet infrastruktur. Vi bestemte oss for å distribuere Kubernetes-klyngen vår i skyen. Vårt valg var Google Cloud Platform. Det serverløse Fission-rammeverket ble installert på en Kubernetes-klynge, som vi distribuerte i Gcloud. Opprinnelig ble kildedataanrikingstjenesten implementert som en egen Java-applikasjon pakket inn i en Pod inne i k8s-klyngen. Men etter en foreløpig demonstrasjon av prosjektet vårt midt i hackathonet, ble vi anbefalt å gjøre Enrichment-tjenesten mer fleksibel for å gi muligheten til å velge hvordan vi skal berike rådataene til innkommende applikasjoner. Og vi hadde ikke noe annet valg enn å gjøre berikelsestjenesten også serverløs.
For å jobbe med Fission brukte vi Fission CLI, som må installeres på toppen av Kubernetes CLI. Det er ganske enkelt å distribuere funksjoner i en k8s-klynge; du trenger bare å tilordne en intern rute og inngang til funksjonen for å tillate innkommende trafikk hvis tilgang utenfor klyngen er nødvendig. Å implementere én funksjon tar vanligvis ikke mer enn 10 sekunder.
Endelig presentasjon av prosjektet og oppsummering
For å demonstrere hvordan systemet vårt fungerer, har vi lagt et enkelt skjema på en ekstern server hvor du kan sende inn en søknad om et av bankens produkter. For å be om, måtte du skrive inn initialer, fødselsdato og telefonnummer.
Data fra klientskjemaet gikk til kontrolløren, som samtidig sendte forespørsler om alle tilgjengelige regler, etter å ha beriket dataene i henhold til de spesifiserte forholdene, og lagret dem i en felles lagring. Totalt har vi implementert tre funksjoner som tar beslutninger om innkommende applikasjoner og 4 databerikelsestjenester. Etter innsending av søknaden mottok klienten vår avgjørelse:
I tillegg til avslag eller godkjenning, mottok klienten også en liste over andre produkter, forespørsler som vi sendte parallelt. Slik demonstrerte vi muligheten for krysssalg i vår plattform.
Totalt var 3 fiktive bankprodukter tilgjengelig:
- Kreditt.
- leketøy
- Boliglån.
Under demonstrasjonen distribuerte vi forberedte funksjoner og berikelsesskript for hver tjeneste.
Hver regel krevde sitt eget sett med inndata. Så, for å godkjenne et boliglån, beregnet vi kundens stjernetegn og koblet dette med logikken til månekalenderen. For å godkjenne et leketøy sjekket vi at klienten hadde nådd myndig alder, og for å utstede et lån sendte vi en forespørsel til en ekstern åpen tjeneste for å bestemme mobiloperatøren, og det ble tatt en beslutning om det.
Vi prøvde å gjøre demonstrasjonen vår interessant og interaktiv, alle tilstedeværende kunne gå til skjemaet vårt og sjekke tilgjengeligheten av våre fiktive tjenester for dem. Og helt på slutten av presentasjonen demonstrerte vi analyser av mottatte søknader, som viste hvor mange som brukte tjenesten vår, antall godkjenninger og avslag.
For å samle analyser på nettet, har vi i tillegg distribuert et åpen kildekode BI-verktøy og skrudde den til oppbevaringsenheten vår. Metabase lar deg bygge skjermer med analyser på dataene som interesserer oss; du trenger bare å registrere en tilkobling til databasen, velge tabeller (i vårt tilfelle, datainnsamlinger, siden vi brukte MongoDB), og spesifisere feltene som er av interesse for oss .
Som et resultat fikk vi en god prototype av en beslutningsplattform, og under demonstrasjonen kunne hver lytter personlig sjekke ytelsen. En interessant løsning, en ferdig prototype og en vellykket demonstrasjon gjorde at vi kunne vinne, til tross for sterk konkurranse fra andre lag. Jeg er sikker på at det også kan skrives en interessant artikkel om hvert teams prosjekt.
Kilde: www.habr.com