Data­bricks ja Lake­house ‑ark­ki­teh­tuu­ri

Mikä on Databricks?

Data­bricks on yhdys­val­ta­lai­nen pil­vi­poh­jai­nen Apac­he Spar­kiin perus­tu­va hajau­te­tun las­ken­nan ja avoi­men läh­de­koo­din data- ja ana­ly­tiik­ka-alus­ta, jon­ka tuo­tos­ta mark­ki­noi­daan Data Lake­house Plat­form ‑nimel­lä. Data­bricks Data Lake­house Plat­for­min voi­daan aja­tel­la ole­van datain­si­nöö­rin, data­tie­tei­li­jän ja BI-ana­lyy­ti­kon yhtei­nen työ­ka­lu­pak­ki, joka tar­jo­aa kai­ken tar­peel­li­sen data­rat­kai­su­jen raken­ta­mi­seen, jal­kaut­ta­mi­seen, jaka­mi­seen ja yllä­pi­toon aina sup­peis­ta, pis­te­mäi­sis­tä data­tar­peis­ta mit­ta­viin, kon­ser­ni­ta­son toteu­tuk­siin asti. Suh­teel­li­ses­ti par­haim­mil­laan Data­bricks onkin juu­ri iso­jen data­mas­so­jen kans­sa työs­ken­nel­täes­sä, sil­lä työ­ka­lun taus­ta on Big Data ‑maa­il­mas­sa. Data­bricks on saa­ta­vil­la Azu­res­sa, AWS:ssä sekä Google Clou­dis­sa, se integroi­tuu vali­tun pil­vi­pal­ve­lun­tar­joa­jan tie­don tal­len­nus [toim. huom. ”sto­ra­ge”] — ja tie­to­tur­va-ark­ki­teh­tuu­riin sekä hal­lin­noi tar­vit­ta­vaa infra­struk­tuu­ria käyt­tä­jän puo­les­ta. Luon­nol­li­ses­ti git-ver­sion­hal­lin­ta ja muut ohjel­mis­to­ke­hi­tyk­sen par­haat käy­tän­nöt ovat Data­brick­sin puo­les­ta tuettuja.

Kone­pel­lin alla Data­bricks siis nojau­tuu hajau­tet­tuun, rin­nak­kai­seen las­ken­taan, jon­ka moot­to­ri­na toi­mii Apac­he Spark. Täs­sä käyt­tä­jä mää­rit­tää mil­lai­sil­la klus­te­reil­la las­ken­taa halu­taan teh­dä ja Data­bricks hank­kii tar­vit­ta­vat koneet käyt­tä­jän puo­les­ta, käyn­nis­tää ne joko tar­vit­taes­sa tai ennal­ta mää­rä­tyn aika­tau­lun mukaan sekä sam­mut­taa, kun klus­te­ria ei enää tar­vi­ta. Pro­ses­soi­ta­va data taas on tal­le­tet­tu­na pil­ves­sä, esim. Azu­re Data Lake Sto­ra­ge Gen2:ssa tai AWS S3:ssa, jol­loin hin­ta­lap­pua muo­dos­tet­taes­sa yksi­nään suu­ri datan mää­rä tai tar­vit­tu las­ken­ta­te­ho ei sane­le koko hin­ta­lap­pua, vaan nämä kak­si osa-aluet­ta skaa­lau­tu­vat toi­sis­taan erillään.

Miten Data­brick­sil­lä kehi­te­tään ja jul­kais­taan dataa?

Dataa pro­ses­soi­taes­sa pro­ses­soi­ta­va yksik­kö on tyy­pil­li­ses­ti Spark Data­fra­me, joka vas­taa löy­häs­ti rin­nas­taen tie­to­kan­ta­tau­lua, jon­ka hal­lin­ta tapah­tuu Spark-moot­to­rin toi­mes­ta. Data­fra­men käsit­te­ly tapah­tuu klus­te­rin muis­tis­sa, ja sitä mani­pu­loi­daan joko Pyt­ho­nil­la, Sca­lal­la, R:llä tai SQL:llä datan pro­ses­soin­ti­put­kis­sa. Put­kien kehi­tys tapah­tuu Data­bricks Note­boo­keis­sa, jot­ka koos­tu­vat yhdes­tä tai useam­mas­ta peräk­käin ajet­ta­vas­ta komen­to­so­lus­ta. Yhteen komen­to­so­luun kir­joi­te­taan koo­di (esim. Pyt­hon-funk­tio tai Spark Data­fra­men muo­dos­ta­va SQL-kyse­ly), ja yhdes­sä Note­boo­kis­sa voi­daan käyt­tää yhtä tai useam­paa eri ohjel­moin­ti- tai kyse­ly­kiel­tä. Yleen­sä yksi datan pro­ses­soin­ti­put­ki koos­tuu useam­mas­ta peräk­käin ajet­ta­vas­ta Note­boo­kis­ta, jois­ta kukin kes­kit­tyy vain tie­tyn­lai­seen pro­ses­soin­tiin; esim. raa­ka­da­tan puh­dis­tus, avain­ten luon­ti tai dimen­sio­naa­li­sen mal­lin lataus. Kun­kin pro­ses­soin­ti­put­ken lop­pu­tuo­tos tal­len­ne­taan pil­veen tyy­pil­li­se­ti Del­ta Lake ‑for­maa­tis­sa, joka on nyky­päi­vä­nä data lake ‑ana­ly­tii­kas­sa de fac­to ‑rat­kai­su. Kehi­tys onkin tek­ni­ses­ti var­sin suo­ra­vii­vais­ta, eikä kehit­tä­jän tar­vit­se vält­tä­mät­tä aja­tel­la Spark-moot­to­rin kou­ke­roi­ta ja hie­nouk­sia kehi­tys­työ­tä teh­des­sä – kui­ten­kin erit­täin moni­puo­li­set kon­fi­gu­raa­tio­mah­dol­li­suu­det säilyttäen.

Työn­ku­lun luon­ti ja riip­pu­vuuk­sien hallinta

Vii­me­ai­kai­se­na uutuu­te­na Data­brick­siin tul­lut Del­ta Live Table (DLT) tar­jo­aa myös huo­mat­ta­vaa lisä­ar­voa data­rat­kai­suil­le. Mie­les­tä­ni olen­nai­sim­pa­na lisä­nä tämä tuo auto­maat­ti­sen DAG-tyy­pi­sen työn­ku­lun muo­dos­tuk­sen sekä riip­pu­vuuk­sien hal­lin­nan. Tämä aut­taa pitä­mään pro­ses­soin­ti­ket­jut oikeas­sa jär­jes­tyk­ses­sä ja var­mis­taa, että oikeat tau­lut latau­tu­vat oikeas­sa jär­jes­tyk­ses­sä. DAG-ket­jut ovat myös käyt­tä­jien näh­tä­vil­lä, jol­loin datan muu­tos­his­to­ria (eng. Data linea­ge) on näh­tä­vil­lä raa­ka­tau­luis­ta aina rapor­toin­tiin asti. Lisäk­si DLT mah­dol­lis­taa dekla­ra­tii­vi­sen data­put­ki­ke­hi­tyk­sen mis­sä sama data­put­ki ja sama koo­di pys­tyy pro­ses­soi­maan eri läh­de­tau­lu­ja joko erä­ajo­na tai strii­mi­nä, jol­loin ark­ki­teh­tuu­ri yksin­ker­tais­tuu ja koo­din mää­rä vähe­nee. DLT-data­put­kien kaut­ta kul­ke­van datan laa­dun­val­von­ta on samal­la tavoin pit­käl­le auto­ma­ti­soi­tu, mis­sä ennal­ta mää­ri­tel­ty­jen sään­tö­jen ja ehto­jen perus­teel­la data vali­doi­daan pro­ses­soin­nin yhtey­des­sä ja tulok­set, kuten ehto­ja ei-täyt­tä­vien rivien mää­rä, on visu­aa­li­ses­ti näky­vil­lä käyttäjälle.

Tie­to­jen hal­lin­ta Uni­ty Cata­lo­gin avulla

Vii­me vuon­na tul­leis­ta uusis­ta mie­len­kiin­toi­sis­ta omi­nai­suuk­sis­ta Data­bricks Uni­ty Cata­log tar­jo­aa näky­vyyt­tä ja hal­lit­ta­vuut­ta sil­loin kun läh­de­jär­jes­tel­miä ja lop­pu­käyt­tä­jä­ryh­miä on usei­ta ja tätä kaik­kea halu­taan hal­li­ta yhdes­sä kes­ki­te­tys­sä pai­kas­sa siten että orga­ni­saa­tion datan hal­lin­ta­mal­li (data gover­nance) toteu­tuu koko datan elin­kaa­ren aika­na. Uni­ty Cata­log mah­dol­lis­taa datan löy­tä­mi­sen lop­pu­käyt­tä­jil­le meta­da­tan poh­jal­ta kai­kes­ta datas­ta mikä on rekis­te­röi­ty mukaan ja datan jaka­mi­sen Del­ta Sha­ring –omi­nai­suu­den kaut­ta koh­teen kans­sa, joka on saman Data­bricks ins­tans­sin sisäl­lä, saman pil­ven sisäl­lä tai ei pil­ves­sä lain­kaan. Data on saa­ta­vil­la hel­pos­ti, mut­ta hal­li­tus­ti siten, että Cata­lo­gin sisäl­lä dataan pää­syä hal­lin­noi­daan, audi­toi­daan ja moni­to­roi­daan kes­ki­te­tys­ti yhdes­sä paikassa.

Tie­to­jen jul­kai­se­mi­nen Data­brick­sin avulla

Aiem­min Data­brick­sin haas­tee­na on ollut datan jake­lu­puo­li ja se, miten var­mis­taa, että BI-kehit­tä­jät ja lii­ke­toi­min­ta-ana­lyy­ti­kot pää­se­vät käsik­si val­mii­seen dataan heil­le tutuin mene­tel­min ja työ­ka­luin. Nyky­ään Data­bricks tar­jo­aa tähän natii­vi­na rat­kai­su­na SQL Ware­housea, joka mah­dol­lis­taa datan jul­kai­sun perin­teis­tä relaa­tio­kan­taa muis­tut­ta­vaan käyt­tö­liit­ty­mään. Näin ollen val­mis­ta, mal­lin­net­tua dataa voi­daan kysel­lä SQL-kie­lel­lä joko suo­raan verk­ko­se­lai­mel­ta tai tue­tus­ta SQL-kehit­ti­mes­tä, esi­mer­kik­si DBea­ve­ris­tä. Myös laa­jal­ti käy­te­tyt BI-työ­ka­lut (esim. Power BI, Tableau, Qlik, Loo­ker) integroi­tu­vat hel­pos­ti Data­bricks SQL Ware­houseen. SQL Ware­house vaa­tii kir­joi­tus­het­kel­lä vie­lä käyn­nis­sä ole­van klus­te­rin toi­miak­seen, mut­ta myös ser­ver­less-rat­kai­su on public pre­view ‑vai­hees­sa ja tulee jul­ki ennen pitkää.

Mihin Data­brick­siä käytetään?

Tyy­pil­li­siä käyt­tö­ta­pauk­sia, joi­hin Data­bricks sopii:

1. Suur­ten data­mas­so­jen kans­sa työskentely: 
   • Ennen muu­ta hajau­tet­tu las­ken­ta, mut­ta myös laa­ja skaa­la klus­te­ri­vaih­toeh­to­ja ja moni­puo­li­set ohjel­moin­ti­kie­li­vaih­toeh­dot tar­joa­vat kaik­ki tar­vit­ta­vat työ­ka­lut suur­ten data­mas­so­jen kans­sa työs­ken­te­lyyn aika- ja kustannustehokkaasti.
2. Laa­jat ja moni­nai­set data-alustat: 
   • Data­brick­sin moni­puo­li­suus mah­dol­lis­taa erit­täin monien käyt­tö­ta­paus­ten toteut­ta­mi­sen yhdes­sä ja samas­sa ympä­ris­tös­sä. Datain­si­nöö­rit hoi­ta­vat raa­ka­da­tan haun, puh­dis­tuk­sen ja Data Vault/​dimensionaalisen mal­lin­nuk­sen, data­tie­tei­li­jät kehit­tä­vät ja har­joit­ta­vat koneop­pi­mis­mal­lit näi­den dato­jen poh­jal­ta ja BI-ana­lyy­ti­kot tar­joi­le­vat datan ylei­sim­min käy­tet­ty­jen visua­li­soin­ti­työ­ka­lu­jen käyt­töön SQL Ware­house ‑raja­pin­nas­sa.
3. Täs­mä­rat­kai­sut, joi­hin nykyi­sin käy­tös­sä ole­vat työ­ka­lut eivät luon­tai­ses­ti taivu: 
   • Esi­mer­kik­si IoT-lait­tei­den toi­mit­ta­man datan pro­ses­soin­ti voi olla monil­le perin­tei­sil­lä työ­ka­luil­la (esim. relaa­tio­kan­nat) toteu­te­tuil­le data-alus­toil­le lii­kaa sekä datan mää­rän että päi­vi­tys­ti­hey­den puo­les­ta. Esi­mer­kik­si Del­ta Live Table ‑toi­min­not tar­joa­vat tähän tar­koi­tuk­seen sovel­tu­van help­po­käyt­töi­sen Strea­ming Tablen, mut­ta saa­ta­vil­la on myös mui­ta vaihtoehtoja.
   • Esi­mer­kik­si joi­den­kin läh­tei­den raa­ka­da­ta voi olla niin haas­ta­vas­sa muo­dos­sa, että perin­tei­sin työ­ka­luin raken­ne­tut rat­kai­sut jou­tu­vat ennen pit­kää ongel­miin joko suo­ri­tus­ky­vyn tai yllä­pi­det­tä­vyy­den näkö­kul­mas­ta, usein molem­mis­ta. Näis­sä tapauk­sis­sa Spark Data­fra­met ja esi­mer­kik­si Pyt­ho­nin modu­laa­ri­suus ja uudel­leen­käy­tet­tä­vyys SQL:ään näh­den mah­dol­lis­ta­vat huo­mat­ta­vas­ti tehok­kaam­mat ja hel­pom­min yllä­pi­det­tä­vät ratkaisut.
4. Uuden data-alus­tan raken­ta­mi­nen puh­taal­ta pöydältä: 
   • Data­bricks tar­jo­aa tehok­kaat työ­ka­lut min­kä tahan­sa data-alus­ta­rat­kai­sun kehit­tä­mi­sel­le työ­ka­lu­pa­le­til­la, jos­ta löy­tyy jokai­sel­le kehit­tä­jäl­le tutut työ­ka­lut. Jos Data­bricks vali­taan toteu­tus­tek­no­lo­giak­si heti elin­kaa­ren alku­vai­hees­sa, ei epä­huo­mios­sa sul­je­ta mitään käyt­tö­ta­pauk­sia data-alus­tan ulko­puo­lel­le tai pako­te­ta itseä myö­hem­min integroi­maan alus­taan sel­lai­sia kom­po­nent­te­ja, jot­ka eivät sii­hen sau­mat­to­mas­ti sovi.
5. Mac­hi­ne Learning: 
   • Koneop­pi­mi­nen (eng. Mac­hi­ne Lear­ning — ML) on ollut muka­na ja kes­kiös­sä koko Data­brick­sin his­to­rian ajan. Nykyi­sel­lään Data­brick­sin ML kyvyk­kyy­det on raken­net­tu avoi­men lake­house-ark­ki­teh­tuu­rin pääl­le, mis­sä omi­nai­suu­det kuten AutoML ja MLflow tuke­vat ja mah­dol­lis­ta­vat koneop­pi­mis­mal­lien kehi­tyk­sen, elin­kaa­ren hal­lin­nan ja val­mii­den mal­lien monitoroinnin.

Mitä Islet on teh­nyt Databricksillä?

Yhte­nä esi­merk­ki­nä tii­mim­me teke­mä erit­täin laa­ja data-alus­ta, jos­sa datain­si­nöö­rim­me hyö­dyn­si­vät Del­ta Live Table ‑toi­min­to­ja datan pro­ses­soin­nis­sa raa­ka­das­ta val­miik­si ja jake­lu­kel­poi­sek­si dimen­sio­mal­lik­si, joka jael­tiin lop­pu­käyt­tä­jil­le SQL Ware­house ‑liit­ty­mäs­sä. Toteu­tuk­ses­sa integroi­tiin suu­ren suo­ma­lai­sen yhtiön SAP S4 HANA data Azu­reen Data­bricks Note­boo­keil­la. Raa­ka­da­ta haet­tiin SAP:n kan­nas­ta sekä tal­le­tet­tiin ADLS Gen2:een Aecor­soft Data Inte­gra­to­ril­la. Toteu­tus teh­tiin täy­sin meta­da­taoh­ja­tuk­si – uut­ta dataa integroi­taes­sa vain uusien tau­lu­jen perus­tie­dot kir­joi­te­taan kon­fi­gu­raa­tio­tie­dos­toon, jon­ka jäl­keen Data­bricks Note­boo­kit hake­vat uuden, tar­jol­la ole­van raa­ka­da­tan, puh­dis­ta­vat sitä sekä teke­vät tar­vit­ta­vat muun­nok­set jat­ko­kä­sit­te­lyn hel­pot­ta­mi­sek­si. Lopul­ta dimen­sio­mal­li muo­dos­te­taan Azu­re DevOps repo­si­to­ryyn kir­joi­tet­tu­jen SQL-kyse­lyi­den avul­la, jot­ka Del­ta Live Table ‑put­ket luke­vat ja muo­dos­ta­vat asiak­kaan kans­sa yhteis­työs­sä suun­ni­tel­lun dimen­sio­naa­li­sen mal­lin Data Lakeen. Tämä mal­li jael­laan Power BI:lle ja ana­lyy­ti­koil­le SQL Warehousella.

Jos haluat kuul­la lisää Data­brick­sin mah­dol­li­suuk­sis­ta, mei­dän koke­muk­sis­tam­me tai muu­ten spar­rail­la Lake­house ark­ki­teh­tuu­ris­ta, ota yhteyttä!