ProHoster > Blogs > interneta ziņas > Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā
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Ŕā raksts. 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 rakstÄ«ja: 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 IBM WebSphere ILOG JRules BRMS, 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:

  1. 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.
  2. Pēc izstrādāto vēsturisko datu noteikumu testÄ“Å”anas analÄ«tiÄ·is augÅ”upielādē savu kodu administratora panelÄ«.
  3. Lai nodroÅ”inātu versiju izveidi, viss kods tiks novirzÄ«ts uz Git krātuvēm.
  4. 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 labs raksts ar to aprakstu un salÄ«dzinoÅ”o analÄ«zi.

IzsvēruÅ”i visus plusus un mÄ«nusus, mēs izvēlējāmies SadalÄ«Å”anās. Å 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. Šajā ietvarā ieviesto vidi saraksts 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:

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā
Šī 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:

  1. 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ā.
  2. 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ē.
  3. 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:

  1. 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ē.
  2. Aizmugursistēmas administrators, ieskaitot REST API priekÅ”pusē un integrāciju ar VCS.
  3. InfrastruktÅ«ras iestatÄ«Å”ana pakalpojumā Google Cloud un pakalpojuma izstrāde avota datu bagātināŔanai.
  4. Modulis administratora lietojumprogrammas integrÄ“Å”anai bez servera ietvarā turpmākai noteikumu izvietoÅ”anai.
  5. 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:

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā
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.

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā
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 JGit bibliotēka, 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:

Kā mēs izveidojām mākoni FaaS Kubernetes iekÅ”ienē un uzvarējām Tinkoff hakatonā
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 Metabāze 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

Pievieno komentāru