Sākot ar pagājušo gadu, mūsu uzņēmums sāka organizēt hakatonus. Pirmais šāds konkurss bija ļoti veiksmīgs, par to rakstījām iekšā . Otrais hakatons notika 2019. gada februārī un bija ne mazāk veiksmīgs. Par pēdējo noturēšanas mērķiem ne tik sen organizators.
Dalībniekiem tika dots diezgan interesants uzdevums ar pilnīgu brīvību, izvēloties tehnoloģiju kaudzi tā īstenošanai. Bija nepieciešams ieviest lēmumu pieņemšanas platformu klientu vērtēšanas funkciju ērtai izvietošanai, kas varētu strādāt ar ātru lietojumprogrammu plūsmu, izturēt lielas slodzes, un pati sistēma bija viegli mērogojama.
Uzdevums nav triviāls un risināms dažādos veidos, par ko pārliecinājāmies dalībnieku projektu noslēguma prezentāciju demonstrēšanas laikā. Hakatonā piedalījās 6 komandas 5 cilvēku sastāvā, visiem dalībniekiem bija labi projekti, bet mūsu platforma izrādījās viskonkurētspējīgākā. Mums ir ļoti interesants projekts, par kuru es vēlētos runāt šajā rakstā.
Mūsu risinājums ir platforma, kuras pamatā ir Kubernetes arhitektūra bez serveriem, kas samazina laiku, kas nepieciešams jaunu līdzekļu ieviešanai ražošanā. Tas ļauj analītiķiem rakstīt kodu viņiem ērtā vidē un izvietot to ražošanā bez inženieru un izstrādātāju līdzdalības.
Kas ir punktu gūšana
Tinkoff.ru, tāpat kā daudziem mūsdienu uzņēmumiem, ir klientu vērtēšana. Vērtēšana ir klientu novērtēšanas sistēma, kuras pamatā ir datu analīzes statistiskās metodes.
Piemēram, klients vēršas pie mums ar lūgumu izsniegt viņam kredītu vai atvērt pie mums individuālā uzņēmēja kontu. Ja plānojam viņam izsniegt kredītu, tad jānovērtē viņa maksātspēja, savukārt, ja konts ir individuālajam uzņēmējam, tad jābūt pārliecinātiem, ka klients neveiks krāpnieciskus darījumus.
Šādu lēmumu pieņemšanas pamatā ir matemātiskie modeļi, kas analizē gan datus no pašas lietojumprogrammas, gan datus no mūsu krātuves. Papildus punktu noteikšanai līdzīgas statistikas metodes var izmantot arī individuālu ieteikumu ģenerēšanai mūsu klientiem jauniem produktiem.
Šāda novērtējuma metode var pieņemt dažādus ievades datus. Un kādā brīdī ievadei varam pievienot jaunu parametru, kas, balstoties uz vēsturisko datu analīzes rezultātiem, palielinās pakalpojuma izmantošanas reklāmguvumu līmeni.
Mūsu rīcībā ir daudz datu par attiecībām ar klientiem, un šīs informācijas apjoms nepārtraukti pieaug. Lai punktu noteikšana darbotos, datu apstrādei ir nepieciešami arī noteikumi (vai matemātiskie modeļi), kas ļauj ātri izlemt, kam apstiprināt pieteikumu, kuram atteikt un kuram piedāvāt vēl pāris produktus, izvērtējot to iespējamo interesi.
Veicot šo uzdevumu, mēs jau izmantojam specializētu lēmumu pieņemšanas sistēmu , kas, pamatojoties uz analītiķu, tehnologu un izstrādātāju noteiktajiem noteikumiem, izlemj, vai apstiprināt vai atteikt klientam konkrētu bankas produktu.
Tirgū ir daudz gatavu risinājumu, gan vērtēšanas modeļi, gan pašas lēmumu pieņemšanas sistēmas. Mēs savā uzņēmumā izmantojam vienu no šīm sistēmām. Taču bizness aug, dažādojas, pieaug gan klientu skaits, gan piedāvāto produktu skaits, un līdz ar to rodas idejas, kā uzlabot esošo lēmumu pieņemšanas procesu. Protams, cilvēkiem, kas strādā ar esošo sistēmu, ir daudz ideju, kā to padarīt vienkāršāku, labāku, ērtāku, taču dažreiz noder idejas no malas. Jaunais Hakatons tika rīkots ar mērķi apkopot skanīgas idejas.
Uzdevums
Hakatons notika 23. februārī. Dalībniekiem tika piedāvāts kaujas uzdevums: izstrādāt lēmumu pieņemšanas sistēmu, kurai bija jāatbilst vairākiem nosacījumiem.
Tika stāstīts, kā funkcionē esošā sistēma un kādas grūtības rodas tās darbības laikā, kā arī uz kādiem biznesa mērķiem būtu jātiecas izstrādātajai platformai. Sistēmai jābūt ātrai ieviešanai tirgū noteikumu izstrādei, lai analītiķu darba kods pēc iespējas ātrāk nonāktu ražošanā. Un attiecībā uz ienākošo pieteikumu plūsmu lēmumu pieņemšanas laikam vajadzētu būt minimālam. Tāpat izstrādātajai sistēmai ir jābūt savstarpējās pārdošanas iespējām, lai klientam būtu iespēja iegādāties citus uzņēmuma produktus, ja tie ir mūsu apstiprināti un tiem ir potenciāla klienta interese.
Skaidrs, ka vienas nakts laikā nav iespējams uzrakstīt izdošanai gatavu projektu, kas noteikti nonāks ražošanā, un ir diezgan grūti aptvert visu sistēmu, tāpēc mums tika lūgts ieviest vismaz daļu no tā. Tika noteiktas vairākas prasības, kurām prototipam jāatbilst. Varēja mēģināt gan aptvert visas prasības kopumā, gan detalizēti strādāt pie atsevišķām izstrādājamās platformas sadaļām.
Runājot par tehnoloģijām, visiem dalībniekiem tika dota pilnīga izvēles brīvība. Bija iespējams izmantot jebkādas koncepcijas un tehnoloģijas: datu straumēšana, mašīnmācīšanās, notikumu ieguve, lielie dati un citi.
Mūsu risinājums
Pēc nelielas prāta vētras nolēmām, ka FaaS risinājums būtu ideāls uzdevuma izpildei.
Šim risinājumam bija jāatrod piemērots bez serveru ietvars, lai ieviestu izstrādājamās lēmumu pieņemšanas sistēmas noteikumus. Tā kā Tinkoff aktīvi izmanto Kubernetes infrastruktūras pārvaldībai, mēs apskatījām vairākus gatavus risinājumus uz tā bāzes, par to pastāstīšu vēlāk.
Lai atrastu visefektīvāko risinājumu, mēs aplūkojām izstrādāto produktu ar tā lietotāju acīm. Galvenie mūsu sistēmas lietotāji ir noteikumu izstrādē iesaistīti analītiķi. Noteikumi ir jāizvieto serverī vai, kā mūsu gadījumā, jāizvieto mākonī turpmākai lēmumu pieņemšanai. No analītiķa viedokļa darbplūsma izskatās šādi:
- Analītiķis raksta skriptu, noteikumu vai ML modeli, pamatojoties uz datiem no noliktavas. Hakatona ietvaros nolēmām izmantot Mongodb, taču datu uzglabāšanas sistēmas izvēle šeit nav svarīga.
- Pēc izstrādāto vēsturisko datu noteikumu testēšanas analītiķis augšupielādē savu kodu administratora panelī.
- Lai nodrošinātu versiju izveidi, viss kods tiks novirzīts uz Git krātuvēm.
- Izmantojot administratora paneli, būs iespējams izvietot kodu mākonī kā atsevišķu funkcionālu bez servera moduli.
Sākotnējie dati no klientiem ir jānosūta caur specializētu bagātināšanas pakalpojumu, kas paredzēts, lai bagātinātu sākotnējo pieprasījumu ar datiem no noliktavas. Bija svarīgi šo pakalpojumu ieviest tā, lai tas darbotos ar vienu repozitoriju (no kura analītiķis ņem datus, izstrādājot noteikumus), lai uzturētu vienotu datu struktūru.
Pat pirms hakatona mēs izlēmām par bez servera sistēmu, kuru izmantosim. Mūsdienās tirgū ir diezgan daudz tehnoloģiju, kas īsteno šo pieeju. Populārākie risinājumi Kubernetes arhitektūrā ir Fission, Open FaaS un Kubeless. Ir pat .
Izsvēruši visus plusus un mīnusus, mēs izvēlējāmies . Šo bez serveru ietvaru ir diezgan viegli pārvaldīt un tas atbilst uzdevuma prasībām.
Lai strādātu ar Fission, jums ir jāsaprot divi pamatjēdzieni: funkcija un vide. Funkcija ir koda fragments, kas rakstīts vienā no valodām, kurai ir Fission vide. ietver Python, JS, Go, JVM un daudzas citas populāras valodas un tehnoloģijas.
Fission spēj veikt arī funkcijas, kas sadalītas vairākos failos, kas ir iepriekš iepakots arhīvā. Fission darbību Kubernetes klasterī nodrošina specializēti podi, kurus pārvalda pats ietvars. Lai mijiedarbotos ar klasteru podiem, katrai funkcijai ir jāpiešķir savs maršruts, kuram POST pieprasījuma gadījumā varat nodot GET parametrus vai pieprasījuma pamattekstu.
Rezultātā mēs plānojām iegūt risinājumu, kas ļautu analītiķiem izvietot izstrādātus noteikumu skriptus bez inženieru un izstrādātāju līdzdalības. Aprakstītā pieeja arī novērš nepieciešamību izstrādātājiem pārrakstīt analītiķa kodu citā valodā. Piemēram, pašreizējai lēmumu pieņemšanas sistēmai, kuru mēs izmantojam, noteikumi ir jāraksta ļoti specializētās tehnoloģijās un valodās, kuru darbības joma ir ārkārtīgi ierobežota, kā arī ir liela atkarība no lietojumprogrammu servera, jo visi bankas noteikumu projekti tiek izvietoti vienā vidē. Tā rezultātā, lai izvietotu jaunus noteikumus, ir jāatbrīvo visa sistēma.
Mūsu piedāvātajā risinājumā noteikumi nav jāatbrīvo; kodu var viegli izvietot, noklikšķinot uz pogas. Arī infrastruktūras pārvaldība Kubernetes ļauj nedomāt par slodzi un mērogošanu, šādas problēmas tiek atrisinātas no kastes. Un vienas datu noliktavas izmantošana novērš nepieciešamību salīdzināt reāllaika datus ar vēsturiskajiem datiem, kas vienkāršo analītiķa darbu.
Ko mēs saņēmām
Tā kā uz hakatonu ieradāmies ar jau gatavu risinājumu (fantāzijās), tad atlika tikai visas domas pārvērst koda rindās.
Panākumu atslēga jebkurā hakatonā ir sagatavošanās un labi uzrakstīts plāns. Tāpēc pirmais, ko mēs izdarījām, bija izlemt, no kādiem moduļiem sastāvēs mūsu sistēmas arhitektūra un kādas tehnoloģijas izmantosim.
Mūsu projekta arhitektūra bija šāda:
Šī diagramma parāda divus ieejas punktus, analītiķi (galveno mūsu sistēmas lietotāju) un klientu.
Darba process ir strukturēts šādi. Analītiķis savam modelim izstrādā noteikumu funkciju un datu bagātināšanas funkciju, saglabā savu kodu Git repozitorijā un izvieto savu modeli mākonī, izmantojot administratora lietojumprogrammu. Apsvērsim, kā tiks izsaukta izvietotā funkcija, un pieņemsim lēmumus par ienākošajiem pieprasījumiem no klientiem:
- Klients tīmekļa vietnē aizpilda veidlapu un nosūta savu pieprasījumu pārzinim. Pieteikums, par kuru jāpieņem lēmums, nonāk sistēmas ievadē un tiek ierakstīts datubāzē sākotnējā formā.
- Pēc tam neapstrādātais pieprasījums tiek nosūtīts bagātināšanai, ja nepieciešams. Sākotnējo pieprasījumu varat papildināt ar datiem gan no ārējiem pakalpojumiem, gan no krātuves. Rezultātā iegūtais bagātinātais vaicājums tiek saglabāts arī datu bāzē.
- Tiek palaista analītiķa funkcija, kas kā ievadi izmanto bagātinātu vaicājumu un rada risinājumu, kas arī tiek ierakstīts krātuvē.
Mēs nolēmām izmantot MongoDB kā krātuvi mūsu sistēmā, jo uz dokumentiem orientēta datu glabāšana JSON dokumentu veidā, jo bagātināšanas pakalpojumi, tostarp sākotnējais pieprasījums, visus datus apkopoja, izmantojot REST kontrolierus.
Tātad, mums bija XNUMX stundas, lai ieviestu platformu. Lomas sadalījām diezgan veiksmīgi, katram komandas dalībniekam mūsu projektā bija sava atbildības joma:
- Priekšgala administratora paneļi analītiķa darbam, ar kuru palīdzību viņš varēja lejupielādēt noteikumus no rakstīto skriptu versiju kontroles sistēmas, atlasīt ievades datu bagātināšanas opcijas un rediģēt noteikumu skriptus tiešsaistē.
- Aizmugursistēmas administrators, ieskaitot REST API priekšpusē un integrāciju ar VCS.
- Infrastruktūras iestatīšana pakalpojumā Google Cloud un pakalpojuma izstrāde avota datu bagātināšanai.
- Modulis administratora lietojumprogrammas integrēšanai bez servera ietvarā turpmākai noteikumu izvietošanai.
- Noteikumu skripti visas sistēmas veiktspējas pārbaudei un ienākošo lietojumprogrammu analītikas apkopošana (pieņemtie lēmumi) galīgajai demonstrācijai.
Sāksim kārtībā.
Mūsu priekšgals tika uzrakstīts Angular 7, izmantojot bankas lietotāja interfeisa komplektu. Administratora paneļa galīgā versija izskatījās šādi:
Tā kā laika bija maz, mēs centāmies ieviest tikai galveno funkcionalitāti. Lai izvietotu funkciju Kubernetes klasterī, bija jāizvēlas notikums (pakalpojums, kuram mākonī ir jāizvieto kārtula) un tās funkcijas kods, kas ievieš lēmumu pieņemšanas loģiku. Katrai kārtulas izvietošanai atlasītajam pakalpojumam mēs ierakstījām šī notikuma žurnālu. Administratora panelī var redzēt visu notikumu žurnālus.
Viss funkciju kods tika saglabāts attālā Git repozitorijā, kas arī bija jāiestata administratora panelī. Lai versētu kodu, visas funkcijas tika saglabātas dažādās repozitorija filiālēs. Administratora panelis nodrošina arī iespēju veikt korekcijas rakstītajos skriptos, lai pirms funkcijas izvietošanas ražošanā varētu ne tikai pārbaudīt rakstīto kodu, bet arī veikt nepieciešamās izmaiņas.
Papildus noteikumu funkcijām mēs ieviesām arī iespēju pakāpeniski bagātināt avota datus, izmantojot bagātināšanas funkcijas, kuru kods bija arī skripti, kuros bija iespējams doties uz datu noliktavu, izsaukt trešo pušu pakalpojumus un veikt sākotnējos aprēķinus. . Lai demonstrētu mūsu risinājumu, mēs aprēķinājām klienta zodiaka zīmi, kurš atstāja pieprasījumu, un noteicām viņa mobilo sakaru operatoru, izmantojot trešās puses REST pakalpojumu.
Platformas aizmugure tika uzrakstīta Java valodā un ieviesta kā Spring Boot lietojumprogramma. Sākotnēji plānojām izmantot Postgres, lai saglabātu administratora datus, taču hakatona ietvaros nolēmām aprobežoties ar vienkāršu H2, lai ietaupītu laiku. Aizmugursistēmā tika ieviesta integrācija ar Bitbucket, lai versētu vaicājumu bagātināšanas funkcijas un noteikumu skriptus. Integrācijai ar attāliem Git krātuvēm mēs izmantojām , kas ir sava veida CLI komandu iesaiņojums, kas ļauj izpildīt jebkuru git instrukciju, izmantojot ērtu programmatūras saskarni. Tāpēc mums bija divas atsevišķas bagātināšanas funkciju un noteikumu krātuves, un visi skripti tika sadalīti direktorijos. Izmantojot lietotāja interfeisu, bija iespējams atlasīt patvaļīgas repozitorija filiāles skripta jaunāko izpildi. Veicot izmaiņas kodā, izmantojot administratora paneli, mainītā koda saistības tika izveidotas attālās krātuvēs.
Lai īstenotu savu ideju, mums bija nepieciešama piemērota infrastruktūra. Mēs nolēmām izvietot mūsu Kubernetes klasteru mākonī. Mūsu izvēle bija Google Cloud Platform. Fission bez servera sistēma tika instalēta Kubernetes klasterī, kuru mēs izvietojām pakalpojumā Gcloud. Sākotnēji avota datu bagātināšanas pakalpojums tika ieviests kā atsevišķa Java lietojumprogramma, kas iesaiņota podā k8s klastera iekšpusē. Bet pēc mūsu projekta sākotnējās demonstrēšanas hakatona vidū mums tika ieteikts padarīt bagātināšanas pakalpojumu elastīgāku, lai nodrošinātu iespēju izvēlēties, kā bagātināt ienākošo lietojumprogrammu neapstrādātos datus. Un mums nebija citas izvēles, kā padarīt bagātināšanas pakalpojumu arī bez servera.
Lai strādātu ar Fission, mēs izmantojām Fission CLI, kas jāinstalē virs Kubernetes CLI. Funkciju izvietošana k8s klasterī ir diezgan vienkārša; jums vienkārši jāpiešķir funkcijai iekšējais maršruts un ieeja, lai atļautu ienākošo trafiku, ja ir nepieciešama piekļuve ārpus klastera. Vienas funkcijas izvietošana parasti aizņem ne vairāk kā 10 sekundes.
Projekta noslēguma prezentācija un kopsavilkums
Lai demonstrētu, kā darbojas mūsu sistēma, attālajā serverī esam ievietojuši vienkāršu veidlapu, kurā var iesniegt pieteikumu kādam no bankas produktiem. Lai pieprasītu, bija jāievada savi iniciāļi, dzimšanas datums un tālruņa numurs.
Dati no klienta veidlapas nonāca pārzinim, kas vienlaikus nosūtīja pieprasījumus par visiem pieejamajiem noteikumiem, iepriekš bagātinot datus atbilstoši norādītajiem nosacījumiem, un saglabāja tos kopējā krātuvē. Kopumā mēs izvietojām trīs funkcijas, kas pieņem lēmumus par ienākošajām lietojumprogrammām, un 4 datu bagātināšanas pakalpojumus. Pēc pieteikuma iesniegšanas klients saņēma mūsu lēmumu:
Papildus atteikumam vai apstiprināšanai klients saņēma arī citu produktu sarakstu, pieprasījumus, par kuriem nosūtījām paralēli. Tādā veidā mēs demonstrējām savstarpējās pārdošanas iespēju mūsu platformā.
Kopumā bija pieejami 3 fiktīvi bankas produkti:
- Kredīts.
- Rotaļlieta
- Hipotēka.
Demonstrācijas laikā mēs izvietojām sagatavotas funkcijas un bagātināšanas skriptus katram pakalpojumam.
Katrai kārtulai bija nepieciešama sava ievaddatu kopa. Tātad, lai apstiprinātu hipotēku, mēs aprēķinājām klienta zodiaka zīmi un saistījām to ar Mēness kalendāra loģiku. Rotaļlietas apstiprināšanai pārbaudījām, vai klients ir sasniedzis pilngadību, un kredīta izsniegšanai nosūtījām pieprasījumu ārējam atvērtajam dienestam mobilā operatora noteikšanai, un par to tika pieņemts lēmums.
Mēs centāmies savu demonstrāciju padarīt interesantu un interaktīvu, ikviens klātesošais varēja doties uz mūsu formu un pārbaudīt, vai viņiem ir pieejami mūsu izdomātie pakalpojumi. Un prezentācijas pašās beigās mēs demonstrējām saņemto pieteikumu analīzi, kas parādīja, cik cilvēku izmantojuši mūsu pakalpojumu, apstiprinājumu un atteikumu skaitu.
Lai tiešsaistē apkopotu analīzi, mēs papildus izvietojām atvērtā pirmkoda BI rīku un pieskrūvēja to mūsu uzglabāšanas vienībai. Metabāze ļauj jums izveidot ekrānus ar analīzi par datiem, kas mūs interesē; jums vienkārši jāreģistrē savienojums ar datu bāzi, jāatlasa tabulas (mūsu gadījumā datu kolekcijas, jo mēs izmantojām MongoDB) un jānorāda mūs interesējošie lauki. .
Rezultātā ieguvām labu lēmumu pieņemšanas platformas prototipu, un demonstrācijas laikā katrs klausītājs varēja personīgi pārbaudīt tās sniegumu. Interesants risinājums, gatavs prototips un veiksmīga demonstrācija ļāva mums uzvarēt, neskatoties uz spēcīgu konkurenci no citām komandām. Esmu pārliecināts, ka par katras komandas projektu var uzrakstīt arī interesantu rakstu.
Avots: www.habr.com