Nuo praėjusių metų mūsų įmonė pradėjo organizuoti hakatonus. Pirmasis toks konkursas buvo labai sėkmingas, apie tai rašėme m . Antrasis hakatonas vyko 2019 metų vasarį ir buvo ne mažiau sėkmingas. Apie pastarojo laikymo tikslus ne taip seniai organizatorius.
Dalyviai gavo gana įdomią užduotį su visiška laisve pasirenkant technologijų krūvą jos įgyvendinimui. Reikėjo įdiegti sprendimų priėmimo platformą, skirtą patogiai diegti klientų balų skaičiavimo funkcijas, kurios galėtų dirbti su greitu programų srautu, atlaikytų dideles apkrovas, o pati sistema būtų lengvai keičiama.
Užduotis yra nebanali ir gali būti išspręsta įvairiai, tuo įsitikinome demonstruodami galutinius dalyvių projektų pristatymus. Hakatone dalyvavo 6 komandos po 5 žmones, visi dalyviai turėjo gerų projektų, tačiau mūsų platforma pasirodė pati konkurencingiausia. Turime labai įdomų projektą, apie kurį norėčiau pakalbėti šiame straipsnyje.
Mūsų sprendimas yra platforma, pagrįsta Kubernetes be serverių architektūra, kuri sumažina laiką, kurio reikia naujoms funkcijoms pristatyti į gamybą. Tai leidžia analitikams parašyti kodą jiems patogioje aplinkoje ir diegti jį gamyboje nedalyvaujant inžinieriams ir kūrėjams.
Kas yra taškais
Tinkoff.ru, kaip ir daugelis šiuolaikinių įmonių, turi klientų įvertinimą. Taškais – tai klientų vertinimo sistema, pagrįsta statistiniais duomenų analizės metodais.
Pavyzdžiui, klientas kreipiasi į mus su prašymu išduoti jam paskolą arba pas mus atsidaryti individualaus verslininko sąskaitą. Jei planuojame jam išduoti paskolą, turime įvertinti jo mokumą, o jei sąskaita yra individualus verslininkas, turime būti tikri, kad klientas nedarys nesąžiningų operacijų.
Tokių sprendimų priėmimo pagrindas yra matematiniai modeliai, analizuojantys duomenis iš pačios programos ir duomenis iš mūsų saugyklos. Be balų skaičiavimo, panašūs statistiniai metodai taip pat gali būti naudojami teikiant individualias rekomendacijas naujiems produktams mūsų klientams.
Tokio vertinimo metodas gali priimti įvairius įvesties duomenis. Ir tam tikru momentu galime pridėti naują parametrą į įvestį, kuris, remiantis istorinių duomenų analizės rezultatais, padidins naudojimosi paslauga konversijos koeficientą.
Turime daugybę duomenų apie santykius su klientais, o šios informacijos kiekis nuolat auga. Kad balų skaičiavimas veiktų, duomenų apdorojimui taip pat reikalingos taisyklės (arba matematiniai modeliai), leidžiančios greitai nuspręsti, kam patvirtinti paraišką, kam atsisakyti, o kam pasiūlyti dar porą produktų, įvertinant galimą jų susidomėjimą.
Atlikdami šią užduotį jau naudojame specializuotą sprendimų priėmimo sistemą , kuri, remdamasi analitikų, technologų ir kūrėjų nustatytomis taisyklėmis, sprendžia, patvirtinti ar atsisakyti konkretaus banko produkto klientui.
Rinkoje yra daug paruoštų sprendimų – tiek balų skaičiavimo modelių, tiek pačių sprendimų priėmimo sistemų. Savo įmonėje naudojame vieną iš šių sistemų. Bet verslas auga, įvairėja, daugėja tiek klientų, tiek siūlomų produktų, o kartu su tuo kyla ir idėjos, kaip pagerinti esamą sprendimų priėmimo procesą. Tikrai žmonės, dirbantys su esama sistema, turi daug idėjų, kaip ją padaryti paprasčiau, geriau, patogiau, tačiau kartais idėjos iš išorės praverčia. Naujasis hakatonas buvo organizuojamas siekiant surinkti skambių idėjų.
Užduotis
Hakatonas vyko vasario 23 d. Dalyviams buvo pasiūlyta kovinė užduotis: sukurti sprendimų priėmimo sistemą, kuri turėjo atitikti daugybę sąlygų.
Buvo pasakyta, kaip veikia esama sistema ir kokie sunkumai iškyla ją eksploatuojant, kokių verslo tikslų turėtų siekti sukurta platforma. Sistema turi turėti greitą pateikimo į rinką laiką, kad būtų parengtos taisyklės, kad analitikų darbo kodas būtų kuo greičiau pradėtas gaminti. O gaunamų paraiškų srautui sprendimų priėmimo laikas turėtų būti minimalus. Taip pat kuriama sistema turi turėti kryžminio pardavimo galimybes, kad suteiktų klientui galimybę įsigyti kitų įmonės produktų, jeigu jie mūsų patvirtinti ir sulauktų potencialaus kliento susidomėjimo.
Akivaizdu, kad per naktį parašyti paruošto spaudai projekto, kuris tikrai bus pradėtas gaminti, neįmanoma, o aprėpti visą sistemą gana sunku, tad buvome paprašyti bent dalį jo įgyvendinti. Buvo nustatyta keletas reikalavimų, kuriuos prototipas turi atitikti. Buvo galima pabandyti ir visapusiškai aprėpti visus reikalavimus, ir detaliai dirbti prie atskirų kuriamos platformos skyrių.
Kalbant apie technologijas, visiems dalyviams buvo suteikta visiška pasirinkimo laisvė. Buvo galima naudoti bet kokias sąvokas ir technologijas: duomenų srautinį perdavimą, mašininį mokymąsi, įvykių šaltinį, didelius duomenis ir kt.
Mūsų sprendimas
Šiek tiek apmąstę nusprendėme, kad FaaS sprendimas būtų idealus užduočiai atlikti.
Šiam sprendimui reikėjo rasti tinkamą be serverio sistemą, kuri įgyvendintų kuriamos sprendimų priėmimo sistemos taisykles. Kadangi Tinkoff aktyviai naudoja Kubernetes infrastruktūros valdymui, mes peržiūrėjome keletą paruoštų sprendimų, pagrįstų juo; apie tai daugiau papasakosiu vėliau.
Norėdami rasti efektyviausią sprendimą, į kuriamą produktą žiūrėjome jo vartotojų akimis. Pagrindiniai mūsų sistemos vartotojai yra analitikai, dalyvaujantys taisyklių kūrime. Taisyklės turi būti įdiegtos serveryje arba, kaip mūsų atveju, įdiegtos debesyje, kad vėliau būtų galima priimti sprendimus. Analitiko požiūriu darbo eiga atrodo taip:
- Analitikas rašo scenarijų, taisyklę arba ML modelį pagal duomenis iš sandėlio. Vykdydami hakatoną nusprendėme naudoti Mongodb, tačiau duomenų saugojimo sistemos pasirinkimas čia nėra svarbus.
- Išbandęs sukurtas taisykles dėl istorinių duomenų, analitikas įkelia savo kodą į administratoriaus skydelį.
- Siekiant užtikrinti versijų nustatymą, visas kodas pateks į „Git“ saugyklas.
- Per administratoriaus skydelį bus galima įdiegti kodą debesyje kaip atskirą funkcinį modulį be serverio.
Pradiniai klientų duomenys turi būti perduoti per specializuotą praturtinimo paslaugą, skirtą praturtinti pradinę užklausą duomenimis iš sandėlio. Šią paslaugą buvo svarbu įdiegti taip, kad ji veiktų su viena saugykla (iš kurios analitikas ima duomenis kurdamas taisykles), kad būtų išlaikyta vieninga duomenų struktūra.
Dar prieš hakatoną nusprendėme naudoti be serverio sistemą. Šiandien rinkoje yra gana daug technologijų, kurios įgyvendina šį metodą. Populiariausi Kubernetes architektūros sprendimai yra Fission, Open FaaS ir Kubeless. Yra net .
Pasvėrę visus už ir prieš, pasirinkome . Šią be serverio sistemą yra gana lengva valdyti ir ji atitinka užduoties reikalavimus.
Norėdami dirbti su Fission, turite suprasti dvi pagrindines sąvokas: funkciją ir aplinką. Funkcija yra kodo dalis, parašyta viena iš kalbų, kurioms yra dalijimosi aplinka. apima Python, JS, Go, JVM ir daugelį kitų populiarių kalbų ir technologijų.
Fission taip pat gali atlikti funkcijas, suskirstytas į keletą failų, iš anksto supakuotų į archyvą. Fission veikimą Kubernetes klasteryje užtikrina specializuotos ankštys, kurias valdo pati sistema. Norint sąveikauti su klasterių grupėmis, kiekvienai funkcijai turi būti priskirtas atskiras maršrutas, kuriam POST užklausos atveju galite perduoti GET parametrus arba užklausos turinį.
Dėl to planavome gauti sprendimą, kuris leistų analitikams diegti sukurtus taisyklių scenarijus nedalyvaujant inžinieriams ir kūrėjams. Aprašytas metodas taip pat pašalina poreikį kūrėjams perrašyti analitiko kodą į kitą kalbą. Pavyzdžiui, dabartinei sprendimų priėmimo sistemai, kurią naudojame, taisykles turime rašyti labai specializuotomis technologijomis ir kalbomis, kurių apimtis yra labai ribota, be to, yra didelė priklausomybė nuo programų serverio, nes visi banko taisyklių projektai yra diegiamos vienoje aplinkoje. Dėl to, norint įdiegti naujas taisykles, būtina išleisti visą sistemą.
Mūsų siūlomame sprendime nereikia išleisti taisyklių, kodą galima lengvai įdiegti vienu mygtuko paspaudimu. Be to, infrastruktūros valdymas Kubernetes leidžia negalvoti apie apkrovą ir mastelio keitimą, tokios problemos išsprendžiamos iš karto. O naudojant vieną duomenų saugyklą, nebereikia lyginti realaus laiko duomenų su istoriniais duomenimis, o tai supaprastina analitiko darbą.
Ką gavome
Kadangi į hakatoną atėjome su jau paruoštu sprendimu (savo fantazijose), beliko visas mintis konvertuoti į kodo eilutes.
Raktas į sėkmę bet kuriame hakatone yra pasiruošimas ir gerai parašytas planas. Todėl pirmiausia nusprendėme, iš kokių modulių sudarys mūsų sistemos architektūra ir kokias technologijas naudosime.
Mūsų projekto architektūra buvo tokia:
Šioje diagramoje pavaizduoti du įėjimo taškai – analitikas (pagrindinis mūsų sistemos vartotojas) ir klientas.
Darbo procesas struktūrizuotas taip. Analitikas sukuria savo modelio taisyklės funkciją ir duomenų praturtinimo funkciją, išsaugo savo kodą „Git“ saugykloje ir per administratoriaus programą diegia savo modelį debesyje. Apsvarstykime, kaip bus iškviesta įdiegta funkcija, ir priimkime sprendimus dėl gaunamų klientų užklausų:
- Klientas svetainėje užpildo formą ir išsiunčia savo prašymą duomenų valdytojui. Paraiška, dėl kurios reikia priimti sprendimą, ateina į sistemos įvestį ir įrašoma į duomenų bazę pradine forma.
- Tada, jei reikia, siunčiamas neapdorotas prašymas praturtinti. Pradinę užklausą galite papildyti duomenimis tiek iš išorinių paslaugų, tiek iš saugyklos. Gauta praturtinta užklausa taip pat saugoma duomenų bazėje.
- Paleidžiama analitiko funkcija, kuri kaip įvestį priima patobulintą užklausą ir sukuria sprendimą, kuris taip pat įrašomas į saugyklą.
„MongoDB“ nusprendėme naudoti kaip saugyklą savo sistemoje dėl į dokumentus orientuoto duomenų saugojimo JSON dokumentų pavidalu, nes praturtinimo paslaugos, įskaitant pradinę užklausą, apibendrino visus duomenis per REST valdiklius.
Taigi platformai įdiegti turėjome XNUMX valandas. Vaidmenis pasiskirstėme gana sėkmingai, kiekvienas komandos narys mūsų projekte turėjo savo atsakomybės sritį:
- Analitiko darbui skirtos priekinės admin panelės, per kurias jis galėjo atsisiųsti taisykles iš rašytinių scenarijų versijų valdymo sistemos, pasirinkti įvesties duomenų praturtinimo parinktis ir redaguoti taisyklių scenarijus internete.
- Užpakalinės dalies administratorius, įskaitant REST API priekyje ir integraciją su VCS.
- „Google Cloud“ infrastruktūros nustatymas ir šaltinio duomenų praturtinimo paslaugos kūrimas.
- Modulis, skirtas integruoti administratoriaus programą su sistema be serverio, kad būtų galima įdiegti taisykles.
- Taisyklių scenarijus, skirtas visos sistemos veikimui tikrinti ir gaunamų programų analizės (priimtų sprendimų) agregavimas galutiniam demonstravimui.
Pradėkime nuo eilės.
Mūsų sąsaja buvo parašyta „Angular 7“, naudojant banko vartotojo sąsajos rinkinį. Galutinė administratoriaus skydelio versija atrodė taip:
Kadangi laiko buvo mažai, stengėmės įdiegti tik pagrindinį funkcionalumą. Norint įdiegti funkciją Kubernetes klasteryje, reikėjo pasirinkti įvykį (paslaugą, kuriai debesyje reikia įdiegti taisyklę) ir funkcijos, kuri įgyvendina sprendimų priėmimo logiką, kodą. Kiekvienam pasirinktos paslaugos taisyklės diegimui rašėme šio įvykio žurnalą. Administratoriaus skydelyje galite matyti visų įvykių žurnalus.
Visas funkcijų kodas buvo saugomas nuotolinėje „Git“ saugykloje, kurią taip pat reikėjo nustatyti administratoriaus skydelyje. Norint versti kodą, visos funkcijos buvo saugomos skirtingose saugyklos šakose. Administratoriaus skydelyje taip pat yra galimybė koreguoti parašytus scenarijus, kad prieš diegdami funkciją gamybinėje versijoje galėtumėte ne tik patikrinti parašytą kodą, bet ir atlikti reikiamus pakeitimus.
Be taisyklių funkcijų, taip pat įdiegėme galimybę laipsniškai praturtinti šaltinio duomenis naudojant praturtinimo funkcijas, kurių kodas taip pat buvo scenarijai, kuriuose buvo galima patekti į duomenų saugyklą, skambinti trečiųjų šalių tarnyboms ir atlikti preliminarius skaičiavimus. . Norėdami pademonstruoti savo sprendimą, apskaičiavome užklausą palikusio kliento zodiako ženklą ir nustatėme jo mobiliojo ryšio operatorių naudodamiesi trečiosios šalies REST paslauga.
Platformos užpakalinė dalis buvo parašyta „Java“ ir įdiegta kaip „Spring Boot“ programa. Iš pradžių planavome naudoti „Postgres“ administratoriaus duomenims saugoti, bet kaip „hackathon“ dalį nusprendėme apsiriboti paprastu H2, kad sutaupytume laiko. Užklausos praturtinimo funkcijų ir taisyklių scenarijų versijavimui buvo įdiegta integracija su „Bitbucket“. Integracijai su nuotolinėmis Git saugyklomis naudojome , kuris yra savotiškas CLI komandų apvyniojimas, leidžiantis vykdyti bet kokias git instrukcijas naudojant patogią programinės įrangos sąsają. Taigi mes turėjome dvi atskiras saugyklas, skirtas praturtinimo funkcijoms ir taisyklėms, o visi scenarijai buvo suskirstyti į katalogus. Per vartotojo sąsają buvo galima pasirinkti naujausią savavališkos saugyklos šakos scenarijaus įvykdymą. Atliekant kodo pakeitimus per administratoriaus skydelį, pakeisto kodo įsipareigojimai buvo sukurti nuotolinėse saugyklose.
Mūsų idėjai įgyvendinti reikėjo tinkamos infrastruktūros. Nusprendėme savo Kubernetes klasterį įdiegti debesyje. Mūsų pasirinkimas buvo „Google Cloud Platform“. „Fission“ be serverio sistema buvo įdiegta „Kubernetes“ klasteryje, kurį įdiegėme „Gcloud“. Iš pradžių šaltinio duomenų praturtinimo paslauga buvo įdiegta kaip atskira Java programa, supakuota į podelį k8s klasterio viduje. Tačiau po išankstinio mūsų projekto demonstravimo hakatono viduryje mums buvo rekomenduota padaryti praturtinimo paslaugą lankstesnę, kad būtų suteikta galimybė pasirinkti, kaip praturtinti gaunamų programų neapdorotus duomenis. Ir mes neturėjome kito pasirinkimo, kaip paversti sodrinimo paslaugą taip pat be serverio.
Norėdami dirbti su Fission, naudojome Fission CLI, kuris turi būti įdiegtas ant Kubernetes CLI. Funkcijų diegimas k8s klasteryje yra gana paprastas; jums tereikia priskirti vidinį maršrutą ir įėjimą į funkciją, kad būtų galima leisti įeinantį srautą, jei reikia prieigos už klasterio ribų. Vienos funkcijos įdiegimas paprastai trunka ne ilgiau kaip 10 sekundžių.
Galutinis projekto pristatymas ir apibendrinimas
Norėdami parodyti, kaip veikia mūsų sistema, nuotoliniame serveryje įdėjome paprastą formą, kurioje galite pateikti paraišką vienam iš banko produktų. Norėdami paprašyti, turėjote įvesti savo inicialus, gimimo datą ir telefono numerį.
Duomenys iš kliento formos pateko į valdytoją, kuris vienu metu išsiuntė užklausas dėl visų galimų taisyklių, prieš tai papildęs duomenis pagal nurodytas sąlygas ir išsaugojęs bendroje saugykloje. Iš viso įdiegėme tris funkcijas, kurios priima sprendimus dėl gaunamų programų, ir 4 duomenų praturtinimo paslaugas. Pateikęs prašymą, klientas gavo mūsų sprendimą:
Be atsisakymo ar patvirtinimo, klientas gavo ir kitų produktų sąrašą, prašymus dėl kurių siuntėme lygiagrečiai. Taip savo platformoje pademonstravome kryžminio pardavimo galimybę.
Iš viso buvo 3 fiktyvūs banko produktai:
- Kreditas.
- Žaislas
- Hipoteka.
Demonstravimo metu kiekvienai paslaugai įdiegėme paruoštas funkcijas ir praturtinimo scenarijus.
Kiekvienai taisyklei reikėjo savo įvesties duomenų rinkinio. Taigi, norėdami patvirtinti būsto paskolą, mes apskaičiavome kliento zodiako ženklą ir susiejome tai su mėnulio kalendoriaus logika. Norėdami patvirtinti žaislą, patikrinome, ar klientas yra sulaukęs pilnametystės, o paskolai išduoti išsiuntėme užklausą išorinei atvirai tarnybai dėl korinio ryšio operatoriaus nustatymo ir dėl to buvo priimtas sprendimas.
Stengėmės, kad mūsų demonstracija būtų įdomi ir interaktyvi, visi susirinkę galėjo eiti į mūsų formą ir pasitikrinti, ar jiems prieinamos mūsų išgalvotos paslaugos. O pačioje pristatymo pabaigoje demonstravome gautų paraiškų analizę, kuri parodė, kiek žmonių pasinaudojo mūsų paslauga, kiek patvirtinimų, atsisakymų.
Norėdami rinkti analizę internete, papildomai įdiegėme atvirojo kodo BI įrankį ir prisukite jį prie mūsų saugyklos. Metabazė leidžia kurti ekranus su analitika apie mus dominančius duomenis, tereikia užregistruoti ryšį su duomenų baze, pasirinkti lenteles (mūsų atveju duomenų rinkinius, nes naudojome MongoDB) ir nurodyti mus dominančius laukus. .
Dėl to gavome gerą sprendimų priėmimo platformos prototipą, o demonstravimo metu kiekvienas klausytojas galėjo asmeniškai pasitikrinti jos atlikimą. Įdomus sprendimas, baigtas prototipas ir sėkmingas demonstravimas leido mums laimėti, nepaisant stiprios kitų komandų konkurencijos. Esu tikras, kad apie kiekvienos komandos projektą taip pat galima parašyti įdomų straipsnį.
Šaltinis: www.habr.com