🥇 Paindlike DWH projekteerimise metodoloogiate ülevaade

Andmetehoidla arendamine on pikk ja tõsine protsess.

Paljuski sõltub projekti edust sellest, kui hästi on alguses läbi mõeldud objekti mudel ja andmebaasi struktuur.

Tavapärane lähenemine on erinevad variatsioonid “tärni” skeemi ja kolmanda normaali vormi (3NF) kombinatsioonist. Üldiselt kehtib põhimõte: algandmed — 3NF, vitriinid — tärn. See lähenemine, mis on aja jooksul tõestatud ja suure hulga uuringutega toetatud, on esimene (ja mõnikord isegi ainus) mõte, mis tuleb kogenud DWH spetsialisti pähe, kui mõelda, kuidas analüütiline andmehoidla peaks välja nägema.

Teisest küljest on äri ja kliendi nõudmised tuntud kiire muutuja, samas kui andmed kasvavad nii “sügavale” kui ka “laiusele”. Ja siin ilmneb tärni peamine puudus — piiratud paindlikkus.

Ja kui teie vaikuses ja mugavuses elus DWH arendajana äkki:

tekib ülesanne “teha kiiresti midagi, ja siis vaatame”;
ilmub kiiresti arenev projekt, kus uute allikate lisamine ja ärimudeli ümberkujundamine toimub vähemalt kord nädalas;
on tellija, kes ei sea selgelt, kuidas süsteem peaks välja nägema ja milliseid funktsioone täitma, kuid on eksperimenteerimise ja järkjärgulise tulemuse täpsustamisega nõus, samas kui lähenemine on samuti järkjärguline;
tutvustas projektijuht rõõmsa uudisega: “Nüüd on meil agiilne mudel!”.

Või kui teil on lihtsalt huvi, kuidas veel andmehoidlaid üles ehitada — olete teretulnud lugema edasi!

Mis tähendab „paindlikkus“

Kuna me alustasime, siis määratleme, milliseid omadusi peaks süsteem omama, et seda saaks nimetada „paindlikuks“.

Tasub mainida, et kirjeldatud omadused peaksid puudutama just süsteemi, mitte protsessi selle arendamisel. Seega, kui soovisite lugeda Agile metodoloogiast, on parem tutvuda teiste artiklitega. Näiteks on Hubris palju huvitavaid materjale (nagu ülevaated ja praktilised, kui ka probleemid).

See ei tähenda, et arendusprotsess ja DWH struktuur ei oleks omavahel seotud. Üldiselt peaks Agile'i järgi arendamine paindliku arhitektuuri hoidlast olema oluliselt lihtsam. Praktikas esinevad aga sagedamini juhul, kui arendatakse traditsioonilist DWH-d Kimballi või DataVaulti järgi — vedajatena, pigem kui ilmsed juhuslikud kokkulangevused paindlikkuse kahe ilmingu vahel ühel projektis.

Nii, millised võimalused peaks paindlik hoidla omama? Siin võib välja tuua kolm punkti:

Varajane tarnimine ja kiire täiendamine — see tähendab, et ideaaljuhul peaks esimene äriline tulemus (näiteks esimesed töötavad aruanded) olema saadud võimalikult varakult, st juba enne, kui süsteemi tervikprojekti on täielikult kavandatud ja rakendatud. Samuti peaks iga järgmine täiendamine nõudma võimalikult vähe aega.
Iteratiivne täiendamine — see tähendab, et iga järgmine täiendus ei tohiks ideaalis puudutada juba töötavat funktsionaalsust. Just see aspekt on sageli suurim õudusunenägu suurtes projektides — varem või hiljem hakkavad eraldi objektid olema nii paljude suhetega seotud, et on lihtsam kogu loogika kopeerida kõrvalt, kui lisada väli olemasolevasse tabelisse. Ja kui teid üllatab, et muudatuste mõju olemasolevatele objektidele analüüsimine võib võtta rohkem aega kui täiendamine ise — siis olete tõenäoliselt veel suurte DWH-idega panganduses või telekommunikatsioonis töötanud.
Pidev kohandumine muutuvaid ärinõudeid — üldine objekti struktuur peaks olema kavandatud mitte lihtsalt võimaliku laiendamise arvesse võtmisega, vaid nii, et selle laiendamise suunda ei oleks isegi unistades kujuteldav projekti kavandamise etapil.

Ja jah, nendele kõigile nõuetele vastamine ühesüsteemis on võimalik (muidugi teatud juhtudel ja teatud tingimustega).

Allpool käsitlen kahte populaarseimat paindliku projekteerimise metoodikat DWH-de jaoks — Anchor model ja Data Vault. Kaaludelt jäävad välja sellised suurepärased tehnikad nagu näiteks EAV, 6NF (puhtal kujul) ja kõik, mis on seotud NoSQL lahendustega — mitte sellepärast, et need oleksid millegagi halvemad, ja isegi mitte sellepärast, et sel juhul ähvardaks artikkel omada keskmise teadusliku töö mahtu. Lihtsalt kõik see kuulub veidi teistsuguste klasside lahendustele — kas tehnikatele, mida saate rakendada konkreetsetes olukordades, sõltumata teie projekti üldisest arhitektuurist (nagu EAV), või hoopis globaalsetele informatsiooni salvestamise paradigmadele (nagu näiteks graafandmebaasid ja teised NoSQL valikud).

Klassikalise lähenemise probleemid ja nende lahendused paindlikes metodoloogiates

Klassikalise lähenemise all mõistan vana head tähtrauda (ilma et arvesse võtta aluseks olevate kihtide konkreetseid teostusi, palun andestage mulle Kimballi, Inmoni ja CDM apostlid).

1. Tugev karistuse määratlus seoste vahel

Selle mudeli aluseks on andmete selge jaotus mõõtmed (Dimension) ja faktid (Fact). Ja see, kurat võtaks, on loogiline — analüüs andmetesse enamikus juhtudel vähendab end konkreetsete arvuliste näitajate (faktide) analüüsiks teatud lõigetes (mõõtmetes).

Samas määratakse objektide vahelised seosed tabelite vaheliste välisvõtmete kaudu. See tundub täiesti loomulik, kuid toob koheselt kaasa esimese paindlikkuse piirmäära — tugeva seoste karistuse määratlemise.

See tähendab, et tabelite projekteerimise etapis peate täpselt määratlema, kas iga seotud objektide paarid saavad olema mitmed-ühele, või ainult 1-ühele, ja „kuhu suunas”. Sellest sõltub otse, millises tabelis on peamine võti ja millises — väline. Nende suhete muutmine uute nõudmiste korral toob tõenäoliselt kaasa andmebaasi ümbertegemise.

Näiteks, projekteerides objekti „kassakviitung” tuginedes müügiosakonna tõotustele, olite sätestanud ühe kampaania mõju mitmele kviitungipositsioonile (aga mitte vastupidi): Ja mõne aja pärast tutvustasid kolleegid uut turundusstrateegiat, kus ühele ja samale positsioonile võivad kehtida

mitmed kampaaniad samal ajal. Nüüd peate tabelid kohandama, tuues seose eraldi objekti.. Ja nüüd peate te töötlema tabeleid, tuues seose eraldi objektina esile.

(Kõik tuletatud objektid, milles toimub promo kontroll, vajavad nüüd samuti täiustamist).

Seosed Data Vaultis ja Anchor Mudelis

Sarnase olukorra vältimine osutus üsna lihtsaks: ei tasu müügiosakonna usaldada, selleks piisab kõiki seoseid algselt eraldi tabelites hoidma ja töödelda neid kui paljusid-kui-paljusid.

Selline lähenemine pakuti välja Dan Linstedti poolt osana paradigmist Data Vault ja seda toetas täielikult Lars Rönnbäck ja Anchor Mudel.

Kokkuvõttes saame esimest silmapaistvat tunnust paindlikest metoodikatest:

Seosed objektide vahel ei ole salvestatud vanemate entiteetide atribuutesse, vaid kujutavad endast eraldi tüüpi objekte.

Uues Data Vault Selliseid seostetabeleid nimetatakse Linktoob kaasa selle, et "saadetamise" hetkel server ei ole veel käivitatud ja kõik läheb katki. Anchor Mudel — Tie. Esmapilgul sarnanevad nad väga, kuigi nende erinevusi ei piirdu ainult nimetusega (millest räägitakse allpool). Mõlemas arhitektuuris saavad seostetabelid siduda mille igasuguseid entiteete (mitte tingimata 2).

See esmapilgul liialdatud lähenemine pakub olulist paindlikkust täiustuste tegemisel. Selline struktuur muutub toleranteerivaks mitte ainult olemasolevate seoste kardinaalsuse muutumise suhtes, vaid ka uute lisamise suhtes — kui nüüd kassapunkti külge tuleb lisaviidatud kassapidajale, siis sellise sideme loomine on lihtsalt lisand, mis ei mõjuta mingeid olemasolevaid objekte ja protsesse.

2. Andmete dubleerimine

Teine probleem, mida paindlikud arhitektuurid lahendavad, on vähem ilmne ja iseloomulik enamasti SCD2 tüüpi mõõtmistele (aeglaselt muutuvale mõõtmisele teist tüüpi), kuigi mitte ainult neile.

Klassikalisel andmehoidlas mõõtmine esindab tavaliselt tabelit, mis sisaldab asenduskoodi (PK-na) ning komplekti ärikoodidest ja atribuute eraldi veergudel.

Kui mõõtmine toetab versioonitust, siis lisatakse standardsetele valdkondadele versioonide kehtivuse ajapiirid, ja ühe rea kohta allikas on andmehoidlas mitu versiooni (igaühe versiooniredaktide nihutamise jaoks).

Kui mõõtmetel on vähemalt üks sagedasti muutuva versiooniga atribuut, siis selliste mõõtmete versioonide arv on muljetavaldav (isegi kui ülejäänud atribuudid ei ole versioonilised või ei muutu kunagi), ja kui neid atribuute on mitu, võib versioonide arv geomeetriliselt kasvada. Selline mõõde võib hõivata märkimisväärse osa kettaruumi, kuigi enamik seal hoitavatest andmetest on lihtsalt fikseeritud atribuutide väärtuste dubleerimine teistest ridadest.

Sagedasti rakendatakse ka denormaliseerimist — osa atribuudidest hoitakse eesmärgiga salvestada neid väärtustena, mitte viidena loendisse või muusse mõõtmesse. Selline lähenemine kiirendab juurdepääsu andmetele, vähendades ühildamiste arvu, kui pöörduda mõõtme poole.

Tavaliselt viib see olukorrani, et samad andmed on samal ajal salvestatud mitmes kohas. Näiteks võib elukoha ja kliendi kategooria kuuluvuse teave korraga eksisteerida mõõtmetes “Klient” ja faktides “Ost”, “Kohaletoimetamine” ja “Klienditeenindusse pöördumised”, samuti seotud tabelis “Klient — Kliendihaldur”.

Üldiselt ka kirjeldatud asjaolud kehtivad ka tavapäraste (mitte versiooniliste) mõõtmete kohta, kuid versiooniliste puhul võivad need omada erinevat ulatust: uue objekti versiooni ilmumine (eriti tagantjärele) ei tähenda ainult kõigi seotud tabelite värskendamist, vaid ka seotud objektide uusversioonide paiskumist — kui Tabel 1 kasutatakse Tabeli 2 koostamiseks, siis Tabel 2 Tabeli 3 koostamiseks jne. Isegi kui Tabeli 1 ei osale Tabeli 3 koostamises (ja osalevad Tabeli 2 teised atribuudid, mis on saadud muudest allikatest), toob selle struktuuri versioonivärskendus vähemalt kaasa täiendavad kulud ja maksimaalselt — liigseid versioone Tabelis 3, mis ei ole siin üldse “asjakohane” ja edasi ahelas.

3. Mitte-lineaarne keerukus täiustamisel

Samaaegselt iga uus vitriin, mis koostatakse teise alusel, suurendab kohtade arvu, kus andmed võivad ETL muudatuste tegemisel “lahku minna”. See omakorda toob kaasa igasuguste uute täiustuste keerukuse (ja kestuse) kasvu.

Kui eelnevalt kirjeldatu kehtib süsteemide kohta, kus ETL-protsessid harva arenevad, saab sellises paradigmas elada — piisab lihtsalt jälgimisest, et uued arendused oleksid õigesti kantud kõikidesse seotud objektidesse. Kui aga arendused toimuvad sageli, suureneb oluliselt tõenäosus, et mõni seos jääb kogemata kahe silma vahele.

Kui lisaks arvestada, et „versiooniga” ETL on oluliselt keerulisem kui „ilma versioonita”, siis muutub selle kõikse haldamine piisavalt keeruliseks, et vigu vältida.

Objektide ja atribuutide salvestamine Data Vaultis ja Anchor mudelis

Autorite pakutud lähenemist elastsete arhitektuuride valdkonnas saab sõnastada järgmiselt:

On vajalik eraldada see, mis muutub, sellest, mis jääb muutumatuks. Teisisõnu, salvestada võtmed eraldi atribuutidest.

Sellegipoolest ei tasu segi ajada ilma versioonita atribuutit muutumatu: esimene ei salvesta oma muutumise ajalugu, kuid võib muutuda (näiteks andmete sisestamise vea parandamisel või uute andmete saamisel) teine — ei muutu kunagi.

Arvamused selle kohta, mida täpselt saab Data Vaultis ja Anchor mudelis pidada muutumatuks, erinevad.

Arhitektuuri vaatepunktist Data Vault, võib muutumatuks pidada kogu võtmete kogumit — naturaalsed (organisatsiooni registrikood, toote kood allik süsteemis jne) ja surrogaadid. Samal ajal saab ülejäänud atribuudid jagada rühmadeks allika ja / või muutuste sageduse järgi ning iga rühma jaoks peab olema loodud eraldi tabel iseseisva versioonide kogumiga.

Kuid Anchor Model paradigmas peetakse muutumatuks ainult surrogaadivõtmeid olendi. Kõik muu (sealhulgas naturaalsed võtmed) on lihtsalt tema atribuutide erijuhud. Samuti kõik atribuudid on vaikimisi üksteisest sõltumatud , seega peab iga attribuudi jaoks olema looduderaldi tabel tabelid, mis sisaldavad olendi võtmeid, nimetatakse.

Uues Data Vault Hubideks (Hub) . Hubid sisaldavad alati fikseeritud kogust välju:Olendi naturaalsed võtmed

Surrogaadivõti
Viide allikale
Salvestamise aeg
Kirjed Hubides

kunagi ei muutu ja ei oma versioone. ei muutu kunagi ja neil ei ole versiooneVälimik lahendused sarnanevad väliselt ID-kaartide tabelitega, mida kasutatakse mõnedes süsteemides surrogaatide genereerimiseks, kuid Data Vault soovitab surrogaatide jaoks kasutada mitte täisarvulist järjestust, vaid ärivõtmete komplekti räsi. Selline lähenemine lihtsustab suhete ja atribuute allikatest laadimist (ei pea liitma hubi, et saada surrogaat, piisab vaid loendamisest, häššides loodud võtme), kuid võib põhjustada muid probleeme (näiteks kolüüside, suurte ja mitte trükitavate sümbolite tõttu stringivõtmetes jne), seega ei ole see üldiselt aktsepteeritud.

Kõik muud atribuudid salvestatakse erilistes tabelites, mida nimetatakse satelliitideks (Satellit). Ühel hubil võib olla mitu satelliiti, mis salvestavad erinevaid atribuutide komplekte.

Atribuutide jaotamine satelliitide vahel toimub põhimõtte järgi koosmuutmine — ühes satelliidis võivad olla versioonivabad atribuudid (näiteks sünnipäev ja isikukood füüsilisele isikule), teises — harva muutuvad versioonilised (näiteks perekonnanimi ja passi number), kolmandas — sageli muutuvad (näiteks kohaletoimetamise aadress, kategooria, viimane tellimise kuupäev jne). Versioonilisus toimub eraldi satelliitide tasandil, mitte terviku mõistes, seega on atribuudi jaotamine mõistlik teha nii, et ühe satelliidi sisesed versioonide lõimingud oleksid minimaalsed (mis vähendab kokkuhoitud versioonide arvu).

Samuti, andmete laadimise protsessi optimeerimiseks, kantakse eraldi satelliitidesse sageli atribuudid, mis on saadud erinevatest allikatest.

Satelliidid on seotud Hubiga läbi välishiirde (mis vastab kardinaalsusele 1-kaduma). See tähendab, et atribuutide mitmesugust väärtust (näiteks mitmeid kontakttelefoninumbreid ühe kliendi jaoks) toetab selline arhitektuur „vaikimisi”.

Uues Ankurmudeli (Anchor Model) tabelid, mis salvestavad võtmeid, nimetatakse ankurditeks (Anchor). Ja nad salvestavad:

Ainult surrogaatvõtmed
Salvestamise aeg
Kirjed Hubides

Looduslikud võtmed on Ankurmudeli seisukohalt tavalised atribuudid. Selline variant võib tunduda keerulisem mõista, kuid see annab palju rohkem ruumi objekti identifitseerimiseks.

Näiteks kui sama üksuse andmed võivad pärineda erinevatest süsteemidest, milles kasutatakse erinevaid looduslikke võtmeid. Data Vaultis võib see viia üsna mahukate konstruktsioonideni, kus on mitu hubi (iga allika jaoks üks + ühendav peamist versioon), samas kui Ankurmudelis satub iga allika looduslik võti oma attribuuti ja seda saab laadimise ajal kasutada sõltumatult teistest.

Kuid siin peitub üks salakaval moment: kui ühes üksuses koondatakse atribuute erinevatest süsteemidest, siis tõenäoliselt eksisteerivad mõned koondamisreeglid, mille järgi süsteem peab mõistma, et erinevatest allikatest saadud rekordid vastavad ühele ja samale üksuse eksemplarile.

Uues Data Vault Need reeglid määravad tõenäoliselt „asendushubi” peamise üksuse loomise ja ei mõjuta hube, mis salvestavad allikate looduslikke võtmeid ja nende algseid atribuute. Kui mingil hetkel koondamisreeglid muutuvad (või tuleb uuendus atribuute, mille alusel seda täiendatakse), piisab asendushubide ümberkujundamisest.

Uues Ankurmudel selline üksus tõenäoliselt hoitakse ühes ainsas ankurduspunktis.See tähendab, et kõik atribuudid, sõltumata sellest, millisest allikast need on saadud, seondatakse samale asendajale. Vigu kumulatiivselt eristada ja jälgida koondamise täpsust sellises süsteemis võib osutuda oluliselt keerulisemaks, eriti kui reeglid on piisavalt keerulised ja muutuvad tihti, ning sama atribuut võib pärineda erinevatest allikatest (kuigi see on täpselt võimalik, kuna iga atribuutversioon salvestab viite oma allikale).

Igal juhul, kui teie süsteemis on kavandatud funktsionaalsete elementide rakendamine duplikaatide eemaldamine, rekordite liitmine ja muud MDM elemendid, on eriti oluline tutvuda looduslike võtmete ladustamise aspektidega paindlikes meetodites. Tõenäoliselt osutub Data Vaulti mahukam konstruktsioon järsku turvalisemaks seoses sulandumise vigadega.

Ankurmudel näeb samuti ette täiendava objekti tüübi, mida nimetatakse Sõlme (Knot) tegelikult on see eriline degenereeritud ankur, mis võib sisaldada vaid ühte atribuuti. Süsteeme on ette nähtud kasutamiseks lamejuhtide hoidmiseks (nt sugu, perekonnaseis, klienditeeninduse kategooria jne). Erinevalt Ankrust, Süsteem ei oma seotud atribuutide tabeleid, ja selle ainus atribuut (nimi) salvestatakse alati ühte tabelisse koos võtmega. Süsteemid seondub Ankrute tabelitega (Tie) samuti nagu ankrud omavahel.

Üksmeelt Süsteemide kasutamise osas pole. Näiteks, Nikolai Golov, kes aktiivselt edendab Ankurmudeli rakendamist Venemaal, usub (mitte põhjendatult), et ühele juhtimissüsteemile ei saa kindlalt öelda, et see alati oleks staatiline ja ühetasandiline, seega on kõigi objektide jaoks parem kohe kasutada täisväärtuslikku Ankrut.

Veel üks oluline erinevus Data Vaulti ja Ankurmudeli vahel on seoste atribuutide olemasolu:

Uues Data Vault Seosed on sama täisväärtuslikud objekid nagu Hublid ja võivad omada oma atribuute. Failis Ankurmudel Seosed kasutatakse ainult Ankrute ühendamiseks ja oma atribuute omada ei saa. See erinevus toob kaasa oluliselt erinevad lähenemised modelleerimisele faktide, millest räägitakse edasi.

Faktide salvestamine

Enne seda rääkisime peamiselt mõõtmete modelleerimisest. Faktidega on asi veidi vähem üheselt mõistetav.

Uues Data Vault tüüpiline objekt faktide hoidmiseks — Seos (Link), mille Sattelitesse kogunevad materiaalsed näitajad.

See lähenemine tundub intuitiivselt arusaadav. See annab lihtsa ligipääsu analüüsitavatele näitajatele ja sarnaneb üldiselt traditsioonilise faktitabeliga (ainult näitajad ei ole salvestatud otse tabelisse, vaid „naabertabelisse“). Kuid siin on ka peidetud probleemid: üks tüüpiline modelleerimise täiendamine — faktivõtme laiendamine — tekitab vajaduse uue välist võtme lisamiseks Linki. See rikub omakorda moodulsust ja võib potentsiaalselt põhjustada vajaduse teiste objektide täienduste järele.

Uues Ankurmudel Seos ei saa omada oma atribuute, seega ei sobi selline lähenemine — absoluutselt kõik atribuudid ja näitajad peavad olema seotud ühe konkreetse ankruga. Kokkuvõte on lihtne — iga fakti jaoks on samuti vajalik oma ankur. Osade, mis me harjutasime pidama faktideks, võib see tunduda loomulik — näiteks ostu fakt koondub objektile "tellimus" või "kviitung", veebisaidi külastus — sessioonile jne. Kuid on ka fakte, mille jaoks sellise loomuliku "objekt-kandja" leidmine ei ole nii lihtne — näiteks päevade alguses laos olevate kaupade varude jäägid.

Seega ei teki faktiteema võtme laiendamisel järeldusmudelis probleeme, kuna piisab lihtsalt uue ühenduse lisamisest vastavale järeldusele, kuid mudeli kavandamine faktide kuvamiseks on vähem üheselt mõistetav, võivad tekkida "kunstlikud" järeldused, mis ei peegelda ärimudeli objekti selgelt.

Kuidas saavutatakse paindlikkus

Saadud konstruktsioon mõlemas juhul sisaldab oluliselt rohkem tabeleid, kui traditsiooniline mõõtmine. Aga võib võtta oluliselt vähem kettaruumi sama versiooniate atribuutide kogumiga, mis on traditsiooniline mõõtmine. Siin pole mingit maagilist — kõik on normaalsuse küsimus. Jagades atribuudid satelliitidesse (Data Vaultis) või eraldi tabelitesse (Anchor Model), vähendame (või välistame täielikult) ühtede atribuutide väärtuste dubleerimist teiste muutumisel..

Tooge Data Vault Kasum sõltub atribuutide jaotamisest satelliitidesse, ja Ankurmudel — on praktiliselt otseselt proportsionaalne mõõtemudeli objekti keskmise versioonide arvu järgi.

Kuid ruumi kokkuhoid on oluline, kuid mitte peamine eelis atribuutide eraldi hoidmisel. Koos eraldi linkide hoidmisega muudab see ladustamise moodulaarseks konstruktsiooniks. See tähendab, et nii eraldi atribuutide kui ka tervikute uusate valdkondade lisamine sellesse mudelisse tundub nagu täiendamine olemasolevatele objektide kogumile ilma nende muutmiseta. Ja just see muudab kirjeldatud meetodid paindlikuks.

See meenutab ka üleminekut üksiktootmiselt masstootmisele — kui traditsioonilises lähenemises on iga mudelitabel ainulaadne ja vajab eraldi tähelepanu, siis paindlikes meetodites on see juba standardsete "detailide" kogum. Ühelt poolt on tabeleid rohkem, andmete laadimise ja valimise protsessid näivad keerulisemad. Teiselt poolt — need muutuvad standardseteks. Seega võivad need olla automaatne ja hallata metaandmeid. Küsimus „kuidas me paigutame?“, millele vastamine võiks võtta märkimisväärse osa muudatuste projekteerimise tööst, ei ole enam oluline (nagu ka küsimus, kuidas mudeli muutmine mõjutab käimasolevaid protsesse).

See ei tähenda, et analüütikud sellises süsteemis täielikult tarvis ei ole — keegi peab ikkagi töötama välja objektide kogumi atribuutidega ja selgitama välja, kust ja kuidas kõike seda laadida. Kuid töö maht, samuti tõenäosus ja viga hind on oluliselt vähenenud. Nii analüüsi etapis kui ka ETLi arendamisel, mis suuresti võib tähendada metaandmete redigeerimist.

Tume pool

Kõik eeltoodud muudab mõlemad lähenemised tõeliselt paindlikeks, tehnoloogilisteks ja sobivateks iteratiivseks arendamiseks. Loomulikult on olemas ka „tõrvatükk“, millest arvan, et oled juba teadlik.

Andmete dekompositsioon, mis on paindlike arhitektuuride moodularhitektuuride aluseks, viib tabelite arvu suurenemiseni ja seega mugavuskulud JOIN'e puhul päringute tegemisel. Selleks, et lihtsalt saada kõik mõõtmete atribuudid, piisab klassikalisest andmehoidlast ühest SELECT-ist, aga paindlik arhitektuur nõuab terve reas JOIN'e. Ja kui kõiki neid JOIN'e saab aruannete jaoks ette kirjutada, siis analüütikud, kes on harjunud SQL-i käsitsi kirjutama, peavad kaks korda rohkem vaeva nägema.

On mitmeid fakte, mis seda olukorda lihtsustavad:

Kui töötada suurte mõõtmete kallal, ei kasutata peaaegu kunagi korraga kõiki selle atribuudid. See tähendab, et JOIN'e võib olla vähem, kui esmapilgul mudelit vaadates paistab. Data Vault'is saab samuti arvesse võtta eeldatavat koostöösagedust, jaotades atribuudid satelliitide vahel. Kuid ise Hübriidid või Ankurid on vajalikud peamiselt substraatide genereerimiseks ja kaardistamiseks laadimise etapis ning neid harva kasutatakse päringutes (see puudutab eriti Ankureid).

Kõik JOIN'id — võtme järgi. Lisaks, andmete 'kompaktselt' salvestamise viis vähendab tabelite skanneerimise kulusid seal, kus see on vajalik (näiteks atribuutide järgi filtreerimisel). See võib viia selleni, et normaaliseeritud andmebaasi alusel, millel on hulgi liiteid, on andmete hankimine isegi kiirem kui ühe raskete mõõtmega, millel on palju versioone iga rea kohta.

Näiteks, siin selle artikkel sisaldab üksikasjalikku võrdlevat testimist Ankurmudeli jõudluse kohta, mis on seotud ühe tabeliga.

Palju sõltub mootorist. Paljudel kaasaegsetel platvormidel on sisemised mehanismid liidete optimeerimiseks. Näiteks oskab MS SQL ja Oracle 'jäta vahele' liiteid tabelitesse, kui nende andmeid ei kasutata kuskil mujal, välja arvatud teised liidendid, ja need ei mõjuta viimast valikut (tabeli/liidete eliminatsioon), samas kui MPP Vertica on kolleegide kogemuse põhjal Avitost, näidanud end suurepärasena Ankurmudeli jaoks, arvestades teatavat käsitsi optimeerimist päringu plaanis. Teisest küljest, Ankurmudeli hoidmine näiteks Click House'is, millel on piiratud liidete tugi, tundub praegu mitte väga hea idee.

Lisaks sellele on mõlema arhitektuuri jaoks olemas erilised tehnikad, mis hõlbustavad andmete juurde pääsemist (nii päringute tulemuslikkuse kui ka lõppkasutajate jaoks). Näiteks, Point-In-Time tabelid Data Vaultis või erilised tabelifunktsioonid Ankurmudelis.

Kokkuvõttes

Käsitletud paindlike arhitektuuride peamine olemus seisneb nende 'konstruktsiooni' moodulsuses.

Just see omadus võimaldab:

Pärast teatavat esialgset ettevalmistust, mis on seotud metaandmete rakendamise ja põhiehkne ETL algoritmide kirjutamisega, anda kiiresti kliendile esialgne tulemus paarist aruandest, mis sisaldavad andmeid vaid mõne lähteobjekti kohta. Selleks ei ole vajalik täielikult kavandada (isegi kõrgemal tasemel) kogu objekti mudelit.
Andmemudel võib alustada tööd (ja tuua kasu) vaid kahe-kolme objektiga, seejärel kasvama järk-järgult (seoses Ankurmudeliga, Nikolai kasutas ilusat võrdlust seeneteedega).
Enamik täiendusi, sealhulgas teemaala laienemine ja uute allikate lisamine ei mõjuta olemasolevat funktsionaalsust ja ei tekita ohtu midagi, mis juba töötab, katkestada..
Tänu standardelementide dekompositsioonile näevad ETL-protsessid sellistes süsteemides välja ühtsed, nende kirjutamine on algoritmitav ja lõpuks automaatika.

Selle paindlikkuse hind on tõhusus. See ei tähenda, et sellistes mudelites vastuvõetava efektiivsuse saavutamine oleks võimatu. Enamasti võib teil lihtsalt olla vaja rohkem pingutust ja tähelepanu detailidele, et saavutada soovitud mõõdikud.