Alates eelmisest aastast hakkas meie ettevõte korraldama häkatone. Esimene selline konkurss oli väga edukas, kirjutasime sellest aastal . Teine häkaton toimus 2019. aasta veebruaris ja ei olnud vähem edukas. Viimase pidamise eesmärkidest mitte väga ammu korraldaja.
Osalejad said üsnagi huvitava ülesande täieliku vabadusega selle teostamiseks tehnoloogilise virna valikul. Klientide hindamisfunktsioonide mugavaks juurutamiseks oli vaja juurutada otsustusplatvorm, mis võiks töötada kiire rakenduste vooga, taluda suuri koormusi ja süsteem ise oli kergesti skaleeritav.
Ülesanne on mittetriviaalne ja seda saab lahendada mitmel viisil, nagu veendusime osalejate projektide lõpuettekannete demonstreerimisel. Häkatonil oli 6 5-liikmelist võistkonda, kõigil osalejatel olid head projektid, kuid meie platvorm osutus kõige konkurentsitihedamaks. Meil on väga huvitav projekt, millest tahaksin selles artiklis rääkida.
Meie lahendus on Kubernetese serverita arhitektuuril põhinev platvorm, mis vähendab uute funktsioonide tootmisse toomiseks kuluvat aega. See võimaldab analüütikutel kirjutada koodi neile sobivas keskkonnas ja juurutada see tootmisse ilma inseneride ja arendajate osaluseta.
Mis on punktiarvestus
Tinkoff.ru-l, nagu paljudel kaasaegsetel ettevõtetel, on klientide hindamine. Scoring on statistilistel andmete analüüsi meetoditel põhinev kliendi hindamissüsteem.
Näiteks pöördub klient meie poole sooviga anda talle laen või avada meie juures üksikettevõtja konto. Kui plaanime talle laenu väljastada, siis peame hindama tema maksevõimet ja kui konto on eraettevõtja, siis peame olema kindlad, et klient ei tee petturlikke tehinguid.
Selliste otsuste tegemise aluseks on matemaatilised mudelid, mis analüüsivad nii rakenduse enda kui ka meie salvestusruumi andmeid. Lisaks punktiarvestusele saab sarnaseid statistilisi meetodeid kasutada ka meie klientidele uute toodete individuaalsete soovituste genereerimisel.
Sellise hindamise meetod võib aktsepteerida mitmesuguseid sisendandmeid. Ja ühel hetkel saame sisendisse lisada uue parameetri, mis ajalooliste andmete analüüsi tulemuste põhjal tõstab teenuse kasutamise konversioonimäära.
Meil on palju andmeid kliendisuhete kohta ja selle teabe maht kasvab pidevalt. Hindade andmise toimimiseks on vaja ka andmetöötlust reegleid (või matemaatilisi mudeleid), mis võimaldavad kiiresti otsustada, kellele taotlus rahuldada, kellele keelduda ja kellele veel paar toodet pakkuda, hinnates nende potentsiaalset huvi.
Käsitletava ülesande jaoks kasutame juba spetsiaalset otsustussüsteemi , mis analüütikute, tehnoloogide ja arendajate seatud reeglite alusel otsustab, kas kliendile konkreetne pangatoode kinnitada või sellest keelduda.
Turul on palju valmislahendusi, nii hindamismudeleid kui ka otsustussüsteeme ise. Kasutame oma ettevõttes üht neist süsteemidest. Aga äri kasvab, mitmekesistab, suureneb nii klientide arv kui ka pakutavate toodete hulk ning koos sellega tekivad ideed, kuidas olemasolevat otsustusprotsessi paremaks muuta. Kindlasti on olemasoleva süsteemiga töötavatel inimestel palju ideid, kuidas seda lihtsamaks, paremaks, mugavamaks muuta, kuid mõnikord tulevad väljastpoolt tulnud ideed kasuks. New Hackathon korraldati eesmärgiga koguda kõlavaid ideid.
Ülesanne
Häkaton peeti 23. veebruaril. Osalejatele pakuti lahinguülesannet: töötada välja otsustussüsteem, mis pidi vastama mitmetele tingimustele.
Meile räägiti, kuidas olemasolev süsteem toimib ja millised raskused selle toimimise käigus tekivad ning milliseid ärilisi eesmärke arendatav platvorm peaks taotlema. Reeglite väljatöötamiseks peab süsteemil olema kiire turuletulekuaeg, et analüütikute töökoodeks jõuaks võimalikult kiiresti tootmisse. Ja sissetuleva taotlusvoo jaoks peaks otsustusaeg olema minimaalne. Samuti peab arendataval süsteemil olema ristmüügi võimalused, et anda kliendile võimalus osta teisi ettevõtte tooteid, kui need on meie poolt heaks kiidetud ja kliendi poolt potentsiaalselt huvitatud.
Selge on see, et üleöö on võimatu kirjutada väljalaskmisvalmis projekti, mis kindlasti tootmisse läheb, ja kogu süsteemi katta on üsna keeruline, seega paluti meil vähemalt osa sellest ellu viia. Kehtestati rida nõudeid, millele prototüüp peab vastama. Proovida sai nii kõiki nõudeid tervikuna katta kui ka arendatava platvormi üksikute osade kallal üksikasjalikult töötada.
Mis puutub tehnoloogiasse, siis kõigile osalejatele anti täielik valikuvabadus. Kasutada oli võimalik mis tahes kontseptsioone ja tehnoloogiaid: andmete voogedastus, masinõpe, sündmuste hankimine, suurandmed ja muud.
Meie lahendus
Pärast väikest ajurünnakut otsustasime, et ülesande täitmiseks sobiks ideaalselt FaaS-i lahendus.
Selle lahenduse jaoks oli vaja leida sobiv Serverless raamistik arendatava otsustussüsteemi reeglite rakendamiseks. Kuna Tinkoff kasutab Kubernetest aktiivselt infrastruktuuri haldamiseks, siis vaatasime selle põhjal mitmeid valmislahendusi, millest räägin lähemalt hiljem.
Kõige tõhusama lahenduse leidmiseks vaatasime arendatavat toodet selle kasutajate pilgu läbi. Meie süsteemi peamised kasutajad on reeglite väljatöötamisega seotud analüütikud. Reeglid tuleb järgnevate otsuste tegemiseks juurutada serverisse või, nagu meie puhul, pilves. Analüütiku vaatenurgast näeb töövoog välja järgmine:
- Analüütik kirjutab laost saadud andmete põhjal skripti, reegli või ML-mudeli. Häkatoni raames otsustasime kasutada Mongodbi, kuid andmesalvestussüsteemi valik pole siinkohal oluline.
- Pärast väljatöötatud reeglite testimist ajalooliste andmete põhjal laadib analüütik oma koodi administraatoripaneelile.
- Versioonide loomise tagamiseks suunatakse kogu kood Giti hoidlatesse.
- Administraatori paneeli kaudu on võimalik koodi pilves juurutada eraldi funktsionaalse serverita moodulina.
Klientide algandmed peavad läbima spetsiaalse rikastusteenuse, mis on loodud esialgse päringu rikastamiseks laost pärinevate andmetega. Oluline oli selle teenuse juurutamine selliselt, et see töötaks ühtse andmestruktuuri säilitamiseks ühe hoidlaga (kust analüütik reeglite väljatöötamisel andmeid võtab).
Juba enne häkatoni otsustasime serverita raamistiku kasuks, mida kasutame. Tänapäeval on turul üsna palju tehnoloogiaid, mis seda lähenemisviisi rakendavad. Kubernetese arhitektuuri populaarseimad lahendused on Fission, Open FaaS ja Kubeless. Neid on isegi .
Pärast kõigi plusside ja miinuste kaalumist tegime valiku . Seda serverita raamistikku on üsna lihtne hallata ja see vastab ülesande nõuetele.
Fissioniga töötamiseks peate mõistma kahte põhimõistet: funktsioon ja keskkond. Funktsioon on koodijupp, mis on kirjutatud ühes keeles, mille jaoks on olemas Fissioni keskkond. sisaldab Pythoni, JS-i, Go, JVM-i ja paljusid teisi populaarseid keeli ja tehnoloogiaid.
Fission on võimeline täitma ka funktsioone, mis on jagatud mitmeks failiks, mis on eelpakendatud arhiivi. Fissioni toimimise Kubernetese klastris tagavad spetsiaalsed kaunad, mida haldab raamistik ise. Klastripoodidega suhtlemiseks tuleb igale funktsioonile määrata oma marsruut ja millele saate POST-päringu korral edastada GET-i parameetrid või päringu keha.
Selle tulemusena plaanisime hankida lahenduse, mis võimaldaks analüütikutel juurutada väljatöötatud reegliskripte ilma inseneride ja arendajate osaluseta. Kirjeldatud lähenemine välistab ka vajaduse, et arendajad kirjutaksid analüütiku koodi teise keelde ümber. Näiteks praeguse otsustussüsteemi jaoks, mida me kasutame, peame reeglid kirjutama väga spetsiifilistes tehnoloogiates ja keeltes, mille ulatus on äärmiselt piiratud ning samuti on suur sõltuvus rakendusserverist, kuna kõik pangareeglite kavandid on kasutusele võetud ühes keskkonnas. Selle tulemusena on uute reeglite juurutamiseks vaja vabastada kogu süsteem.
Meie pakutud lahenduses ei ole vaja reegleid vabastada, koodi saab hõlpsasti juurutada ühe nupuvajutusega. Samuti võimaldab Kubernetese infrastruktuuri haldamine mitte mõelda koormusele ja skaleerimisele; sellised probleemid lahendatakse karbist välja. Ja ühe andmelao kasutamine välistab vajaduse võrrelda reaalajas andmeid ajalooliste andmetega, mis lihtsustab analüütiku tööd.
Mida me saime
Kuna tulime häkatonile valmis lahendusega (oma fantaasiates), siis ei jäänudki muud üle, kui kõik oma mõtted koodiridadeks konverteerida.
Edu võti igal häkatonil on ettevalmistus ja hästi kirjutatud plaan. Seetõttu otsustasime esimese asjana, millistest moodulitest meie süsteemi arhitektuur koosneb ja milliseid tehnoloogiaid kasutame.
Meie projekti arhitektuur oli järgmine:
Sellel diagrammil on kaks sisenemispunkti, analüütik (meie süsteemi peamine kasutaja) ja klient.
Tööprotsess on üles ehitatud nii. Analüütik töötab oma mudeli jaoks välja reeglifunktsiooni ja andmete rikastamise funktsiooni, salvestab oma koodi Giti hoidlasse ja juurutab oma mudeli administraatorirakenduse kaudu pilve. Mõelgem, kuidas juurutatud funktsiooni kutsutakse, ja teeme otsuseid klientidelt saabuvate päringute kohta:
- Klient täidab veebilehel ankeedi ja saadab oma päringu vastutavale töötlejale. Rakendus, mille kohta tuleb teha otsus, tuleb süsteemi sisendisse ja salvestatakse andmebaasi algsel kujul.
- Järgmisena saadetakse toortaotlus vajadusel rikastamiseks. Esialgset päringut saate täiendada nii välisteenuste kui ka salvestusruumi andmetega. Saadud rikastatud päring salvestatakse samuti andmebaasi.
- Käivitatakse analüütiku funktsioon, mis võtab sisendiks rikastatud päringu ja toodab lahenduse, mis kirjutatakse ka salvestusruumi.
Otsustasime kasutada oma süsteemis salvestusruumina MongoDB-d JSON-dokumentide vormis andmete dokumendipõhise salvestamise tõttu, kuna rikastamisteenused, sealhulgas algne päring, koondasid kõik andmed REST-kontrollerite kaudu.
Seega oli meil platvormi juurutamiseks aega XNUMX tundi. Rollid jaotasime üsna edukalt, igal meeskonnaliikmel oli meie projektis oma vastutusala:
- Analüütiku töö jaoks mõeldud esiotsa administraatoripaneelid, mille kaudu sai ta kirjalike skriptide versioonikontrollisüsteemist reegleid alla laadida, valida sisendandmete rikastamise võimalusi ja reegliskripte veebis redigeerida.
- Taustaprogrammi administraator, sealhulgas REST API esikülje jaoks ja integreerimine VCS-iga.
- Google Cloudi infrastruktuuri seadistamine ja lähteandmete rikastamise teenuse arendamine.
- Moodul administraatorirakenduse integreerimiseks serverita raamistikuga reeglite hilisemaks juurutamiseks.
- Reeglite skriptid kogu süsteemi jõudluse testimiseks ja analüütika koondamine sissetulevate rakenduste kohta (tehtud otsused) lõplikuks demonstratsiooniks.
Alustame järjekorras.
Meie kasutajaliides on kirjutatud Angular 7-s, kasutades pangandusliidese komplekti. Administraatoripaneeli lõplik versioon nägi välja selline:
Kuna aega oli vähe, proovisime rakendada ainult võtmefunktsioone. Funktsiooni juurutamiseks Kubernetese klastris oli vaja valida sündmus (teenus, mille jaoks reegel tuleb pilves juurutada) ja funktsiooni kood, mis rakendab otsustusloogikat. Iga valitud teenuse reegli juurutamise kohta kirjutasime selle sündmuse logi. Administraatoripaneelil näete kõigi sündmuste logisid.
Kogu funktsioonikood salvestati Giti kaughoidlasse, mis tuli samuti administraatori paneelil seadistada. Koodi versioonimiseks salvestati kõik funktsioonid hoidla erinevatesse harudesse. Administraatoripaneel annab ka võimaluse kohandada kirjutatud skripte, nii et enne funktsiooni juurutamist tootmisse saate mitte ainult kontrollida kirjutatud koodi, vaid teha ka vajalikud muudatused.
Lisaks reeglite funktsioonidele juurutasime ka võimaluse lähteandmeid järk-järgult rikastada rikastusfunktsioonide abil, mille koodiks olid ka skriptid, milles oli võimalik minna andmelattu, helistada kolmandate osapoolte teenustele ja teha eelarvutusi. . Oma lahenduse demonstreerimiseks arvutasime taotlusest lahkunud kliendi sodiaagimärgi ja määrasime kolmanda osapoole REST-teenuse abil kindlaks tema mobiilioperaatori.
Platvormi taustaprogramm kirjutati Java keeles ja rakendati Spring Boot rakendusena. Algselt plaanisime kasutada Postgresi administraatoriandmete salvestamiseks, kuid häkatoni raames otsustasime aja säästmiseks piirduda lihtsa H2-ga. Taustaprogrammis rakendati päringu rikastamise funktsioonide ja reegliskriptide versioonide muutmiseks integreerimist Bitbucketiga. Integreerimiseks Giti kaughoidlatega kasutasime , mis on omamoodi CLI-käskude ümbris, mis võimaldab teil mugava tarkvaraliidese abil täita mis tahes git-käske. Seega oli meil rikastamisfunktsioonide ja reeglite jaoks kaks eraldi hoidlat ning kõik skriptid olid jagatud kataloogidesse. Kasutajaliidese kaudu oli võimalik valida hoidla suvalise haru skripti uusim kinnistamine. Koodi muutmisel administraatori paneeli kaudu loodi muudetud koodi sissekanded kaughoidlates.
Oma idee elluviimiseks vajasime sobivat infrastruktuuri. Otsustasime oma Kubernetese klastri pilves juurutada. Meie valik oli Google Cloud Platform. Fissioni serverita raamistik installiti Kubernetese klastrisse, mille juurutasime Gcloudis. Algselt rakendati lähteandmete rikastamise teenust eraldi Java-rakendusena, mis oli pakitud k8s-klastri sisemusse. Kuid pärast meie projekti esialgset tutvustamist häkatoni keskel soovitati meil muuta rikastamise teenus paindlikumaks, et anda võimalus valida, kuidas sissetulevate rakenduste algandmeid rikastada. Ja meil ei jäänud muud üle, kui muuta rikastamisteenus ka serverivabaks.
Fissioniga töötamiseks kasutasime Fission CLI-d, mis tuleb installida Kubernetes CLI peale. Funktsioonide juurutamine k8s-klastrisse on üsna lihtne; peate lihtsalt määrama funktsioonile sisemise marsruudi ja sissepääsu, et lubada sissetulevat liiklust, kui on vaja juurdepääsu väljaspool klastrit. Ühe funktsiooni juurutamine ei võta tavaliselt rohkem kui 10 sekundit.
Projekti lõppesitlus ja kokkuvõtted
Meie süsteemi toimimise demonstreerimiseks oleme paigutanud kaugserverisse lihtsa ankeedi, kuhu saate esitada taotluse mõne panga toote kasutamiseks. Taotlemiseks tuli sisestada oma initsiaalid, sünniaeg ja telefoninumber.
Kliendivormi andmed läksid vastutavale töötlejale, kes saatis samaaegselt päringud kõikide saadaolevate reeglite kohta, olles eelnevalt andmeid vastavalt määratud tingimustele rikastanud ja salvestas need ühisesse salvestusruumi. Kokku juurutasime kolm funktsiooni, mis teevad otsuseid sissetulevate rakenduste kohta, ja 4 andmerikastusteenust. Pärast avalduse esitamist sai klient meie otsuse:
Lisaks keeldumisele või heakskiitmisele sai klient ka nimekirja muudest toodetest, mille päringud saatsime paralleelselt. Nii demonstreerisime oma platvormil ristmüügi võimalust.
Kokku oli saadaval 3 fiktiivset pangatoodet:
- Krediit.
- Mänguasja
- Hüpoteek.
Demonstratsiooni käigus juurutasime iga teenuse jaoks ettevalmistatud funktsioonid ja rikastusskriptid.
Iga reegel nõudis oma sisendandmete komplekti. Seega arvutasime hüpoteegi kinnitamiseks välja kliendi sodiaagimärgi ja ühendasime selle kuukalendri loogikaga. Mänguasja kinnitamiseks kontrollisime kliendi täisealiseks saamist ning laenu väljastamiseks saatsime välisele avatud teenusele päringu mobiilsideoperaatori määramiseks ja selle kohta tehti otsus.
Püüdsime muuta oma meeleavalduse huvitavaks ja interaktiivseks, kõik kohalviibijad said minna meie ankeeti ja kontrollida, kas meie väljamõeldud teenused on neile kättesaadavad. Ja päris esitluse lõpus demonstreerisime laekunud taotluste analüüsi, mis näitas, kui palju inimesi meie teenust kasutas, kui palju oli kinnitusi ja keeldumisi.
Analüütika veebis kogumiseks juurutasime lisaks avatud lähtekoodiga BI-tööriista ja keeras selle meie hoiuruumi külge. Metabase võimaldab koostada analüütikaga ekraane meile huvipakkuvatest andmetest; tuleb lihtsalt registreerida ühendus andmebaasiga, valida tabelid (meie puhul andmekogud, kuna kasutasime MongoDB-d) ja täpsustada meid huvitavad väljad. .
Selle tulemusena saime hea otsustusplatvormi prototüübi ning demonstratsiooni käigus sai iga kuulaja isiklikult selle esitust kontrollida. Huvitav lahendus, valmis prototüüp ja edukas demonstratsioon võimaldasid meil võita vaatamata tugevale konkurentsile teiste tiimide poolt. Olen kindel, et iga meeskonna projekti kohta saab kirjutada ka huvitava artikli.
Allikas: www.habr.com