Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff

Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff
Gan ddechrau'r llynedd, dechreuodd ein cwmni drefnu hacathonau. Roedd y gystadleuaeth gyntaf o'r fath yn llwyddiannus iawn, fe ysgrifennon ni amdani yn Erthygl. Digwyddodd yr ail hacathon ym mis Chwefror 2019 ac nid oedd yn llai llwyddiannus. Ynglŷn â'r nodau o gynnal yr olaf ddim mor bell yn ôl ysgrifennodd trefnydd.

Rhoddwyd tasg eithaf diddorol i'r cyfranogwyr gyda rhyddid llwyr wrth ddewis pentwr technoleg ar gyfer ei weithredu. Roedd angen gweithredu llwyfan gwneud penderfyniadau ar gyfer defnydd cyfleus o swyddogaethau sgorio cwsmeriaid a allai weithio gyda llif cyflym o gymwysiadau, gwrthsefyll llwythi trwm, ac roedd y system ei hun yn hawdd i'w graddio.

Nid yw'r dasg yn ddibwys a gellir ei datrys mewn sawl ffordd, fel y cawsom ein hargyhoeddi yn ystod arddangosiad y cyflwyniadau terfynol o brosiectau'r cyfranogwyr. Roedd 6 thîm o 5 o bobl yn yr hacathon, roedd gan bob cyfranogwr brosiectau da, ond ein platfform ni oedd y mwyaf cystadleuol. Mae gennym brosiect diddorol iawn, yr hoffwn siarad amdano yn yr erthygl hon.

Mae ein datrysiad yn blatfform sy'n seiliedig ar bensaernïaeth Serverless y tu mewn i Kubernetes, sy'n lleihau'r amser y mae'n ei gymryd i ddod â nodweddion newydd i gynhyrchu. Mae'n caniatáu i ddadansoddwyr ysgrifennu cod mewn amgylchedd sy'n gyfleus iddynt a'i ddefnyddio i gynhyrchu heb gyfranogiad peirianwyr a datblygwyr.

Beth yw sgorio

Mae gan Tinkoff.ru, fel llawer o gwmnïau modern, sgorio cwsmeriaid. System asesu cwsmeriaid yw sgorio sy'n seiliedig ar ddulliau ystadegol o ddadansoddi data.

Er enghraifft, mae cleient yn troi atom ni gyda chais i roi benthyciad iddo, neu agor cyfrif entrepreneur unigol gyda ni. Os ydym yn bwriadu rhoi benthyciad iddo, yna mae angen i ni asesu ei ddiddyledrwydd, ac os yw'r cyfrif yn entrepreneur unigol, yna mae angen i ni fod yn siŵr na fydd y cleient yn cynnal trafodion twyllodrus.

Y sail ar gyfer gwneud penderfyniadau o'r fath yw modelau mathemategol sy'n dadansoddi'r data o'r cymhwysiad ei hun a'r data o'n storfa. Yn ogystal â sgorio, gellir defnyddio dulliau ystadegol tebyg hefyd yn y gwasanaeth o gynhyrchu argymhellion unigol ar gyfer cynhyrchion newydd i'n cleientiaid.

Gall dull asesiad o'r fath dderbyn amrywiaeth o ddata mewnbwn. Ac ar ryw adeg, gallwn ychwanegu paramedr newydd i'r mewnbwn, a fydd, yn seiliedig ar ganlyniadau'r dadansoddiad o ddata hanesyddol, yn cynyddu cyfradd trosi defnyddio'r gwasanaeth.

Mae gennym gyfoeth o ddata am berthnasoedd cwsmeriaid, ac mae maint y wybodaeth hon yn cynyddu'n gyson. Ar gyfer sgorio i weithio, mae prosesu data hefyd yn gofyn am reolau (neu fodelau mathemategol) sy'n eich galluogi i benderfynu'n gyflym pwy i gymeradwyo cais, pwy i'w wrthod, a phwy i gynnig cwpl mwy o gynhyrchion, gan asesu eu diddordeb posibl.

Ar gyfer y dasg dan sylw, rydym eisoes yn defnyddio system arbenigol o wneud penderfyniadau IBM WebSphere ILOG JRules BRMS, sydd, yn seiliedig ar y rheolau a osodwyd gan ddadansoddwyr, technolegwyr a datblygwyr, yn penderfynu a ddylid cymeradwyo neu wrthod cynnyrch bancio penodol i'r cleient.

Mae yna lawer o atebion parod ar y farchnad, yn fodelau sgorio a systemau gwneud penderfyniadau eu hunain. Rydym yn defnyddio un o'r systemau hyn yn ein cwmni. Ond mae'r busnes yn tyfu, yn arallgyfeirio, mae nifer y cleientiaid a nifer y cynhyrchion a gynigir yn cynyddu, ac ynghyd â hyn, mae syniadau'n dod i'r amlwg ar sut i wella'r broses bresennol o wneud penderfyniadau. Siawns nad oes gan bobl sy'n gweithio gyda'r system bresennol lawer o syniadau ar sut i'w gwneud yn symlach, yn well, yn fwy cyfleus, ond weithiau mae syniadau o'r tu allan yn ddefnyddiol. Trefnwyd yr Hackathon Newydd gyda’r nod o gasglu syniadau cadarn.

Tasg

Cynhaliwyd yr hacathon ar Chwefror 23. Cynigiwyd tasg ymladd i'r cyfranogwyr: datblygu system gwneud penderfyniadau a oedd yn gorfod bodloni nifer o amodau.

Dywedwyd wrthym sut mae'r system bresennol yn gweithio a pha anawsterau sy'n codi yn ystod ei gweithrediad, yn ogystal â pha nodau busnes y dylai'r platfform datblygedig eu dilyn. Rhaid i'r system gael amser cyflym i'r farchnad ar gyfer datblygu rheolau fel bod cod gweithio dadansoddwyr yn dechrau cynhyrchu cyn gynted â phosibl. Ac ar gyfer y llif ceisiadau sy'n dod i mewn, dylai'r amser gwneud penderfyniadau fod mor isel â phosibl. Hefyd, mae'n rhaid i'r system sy'n cael ei datblygu feddu ar alluoedd traws-werthu er mwyn rhoi cyfle i'r cleient brynu cynhyrchion cwmni eraill os ydynt wedi'u cymeradwyo gennym ni a bod ganddynt ddiddordeb posibl gan y cleient.

Mae’n amlwg ei bod yn amhosibl ysgrifennu prosiect parod i’w ryddhau dros nos a fydd yn sicr yn mynd i mewn i gynhyrchu, ac mae’n eithaf anodd cwmpasu’r system gyfan, felly gofynnwyd inni weithredu o leiaf rhan ohoni. Sefydlwyd nifer o ofynion y mae'n rhaid i'r prototeip eu bodloni. Roedd modd ceisio’r ddau i gwmpasu’r holl ofynion yn eu cyfanrwydd, a gweithio’n fanwl ar adrannau unigol o’r platfform oedd yn cael ei ddatblygu.

O ran technoleg, rhoddwyd rhyddid llwyr i'r holl gyfranogwyr ddewis. Roedd yn bosibl defnyddio unrhyw gysyniadau a thechnolegau: Ffrydio data, dysgu peiriannau, cyrchu digwyddiadau, data mawr ac eraill.

Ein datrysiad

Ar ôl ychydig o drafod syniadau, fe wnaethom benderfynu y byddai datrysiad FaaS yn ddelfrydol ar gyfer cwblhau'r dasg.

Ar gyfer yr ateb hwn, roedd angen dod o hyd i fframwaith Serverless addas i weithredu rheolau'r system gwneud penderfyniadau oedd yn cael ei datblygu. Gan fod Tinkoff yn defnyddio Kubernetes yn weithredol ar gyfer rheoli seilwaith, buom yn edrych ar nifer o atebion parod yn seiliedig arno; byddaf yn dweud mwy wrthych amdano yn nes ymlaen.

I ddod o hyd i'r ateb mwyaf effeithiol, fe wnaethom edrych ar y cynnyrch sy'n cael ei ddatblygu trwy lygaid ei ddefnyddwyr. Prif ddefnyddwyr ein system yw dadansoddwyr sy'n ymwneud â datblygu rheolau. Rhaid defnyddio'r rheolau i'r gweinydd, neu, fel yn ein hachos ni, eu defnyddio yn y cwmwl, ar gyfer gwneud penderfyniadau dilynol. O safbwynt dadansoddwr, mae'r llif gwaith yn edrych fel hyn:

  1. Mae'r dadansoddwr yn ysgrifennu sgript, rheol, neu fodel ML yn seiliedig ar ddata o'r warws. Fel rhan o'r hacathon, fe benderfynon ni ddefnyddio Mongodb, ond nid yw'r dewis o system storio data yn bwysig yma.
  2. Ar ôl profi'r rheolau datblygedig ar ddata hanesyddol, mae'r dadansoddwr yn uwchlwytho ei god i'r panel gweinyddol.
  3. Er mwyn sicrhau fersiwn, bydd yr holl god yn mynd i ystorfeydd Git.
  4. Trwy'r panel gweinyddol bydd yn bosibl defnyddio'r cod yn y cwmwl fel modiwl Serverless swyddogaethol ar wahân.

Rhaid i ddata cychwynnol gan gleientiaid basio trwy wasanaeth Cyfoethogi arbenigol sydd wedi'i gynllunio i gyfoethogi'r cais cychwynnol gyda data o'r warws. Roedd yn bwysig gweithredu'r gwasanaeth hwn yn y fath fodd fel y byddai'n gweithio gydag un storfa (y mae'r dadansoddwr yn cymryd data ohoni wrth ddatblygu rheolau) i gynnal strwythur data unedig.

Hyd yn oed cyn yr hacathon, fe wnaethom benderfynu ar y fframwaith Serverless y byddem yn ei ddefnyddio. Heddiw mae yna lawer iawn o dechnolegau ar y farchnad sy'n gweithredu'r dull hwn. Yr atebion mwyaf poblogaidd o fewn pensaernïaeth Kubernetes yw Fission, Open FaaS a Kubeless. Mae hyd yn oed erthygl dda gyda'u disgrifiad a'u dadansoddiad cymharol.

Ar ôl pwyso a mesur yr holl fanteision ac anfanteision, fe wnaethon ni ddewis Ymholltiad. Mae'r fframwaith Gweinyddwr hwn yn eithaf hawdd i'w reoli ac mae'n bodloni gofynion y dasg.

I weithio gyda Ymholltiad, mae angen i chi ddeall dau gysyniad sylfaenol: swyddogaeth ac amgylchedd. Mae ffwythiant yn ddarn o god a ysgrifennwyd yn un o'r ieithoedd y mae amgylchedd Ymholltiad ar eu cyfer. Rhestr o amgylcheddau a weithredir o fewn y fframwaith hwn yn cynnwys Python, JS, Go, JVM a llawer o ieithoedd a thechnolegau poblogaidd eraill.

Mae Ymholltiad hefyd yn gallu cyflawni swyddogaethau wedi'u rhannu'n sawl ffeil, wedi'u rhag-becynnu i mewn i archif. Sicrheir gweithrediad Ymholltiad mewn clwstwr Kubernetes gan godennau arbenigol, a reolir gan y fframwaith ei hun. Er mwyn rhyngweithio â chodau clwstwr, rhaid neilltuo llwybr ei hun i bob swyddogaeth, a gallwch basio paramedrau GET neu gorff gwneud cais iddo yn achos cais POST.

O ganlyniad, roeddem yn bwriadu cael ateb a fyddai'n caniatáu i ddadansoddwyr ddefnyddio sgriptiau rheolau datblygedig heb gyfranogiad peirianwyr a datblygwyr. Mae'r dull a ddisgrifir hefyd yn dileu'r angen i ddatblygwyr ailysgrifennu cod dadansoddwyr i iaith arall. Er enghraifft, ar gyfer y system gwneud penderfyniadau gyfredol a ddefnyddiwn, mae'n rhaid i ni ysgrifennu rheolau mewn technolegau ac ieithoedd hynod arbenigol, y mae eu cwmpas yn gyfyngedig iawn, ac mae dibyniaeth gref hefyd ar weinydd y cais, gan fod yr holl reolau banc drafft yn cael eu defnyddio mewn un amgylchedd. O ganlyniad, i ddefnyddio rheolau newydd mae angen rhyddhau'r system gyfan.

Yn ein datrysiad arfaethedig, nid oes angen rhyddhau rheolau; gellir defnyddio'r cod yn hawdd trwy glicio botwm. Hefyd, mae rheoli seilwaith yn Kubernetes yn caniatáu ichi beidio â meddwl am lwyth a graddio; mae problemau o'r fath yn cael eu datrys allan o'r bocs. Ac mae defnyddio un warws data yn dileu'r angen i gymharu data amser real â data hanesyddol, sy'n symleiddio gwaith y dadansoddwr.

Yr hyn a gawsom

Ers i ni ddod at yr hacathon gyda datrysiad parod (yn ein ffantasïau), y cyfan oedd yn rhaid i ni ei wneud oedd trosi ein holl feddyliau yn llinellau o god.

Yr allwedd i lwyddiant mewn unrhyw hacathon yw paratoi a chynllun wedi'i ysgrifennu'n dda. Felly, y peth cyntaf a wnaethom oedd penderfynu pa fodiwlau y byddai ein pensaernïaeth system yn eu cynnwys a pha dechnolegau y byddem yn eu defnyddio.

Roedd pensaernïaeth ein prosiect fel a ganlyn:

Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff
Mae'r diagram hwn yn dangos dau bwynt mynediad, y dadansoddwr (prif ddefnyddiwr ein system) a'r cleient.

Mae'r broses waith wedi'i strwythuro fel hyn. Mae'r dadansoddwr yn datblygu swyddogaeth rheol a swyddogaeth cyfoethogi data ar gyfer ei fodel, yn storio ei god mewn ystorfa Git, ac yn defnyddio ei fodel i'r cwmwl trwy'r cymhwysiad gweinyddwr. Gadewch i ni ystyried sut y bydd y swyddogaeth a ddefnyddir yn cael ei galw a gwneud penderfyniadau ar geisiadau sy'n dod i mewn gan gleientiaid:

  1. Mae'r cleient yn llenwi ffurflen ar y wefan ac yn anfon ei gais at y rheolwr. Mae cais y mae angen gwneud penderfyniad yn ei gylch yn dod i fewnbwn y system ac yn cael ei gofnodi yn y gronfa ddata yn ei ffurf wreiddiol.
  2. Nesaf, anfonir y cais amrwd am gyfoethogi, os oes angen. Gallwch ategu'r cais cychwynnol gyda data o wasanaethau allanol ac o'r storfa. Mae'r ymholiad cyfoethog o ganlyniad hefyd yn cael ei storio yn y gronfa ddata.
  3. Mae swyddogaeth y dadansoddwr yn cael ei lansio, sy'n cymryd ymholiad cyfoethog fel mewnbwn ac yn cynhyrchu datrysiad, sydd hefyd wedi'i ysgrifennu i'r storfa.

Fe wnaethom benderfynu defnyddio MongoDB fel storfa yn ein system oherwydd storio data yn seiliedig ar ddogfen ar ffurf dogfennau JSON, gan fod y gwasanaethau cyfoethogi, gan gynnwys y cais gwreiddiol, wedi agregu'r holl ddata trwy reolwyr REST.

Felly, roedd gennym ni XNUMX awr i weithredu'r platfform. Fe wnaethom ddosbarthu’r rolau yn eithaf llwyddiannus; roedd gan bob aelod o’r tîm ei faes cyfrifoldeb ei hun yn ein prosiect:

  1. Paneli gweinyddol pen blaen ar gyfer gwaith y dadansoddwr, lle gallai lawrlwytho rheolau o'r system rheoli fersiwn o sgriptiau ysgrifenedig, dewis opsiynau ar gyfer cyfoethogi data mewnbwn a golygu sgriptiau rheolau ar-lein.
  2. Gweinyddwr ôl-gefn, gan gynnwys API REST ar gyfer y tu blaen ac integreiddio â VCS.
  3. Sefydlu seilwaith yn Google Cloud a datblygu gwasanaeth ar gyfer cyfoethogi data ffynhonnell.
  4. Modiwl ar gyfer integreiddio'r rhaglen weinyddol â'r fframwaith Serverless ar gyfer defnyddio rheolau wedyn.
  5. Sgriptiau o reolau ar gyfer profi perfformiad y system gyfan a chydgrynhoi dadansoddeg ar geisiadau sy'n dod i mewn (penderfyniadau wedi'u gwneud) ar gyfer yr arddangosiad terfynol.

Gadewch i ni ddechrau mewn trefn.

Ysgrifennwyd ein frontend yn Angular 7 gan ddefnyddio'r Pecyn UI bancio. Roedd fersiwn derfynol y panel gweinyddol yn edrych fel hyn:

Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff
Gan nad oedd llawer o amser, fe wnaethom geisio gweithredu'r swyddogaeth allweddol yn unig. Er mwyn defnyddio swyddogaeth yng nghlwstwr Kubernetes, roedd angen dewis digwyddiad (gwasanaeth y mae angen defnyddio rheol ar ei gyfer yn y cwmwl) a chod y swyddogaeth sy'n gweithredu'r rhesymeg gwneud penderfyniadau. Ar gyfer pob defnydd o reol ar gyfer y gwasanaeth a ddewiswyd, fe wnaethom ysgrifennu log o'r digwyddiad hwn. Yn y panel gweinyddol fe allech chi weld logiau o'r holl ddigwyddiadau.

Roedd yr holl god swyddogaeth yn cael ei storio mewn ystorfa Git o bell, yr oedd yn rhaid ei osod yn y panel gweinyddol hefyd. I fersiwn y cod, roedd yr holl swyddogaethau'n cael eu storio mewn gwahanol ganghennau o'r ystorfa. Mae'r panel gweinyddol hefyd yn darparu'r gallu i wneud addasiadau i sgriptiau ysgrifenedig, fel y gallwch nid yn unig wirio'r cod ysgrifenedig, ond hefyd wneud y newidiadau angenrheidiol cyn defnyddio swyddogaeth i gynhyrchu.

Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff
Yn ogystal â'r swyddogaethau rheolau, fe wnaethom hefyd weithredu'r gallu i gyfoethogi'r data ffynhonnell yn raddol gan ddefnyddio swyddogaethau Cyfoethogi, yr oedd y cod hefyd yn sgriptiau lle'r oedd yn bosibl mynd i'r warws data, ffonio gwasanaethau trydydd parti a gwneud cyfrifiadau rhagarweiniol. . I ddangos ein datrysiad, fe wnaethom gyfrifo arwydd Sidydd y cleient a adawodd y cais a phenderfynu ar ei weithredwr symudol gan ddefnyddio gwasanaeth REST trydydd parti.

Ysgrifennwyd cefn y platfform yn Java a'i weithredu fel cymhwysiad Spring Boot. I ddechrau, roeddem yn bwriadu defnyddio Postgres i storio data gweinyddol, ond, fel rhan o'r hacathon, fe benderfynon ni gyfyngu ein hunain i H2 syml er mwyn arbed amser. Ar y cefn, gweithredwyd integreiddio â Bitbucket i fersiwn y swyddogaethau cyfoethogi ymholiad a sgriptiau rheolau. Ar gyfer integreiddio â storfeydd Git anghysbell, fe wnaethom ddefnyddio llyfrgell JGit, sy'n fath o lapio dros orchmynion CLI, sy'n eich galluogi i weithredu unrhyw gyfarwyddiadau git gan ddefnyddio rhyngwyneb meddalwedd cyfleus. Felly roedd gennym ddwy storfa ar wahân ar gyfer swyddogaethau a rheolau cyfoethogi, a rhannwyd yr holl sgriptiau yn gyfeiriaduron. Trwy'r UI roedd yn bosibl dewis yr ymrwymiad diweddaraf o sgript cangen fympwyol o'r gadwrfa. Wrth wneud newidiadau i'r cod trwy'r panel gweinyddol, crëwyd ymrwymiadau o'r cod wedi'i newid mewn cadwrfeydd anghysbell.

Er mwyn gweithredu ein syniad, roedd angen seilwaith addas arnom. Fe benderfynon ni ddefnyddio ein clwstwr Kubernetes yn y cwmwl. Ein dewis ni oedd Google Cloud Platform. Gosodwyd y fframwaith di-weinydd Fission ar glwstwr Kubernetes, a ddefnyddiwyd gennym yn Gcloud. I ddechrau, gweithredwyd y gwasanaeth cyfoethogi data ffynhonnell fel cymhwysiad Java ar wahân wedi'i lapio mewn Pod y tu mewn i'r clwstwr k8s. Ond ar ôl arddangosiad rhagarweiniol o'n prosiect yng nghanol yr hacathon, fe'n hargymhellwyd i wneud y gwasanaeth Cyfoethogi yn fwy hyblyg i roi'r cyfle i ddewis sut i gyfoethogi data crai ceisiadau sy'n dod i mewn. Ac nid oedd gennym unrhyw ddewis ond i wneud y gwasanaeth cyfoethogi hefyd Serverless.

I weithio gyda Ymholltiad, fe wnaethom ddefnyddio'r Fission CLI, y mae'n rhaid ei osod ar ben y Kubernetes CLI. Mae defnyddio swyddogaethau i glwstwr k8s yn eithaf syml; does ond angen i chi neilltuo llwybr mewnol a mynediad i'r swyddogaeth i ganiatáu traffig sy'n dod i mewn os oes angen mynediad y tu allan i'r clwstwr. Fel arfer nid yw defnyddio un swyddogaeth yn cymryd mwy na 10 eiliad.

Cyflwyniad terfynol y prosiect a chrynhoi

I ddangos sut mae ein system yn gweithio, rydym wedi gosod ffurflen syml ar weinydd pell lle gallwch gyflwyno cais am un o gynhyrchion y banc. I wneud cais, roedd yn rhaid i chi nodi eich llythrennau blaen, dyddiad geni a rhif ffôn.

Aeth data o'r ffurflen cleient i'r rheolwr, a anfonodd geisiadau am yr holl reolau sydd ar gael ar yr un pryd, ar ôl cyfoethogi'r data yn flaenorol yn unol â'r amodau penodedig, a'u cadw mewn storfa gyffredin. Yn gyfan gwbl, fe wnaethom ddefnyddio tair swyddogaeth sy'n gwneud penderfyniadau ar geisiadau sy'n dod i mewn a 4 gwasanaeth cyfoethogi data. Ar ôl cyflwyno'r cais, derbyniodd y cleient ein penderfyniad:

Sut wnaethon ni wneud cwmwl FaaS y tu mewn i Kubernetes ac ennill yr hacathon Tinkoff
Yn ogystal â gwrthod neu gymeradwyo, mae'r cleient hefyd yn derbyn rhestr o gynhyrchion eraill, ceisiadau a anfonwyd gennym ochr yn ochr. Dyma sut y gwnaethom ddangos y posibilrwydd o groes-werthu yn ein platfform.

Roedd cyfanswm o 3 chynnyrch banc ffug ar gael:

  • Credyd.
  • Tegan
  • Morgais.

Yn ystod yr arddangosiad, fe wnaethom ddefnyddio swyddogaethau parod a sgriptiau cyfoethogi ar gyfer pob gwasanaeth.

Roedd pob rheol yn gofyn am ei set ei hun o ddata mewnbwn. Felly, i gymeradwyo morgais, fe wnaethom gyfrifo arwydd Sidydd y cleient a chysylltu hyn â rhesymeg y calendr lleuad. I gymeradwyo tegan, gwnaethom wirio bod y cleient wedi cyrraedd oedran y mwyafrif, ac i roi benthyciad, anfonwyd cais at wasanaeth agored allanol i bennu'r gweithredwr cellog, a gwnaed penderfyniad arno.

Fe wnaethom geisio gwneud ein harddangosiad yn ddiddorol ac yn rhyngweithiol, gallai pawb a oedd yn bresennol fynd i'n ffurflen a gwirio argaeledd ein gwasanaethau ffuglen iddynt. Ac ar ddiwedd y cyflwyniad, fe wnaethom ddangos dadansoddiadau o geisiadau a dderbyniwyd, a oedd yn dangos faint o bobl a ddefnyddiodd ein gwasanaeth, nifer y cymeradwyaethau, a gwrthodiadau.

I gasglu dadansoddeg ar-lein, fe wnaethom hefyd ddefnyddio offeryn BI ffynhonnell agored Metabas a'i sgriwio i'n huned storio. Mae Metabase yn caniatáu ichi adeiladu sgriniau gyda dadansoddeg ar y data sydd o ddiddordeb i ni; does ond angen i chi gofrestru cysylltiad â'r gronfa ddata, dewis tablau (yn ein hachos ni, casgliadau data, ers i ni ddefnyddio MongoDB), a nodi'r meysydd sydd o ddiddordeb i ni .

O ganlyniad, cawsom brototeip da o lwyfan gwneud penderfyniadau, ac yn ystod yr arddangosiad, gallai pob gwrandäwr wirio ei berfformiad yn bersonol. Roedd datrysiad diddorol, prototeip gorffenedig ac arddangosiad llwyddiannus yn ein galluogi i ennill, er gwaethaf cystadleuaeth gref gan dimau eraill. Rwy’n siŵr y gellir ysgrifennu erthygl ddiddorol hefyd ar brosiect pob tîm.

Ffynhonnell: hab.com

Ychwanegu sylw