Ladustuste arendamine on pikk ja tõsine ettevõtmine.
Projekti elus sõltub palju sellest, kui hästi on objekti mudel ja alusstruktuur alguses läbi mõeldud.
Üldtunnustatud lähenemine on olnud ja jääb täheskeemi mitmesugused kombinatsioonid kolmanda normaalvormiga. Reeglina vastavalt põhimõttele: algandmed - 3NF, vitriinid - täht. See ajaproovitud ja paljude uuringutega toetatud lähenemine on esimene (ja mõnikord ka ainus), mis kogenud DWH spetsialistile pähe tuleb, kui mõelda, milline analüüsihoidla peaks välja nägema.
Teisest küljest kipuvad äri üldiselt ja eelkõige klientide nõudmised kiiresti muutuma, samal ajal kui andmed kasvavad nii „sügavalt” kui ka „laiuselt”. Ja siin ilmneb tähe peamine puudus - piiratud paindlikkus.
Ja kui teie vaikses ja mugavas elus DWH arendajana järsku:
- tekkis ülesanne "teha vähemalt midagi kiiresti ja siis näeme";
- ilmus kiiresti arenev projekt, uute allikate ühendamise ja ärimudeli muutmisega vähemalt kord nädalas;
- ilmus klient, kellel pole õrna aimugi, kuidas süsteem välja peaks nägema ja milliseid funktsioone see lõpuks täitma, kuid on valmis katseteks ja soovitud tulemuse järjepidevaks viimistlemiseks järjepideva lähenemisega sellele;
- projektijuht vaatas sisse rõõmusõnumiga: “Ja nüüd on meil agile!”.
Või kui olete lihtsalt huvitatud sellest, kuidas saaksite hoiuruumi ehitada - tere tulemast kassi juurde!
Mida tähendab "paindlikkus"?
Alustuseks määratleme, millised omadused peavad süsteemil olema, et seda saaks nimetada paindlikuks.
Eraldi väärib märkimist, et kirjeldatud omadused peaksid konkreetselt viitama süsteem, mitte protsessi selle areng. Seega, kui soovite lugeda Agile'i kui arendusmetoodika kohta, on parem lugeda teisi artikleid. Näiteks just seal, Habrel, on palju huvitavaid materjale (nagu и Ja ).
See ei tähenda, et arendusprotsess ja andmelao struktuur on omavahel seotud. Üldiselt peaks agiilse salvestusruumi agiilne arendamine olema palju lihtsam. Praktikas on aga Kimbali ja DataVaulti järgi klassikalise DWH agiilse arenduse puhul rohkem valikuvõimalusi – vastavalt kosele, kui õnnelikud kokkusattumused paindlikkuse kahes vormis ühe projekti puhul.
Niisiis, millised funktsioonid peaksid paindlikul salvestusruumil olema? Siin on kolm punkti:
- Varajane tarne ja kiire valmimine - see tähendab, et ideaaljuhul tuleks esimene äritulemus (näiteks esimesed tööaruanded) saada võimalikult varakult ehk isegi enne kogu süsteemi kavandamist ja juurutamist. Samas peaks iga järgnev läbivaatamine võtma ka võimalikult vähe aega.
- Iteratiivne täpsustamine - see tähendab, et iga järgnev versioon ei tohiks ideaaljuhul mõjutada juba toimivat funktsionaalsust. Just see hetk muutub suurte projektide puhul sageli suurimaks õudusunenäoks – varem või hiljem hakkavad üksikud objektid omandama nii palju seoseid, et lihtsam on loogikat kõrvuti koopias täielikult korrata, kui olemasolevasse tabelisse välja lisada. Ja kui olete üllatunud, et olemasolevate objektide parenduste mõju analüüs võib võtta kauem aega kui läbivaatamine ise, siis tõenäoliselt pole te panganduse või telekommunikatsiooni suurte andmeladudega töötanud.
- Pidev kohanemine muutuvate ärinõuetega - objekti üldine struktuur tuleks kujundada mitte pelgalt võimalikku laiendust arvesse võttes, vaid eeldades, et selle järgmise laienduse suunast ei osatud projekteerimisetapis isegi unistada.
Ja jah, kõigi nende nõuete täitmine ühes süsteemis on võimalik (muidugi teatud juhtudel ja teatud reservatsioonidega).
Allpool käsitlen kahte kõige populaarsemat agiilse disaini metoodikat HD jaoks ankurmudel и Andmehoidla. Sulgudest väljas on sellised suurepärased nipid nagu näiteks EAV, 6NF (puhtal kujul) ja kõik, mis on seotud NoSQL-i lahendustega - mitte sellepärast, et need on kuidagi kehvemad ja isegi mitte sellepärast, et sel juhul ähvardaks artikkel mahu omandada. keskmisest disserist. See kõik viitab lihtsalt veidi erineva klassi lahendustele – kas tehnikatele, mida saad rakendada konkreetsetel juhtudel, olenemata oma projekti üldisest arhitektuurist (nagu EAV), või globaalselt erinevatele infosalvestusparadigmadele (nt graafikuandmebaasid). ja muud valikud). NoSQL).
Klassikalise lähenemise probleemid ja nende lahendused paindlikes metoodikates
"Klassikalise" lähenemise all pean silmas vana head tähte (olenemata aluseks olevate kihtide konkreetsest teostusest, andke andeks Kimballi, Inmoni ja CDM-i järgijad).
1. Seoste jäik kardinaalsus
See mudel põhineb andmete selgel jaotamisel mõõdud (mõõtmed) и faktid (fakt). Ja see, pagan, on loogiline - lõppude lõpuks taandub andmete analüüs valdaval enamusel juhtudel teatud numbriliste näitajate (faktide) analüüsile teatud lõikudes (mõõtmetes).
Samal ajal luuakse objektidevahelised lingid tabelite vaheliste linkide kujul võõrvõtme abil. See tundub üsna loomulik, kuid viib koheselt esimese paindlikkuse piiranguni − suhete kardinaalsuse range määratlus.
See tähendab, et tabelite kujundamise etapis tuleb iga seotud objektide paari puhul määrata, kas neid saab seostada nii palju-mitmele või ainult 1-mitmele ja “mis suunas”. See sõltub otseselt sellest, millisel tabelil on primaarvõti ja millisel võõrvõti. Selle suhte muutmine uute nõuete saabumisel viib suure tõenäosusega baasi ümbertöötamiseni.
Näiteks “kassakviitungi” objekti kujundamisel panid sa müügiosakonna vandetatud kinnitustele toetudes ette tegutsemisvõimaluse üks edutamine mitme kontrollpositsiooni eest (aga mitte vastupidi):
Ja mõne aja pärast tutvustasid kolleegid uut turundusstrateegiat, milles mitu kampaaniat korraga. Ja nüüd peate tabelid viimistlema, tõstes seose eraldi objektis esile.
(Kõik tuletatud objektid, milles promo check liitub, vajavad nüüd ka täiustamist).
Andmehoidla ja ankurmudeli lingid
Sellise olukorra vältimine osutus üsna lihtsaks: müügiosakonda pole vaja usaldada, piisab kõik seosed salvestatakse algselt eraldi tabelitesse ja töödelda sama palju-mitmele.
Seda lähenemisviisi on pakutud Dan Linstedt osana paradigmast Andmehoidla ja täielikult toetatud Lars Rönnbäck в Ankru mudel.
Selle tulemusena saame paindlike metoodikate esimese eripära:
Objektide vahelisi seoseid ei salvestata ülemolemite atribuutidesse, vaid need on omaette tüüpi objektid.
В Andmehoidla selliseid tabeleid nimetatakse on siinja sisse Ankru mudel - tie. Esmapilgul on need väga sarnased, kuigi nende erinevusi ei ammenda nimi (millest tuleb juttu allpool). Mõlemas arhitektuuris saavad linkitabelid linkida suvaline arv üksusi (mitte tingimata 2).
See esmapilgul koondamine annab lõpetamisel olulise paindlikkuse. Selline struktuur muutub tolerantseks mitte ainult olemasolevate linkide kardinaalsuste muutmise, vaid ka uute lisamise suhtes - kui nüüd on tšekipositsioonil ka link selle katki teinud kassapidajaga, on sellise lingi ilmumine lihtsalt pealisehitus. olemasolevate tabelite kohal, mõjutamata olemasolevaid objekte ja protsesse.
2. Andmete dubleerimine
Teine probleem, mille lahendavad paindlikud arhitektuurid, on vähem ilmselge ja esiteks omane. mõõtmised tüüp SCD2 (teise tüübi aeglaselt muutuvad mõõtmised), kuigi mitte ainult neid.
Klassikalises salvestusruumis on dimensioon tavaliselt tabel, mis sisaldab asendusvõtit (PK-na) ning ärivõtmete ja atribuutide komplekti eraldi veergudes.
Kui dimensioon toetab versioonimist, lisatakse standardsele väljade komplektile versiooni ajapiirangud ja hoidlas kuvatakse allika rea kohta mitu versiooni (üks iga versiooniatribuutide muudatuse kohta).
Kui dimensioon sisaldab vähemalt ühte sageli muutuvat versiooniatribuuti, on sellise dimensiooni versioonide arv muljetavaldav (isegi kui teised atribuudid ei ole versioonitud või ei muutu kunagi), ja kui selliseid atribuute on mitu, siis versioonide arv. võib nende arvust plahvatuslikult kasvada. Selline mõõde võib võtta märkimisväärse hulga kettaruumi, kuigi enamik selles salvestatud andmetest on lihtsalt muude ridade muutumatute atribuutide väärtuste duplikaadid.
Samal ajal kasutatakse seda ka sageli denormaliseerimine - mõned atribuudid on tahtlikult salvestatud väärtusena, mitte viitena teatmeteosele või muule dimensioonile. See lähenemisviis kiirendab andmetele juurdepääsu, vähendades dimensioonile juurdepääsul liitumiste arvu.
Tavaliselt toob see kaasa sama info salvestatakse samaaegselt mitmes kohas. Näiteks saab samaaegselt salvestada teavet elukohapiirkonna ja kliendikategooria kuuluvuse kohta dimensioonides “Klient” ja fakte “Ost”, “Kohaletoimetamine” ja “Kontaktid kõnekeskusesse”, samuti linkide tabel “Klient – Kliendihaldur”.
Üldjuhul kehtib ülaltoodu tavaliste (versioonita) mõõtmiste kohta, kuid versioonide puhul võivad need olla erineva skaalaga: objekti uue versiooni ilmumine (eriti tagantjärele mõeldes) toob kaasa mitte ainult kõigi seotud tabelite uuendamise, vaid seotud objektide uute versioonide kaskaadi ilmumisele – kui tabelit 1 kasutatakse tabeli 2 koostamiseks ja tabelit 2 kasutatakse tabeli 3 koostamiseks jne. Isegi kui tabeli 1 koostamisel pole kaasatud ühtegi tabeli 3 atribuuti (ja teistest allikatest saadud tabeli 2 muud atribuudid on kaasatud), toob selle konstruktsiooni versioonide muutmine kaasa vähemalt täiendavaid üldkulusid ja kõige rohkem lisaversioonid tabelis 3, mis on üldiselt "sellega mitte midagi pistmist" ja ahelas edasi.
3. Viimistlemise mittelineaarne keerukus
Samal ajal suurendab iga uus poeleht, mis ehitatakse üksteise peale, kohtade arvu, kus andmed võivad ETL-i muudatuste tegemisel "lahku minna". See omakorda toob kaasa iga järgneva läbivaatamise keerukuse (ja kestuse) suurenemise.
Kui ülaltoodu kehtib harva muudetud ETL-protsessidega süsteemide kohta, võite elada sellises paradigmas – lihtsalt veenduge, et kõik seotud objektid oleksid õigesti tehtud. Kui muudatusi tehakse sageli, suureneb märkimisväärselt tõenäosus, et mitu linki kogemata "kaota jäävad".
Kui lisaks arvestada, et “versioonitud” ETL on palju keerulisem kui “versioonita”, muutub kogu selle majanduse sagedase viimistlemise käigus vigu vältida.
Objektide ja atribuutide salvestamine andmehoidlas ja ankurmudelis
Paindlike arhitektuuride autorite pakutud lähenemisviisi saab sõnastada järgmiselt:
Tuleb eraldada see, mis muutub, sellest, mis jääb muutumatuks. See tähendab võtmete salvestamist atribuutidest eraldi.
Siiski ärge ajage segadusse pole versioonitud atribuut koos muutmata: esimene ei salvesta oma muutumise ajalugu, kuid võib muutuda (näiteks sisestusvea parandamisel või uute andmete saamisel), teine ei muutu kunagi.
Seisukohad selle kohta, mida täpselt võib Data Vault ja Anchor mudelis muutumatuks pidada, erinevad.
Arhitektuuri mõttes Andmehoidla, võib lugeda muutumatuks kogu võtmete komplekt — loomulik (organisatsiooni TIN, tootekood lähtesüsteemis jne) ja asendus. Samal ajal saab ülejäänud atribuudid jagada rühmadesse vastavalt muutuste allikale ja/või sagedusele ning hoidke iga rühma jaoks eraldi tabelit sõltumatu versioonikomplektiga.
Samas paradigmas Ankru mudel loetakse muutmatuks ainult asendusvõti üksused. Kõik muu (kaasa arvatud loomulikud võtmed) on vaid selle atribuutide erijuht. Kus kõik atribuudid on vaikimisi üksteisest sõltumatud, seega tuleb iga atribuudi jaoks luua eraldi laud.
В Andmehoidla kutsutakse olemi võtmeid sisaldavad tabelid Hubami (keskus). Jaoturid sisaldavad alati kindlat väljade komplekti:
- Loodusliku olemi võtmed
- Surrogaatvõti
- Link allikale
- Salvestusaeg
Kirjed sõlmpunktides ei muuda kunagi ega oma versioone. Väliselt on jaoturid väga sarnased ID-kaardi tabelitega, mida mõnes süsteemis kasutatakse surrogaatide genereerimiseks, kuid Data Vault'is on soovitatav surrogaatidena kasutada mitte täisarvude jada, vaid ärivõtmete komplekti räsi. See lähenemine lihtsustab linkide ja atribuutide laadimist allikatest (asendusrühma saamiseks pole vaja jaoturiga liituda, lihtsalt arvutage loomulikust võtmest räsi), kuid see võib põhjustada muid probleeme (nt kokkupõrgete, suur- ja mitte- märkide trükkimine stringivõtmetesse jne .p.), seetõttu pole see üldiselt aktsepteeritud.
Kõik muud olemi atribuudid salvestatakse spetsiaalsetesse tabelitesse, mida nimetatakse Satelliidid (satelliit). Ühel jaoturil võib olla mitu satelliiti, mis salvestavad erinevaid atribuutide komplekte.
Atribuutide jaotus satelliitide vahel toimub vastavalt põhimõttele ühine muutus - ühes satelliidis saab salvestada versioonita atribuute (näiteks üksikisiku sünnikuupäev ja SNILS), teises - harva muutuv versioon (näiteks perekonnanimi ja passi number), kolmandas - sageli muutuvad (näiteks tarneaadress, kategooria, viimase tellimuse kuupäev jne). Versioonide loomine toimub sel juhul üksikute satelliitide, mitte üksuse kui terviku tasemel, seetõttu on soovitatav atribuudid jaotada nii, et versioonide ristumiskoht ühes satelliidis oleks minimaalne (mis vähendab koguarvu salvestatud versioonidest).
Samuti paigutatakse andmete laadimise protsessi optimeerimiseks erinevatest allikatest saadud atribuudid sageli eraldi satelliitidele.
Satelliidid suhtlevad jaoturiga võõrvõti (mis vastab 1-mitmele kardinaalsusele). See tähendab, et see vaikearhitektuur toetab mitut atribuudi väärtust (näiteks sama kliendi mitu kontakttelefoninumbrit).
В Ankru mudel kutsutakse võtmeid salvestavaid tabeleid Ankrud. Ja nad hoiavad:
- Ainult asendusvõtmed
- Link allikale
- Salvestusaeg
Ankrumudeli seisukohast vaadeldakse loomulikke võtmeid tavalised atribuudid. See valik võib tunduda raskemini mõistetav, kuid see annab palju rohkem ruumi objekti tuvastamiseks.
Näiteks kui andmed sama olemi kohta võivad pärineda erinevatest süsteemidest, millest igaüks kasutab oma loomulikku võtit. Andmehoidlas võib see kaasa tuua mitme jaoturi üsna tülika konstruktsiooni (üks allika kohta + ühendav põhiversioon), samas kui Ankru mudelis langeb iga allika loomulik võti oma atribuudi alla ja seda saab kasutada laadimisel sõltumatult kõik teised.
Kuid siin peitub üks salakaval hetk: kui erinevatest süsteemidest pärit atribuudid on ühendatud ühes olemis, siis tõenäoliselt on neid liimireeglid, mille järgi süsteem peab mõistma, et erinevatest allikatest pärinevad kirjed vastavad olemi ühele eksemplarile.
В Andmehoidla need reeglid määravad tõenäoliselt formatsiooni peaüksuse „asenduskeskus”. ega mõjuta mingil moel jaoturid, mis salvestavad allikate loomulikke võtmeid ja nende algseid atribuute. Kui ühel hetkel muutuvad liitmise reeglid (või ühendamisel kasutatavad atribuudid), siis piisab asendusjaoturite uuesti moodustamisest.
В ankurmudel selline üksus tõenäoliselt salvestatakse üksik ankur. See tähendab, et kõik atribuudid, olenemata sellest, millisest allikast need on saadud, seotakse sama surrogaadiga. Ekslikult liidetud kirjete eraldamine ja üldiselt liitmise asjakohasuse jälgimine sellises süsteemis võib olla palju keerulisem, eriti kui reeglid on üsna keerulised ja muutuvad sageli ning sama atribuuti saab hankida erinevatest allikatest (kuigi see on kindlasti võimalik, kuna iga atribuudi versioon säilitab viite oma päritolule).
Igal juhul, kui teie süsteem peaks seda funktsiooni rakendama dubleerimine, kirjete liitmine ja muud MDM-i elemendid, peaksite eriti hoolikalt lugema looduslike võtmete salvestamise aspekte paindlikes metoodikates. Võib-olla on Data Vault'i kohmakam disain ühtäkki liitvigade osas turvalisem.
ankurmudel pakub ka täiendavat objektitüüpi nimega Sõlm tegelikult on see eriline degenereerunud ankrutüüp, mis võib sisaldada ainult ühte atribuuti. Sõlme peaks kasutama kindlate kataloogide (näiteks sugu, perekonnaseis, klienditeeninduse kategooria jne) salvestamiseks. Erinevalt Ankrust, Knot ei ole seotud atribuutide tabeleid, ja selle ainus atribuut (nimi) salvestatakse alati võtmega samasse tabelisse. Sõlmed on ankrutega ühendatud Tietabelitega samal viisil, nagu ankrud on omavahel ühendatud.
Node'ide kasutamise kohta pole ühemõttelist arvamust. Näiteks, , kes propageerib aktiivselt ankrumudeli kasutamist Venemaal, usub (mitte põhjendamatult), et ühe teatmeraamatu kohta on võimatu öelda, et ta alati on staatiline ja ühetasandiline, seega on parem kasutada kõigi objektide jaoks korraga täisväärtuslikku ankrut.
Teine oluline erinevus Data Vaulti ja ankurmudeli vahel on olemasolu linkide atribuudid:
В Andmehoidla Lingid on samad täisväärtuslikud objektid nagu jaoturid ja võivad olla enda atribuudid. Sisse ankurmudel Linke kasutatakse ainult Ankrute ja ei saa olla oma atribuute. See erinevus toob kaasa oluliselt erinevad modelleerimismeetodid. faktid, millest tuleb juttu järgmisena.
Faktide talletamine
Seni oleme rääkinud peamiselt mõõtmiste modelleerimisest. Faktid on veidi vähem selged.
В Andmehoidla tüüpiline faktide talletamise objekt − Link, mille satelliitidele on lisatud reaalsed näitajad.
See lähenemine näib olevat intuitiivne. See tagab lihtsa juurdepääsu analüüsitud näitajatele ja on üldiselt sarnane traditsioonilise faktitabeliga (ainult näitajaid ei salvestata tabelisse endasse, vaid „kõrvaltabelisse“). Kuid on ka lõkse: mudeli üks tüüpilisi täiustusi - faktivõtme laiendamine - muudab selle vajalikuks lingile uue võõrvõtme lisamine. Ja see omakorda "murdab" modulaarsust ja võib potentsiaalselt põhjustada teiste objektide täiustamise vajaduse.
В ankurmudel Lingil ei saa olla oma atribuute, seega selline lähenemine ei tööta – absoluutselt kõik atribuudid ja näitajad peavad olema seotud ühe kindla ankruga. Järeldus sellest on lihtne - iga fakt vajab ka oma ankrut. Mõne asja puhul, mida oleme harjunud faktidena tajuma, võib see tunduda loomulik - näiteks taandub ostu fakt suurepäraselt objektiks „tellimus” või „kviitung”, saidi külastamine taandub seansile jne. Kuid on ka fakte, mille jaoks pole sellist loomulikku “kandeobjekti” nii lihtne leida - näiteks kaubajääk ladudes iga päeva alguses.
Sellest tulenevalt ei teki Ankrumudelis faktivõtme laiendamisel modulaarsusega probleeme (piisab, kui lisada vastavale ankrule uus seos), kuid mudeli kujundamine faktide kuvamiseks on vähem lihtne, võivad ilmuda “kunstlikud” ankrud. mis peegeldavad ettevõtte objektmudelit, pole ilmne.
Kuidas saavutatakse paindlikkus
Saadud konstruktsioon mõlemal juhul sisaldab oluliselt rohkem tabeleidkui traditsiooniline mõõtmine. Aga see võib võtta oluliselt vähem kettaruumi sama versiooniga atribuutide komplektiga kui traditsioonilisel dimensioonil. Loomulikult pole siin maagiat – kõik on normaliseerimises. Jaotades atribuute satelliitide (andmehoidlas) või üksikute tabelite (ankurmudel) vahel, vähendame (või kõrvaldame täielikult) mõne atribuudi väärtuste dubleerimine teiste muutmisel.
eest Andmehoidla võimendus sõltub atribuutide jaotusest satelliitide vahel ja ankurmudel — on peaaegu otseselt võrdeline versioonide keskmise arvuga mõõtmisobjekti kohta.
Ruumi võtmine on aga atribuutide eraldi salvestamise oluline, kuid mitte peamine eelis. Koos linkide eraldi talletamisega muudab see lähenemisviis salvestusruumi modulaarne disain. See tähendab, et nii üksikute atribuutide kui ka täiesti uute teemavaldkondade lisamine sellisesse mudelisse näeb välja selline pealisehitis üle olemasoleva objektide komplekti neid muutmata. Ja just see muudab kirjeldatud metoodikad paindlikuks.
See meenutab ka üleminekut tükktootmiselt masstootmisele - kui traditsioonilises lähenemises on iga mudelitabel unikaalne ja nõuab eraldi tähelepanu, siis paindlike metoodikate puhul on tegemist juba tüüpiliste “detailide” komplektiga. Ühest küljest on tabeleid rohkem, andmete laadimise ja toomise protsessid peaksid välja nägema keerulisemad. Teisest küljest muutuvad nad tüüpiline. See tähendab, et võib olla automatiseeritud ja hallatud metaandmetega. Küsimus "kuidas me selle paneme?", mille vastus võib hõivata olulise osa parenduste kavandamise tööst, pole nüüd lihtsalt seda väärt (nagu ka küsimus mudeli muutmise mõju kohta tööprotsessid).
See ei tähenda, et analüütikuid sellises süsteemis üldse vaja poleks – keegi peab ikkagi atribuutidega objektide komplekti välja töötama ja välja mõtlema, kuhu ja kuidas see kõik laadida. Kuid töö maht, samuti vea tõenäosus ja maksumus vähenevad oluliselt. Nii analüüsi staadiumis kui ka ETL-i väljatöötamise käigus, mida saab olulises osas taandada metaandmete redigeerimisele.
Tume külg
Kõik eelnev muudab mõlemad lähenemisviisid tõeliselt paindlikuks, valmistatavaks ja sobivaks iteratiivseks täiustamiseks. Muidugi on ka “tõrvatünn”, millest arvan, et sa juba tead.
Paindlike arhitektuuride modulaarsuse aluseks olev andmete lagunemine toob kaasa tabelite arvu suurenemise ja sellest tulenevalt pea kohal liitumiste jaoks toomisel. Kõigi dimensiooni atribuutide saamiseks piisab klassikalises salvestusruumis ühest valikust ja paindlik arhitektuur nõuab mitut ühendust. Veelgi enam, kui aruannete jaoks saab kõik need ühendused ette kirjutada, saavad analüütikud, kes on harjunud SQL-i käsitsi kirjutama, kahekordselt kannatama.
On mitmeid fakte, mis muudavad selle olukorra lihtsamaks:
Suurte mõõtmetega töötades ei kasutata peaaegu kunagi peaaegu kõiki selle atribuute korraga. See tähendab, et liitumisi võib olla vähem, kui mudelist esmapilgul tundub. Data Vaultis saate satelliitidele atribuutide määramisel arvestada ka eeldatava jagamise sagedusega. Samal ajal on jaoturid või ankrud ise vajalikud eelkõige surrogaatide genereerimiseks ja kaardistamiseks laadimisetapis ning neid kasutatakse päringutes harva (see kehtib eriti ankrute kohta).
Kõik ühendused on võtmega. Lisaks vähendab "tihendatud" andmete salvestamise viis tabelite skannimise kulusid seal, kus seda vajatakse (näiteks atribuudi väärtuse järgi filtreerimisel). See võib viia tõsiasjani, et toomine normaliseeritud andmebaasist koos hunniku liitudega on isegi kiirem kui ühe raske dimensiooni skannimine, kus rea kohta on palju versioone.
Näiteks siin Artiklis on Anchori mudeli üksikasjalik võrdlev jõudlustest koos valikuga ühest tabelist.
Palju oleneb mootorist. Paljudel kaasaegsetel platvormidel on liitumiste optimeerimiseks sisemised mehhanismid. Näiteks võivad MS SQL ja Oracle tabelite liitumised vahele jätta, kui nende andmeid ei kasutata kuskil peale muude liitumiste ja need ei mõjuta lõplikku valikut (tabeli/liitumise kõrvaldamine), samas kui MPP Vertica , osutus suurepäraseks mootoriks ankrumudeli jaoks, päringuplaani käsitsi optimeerimisega. Teisest küljest ei tundu Anchor Modeli salvestamine näiteks Click House'i, millel on piiratud liitumistoetus, veel hea mõte.
Lisaks on mõlema arhitektuuri jaoks olemas erilised trikid, mis hõlbustavad andmetele juurdepääsu (nii päringu jõudluse kui ka lõppkasutajate jaoks). Näiteks, Point-in-time tabelid Andmehoidlas või spetsiaalsed tabelifunktsioonid ankurmudelis.
Kogusummas
Vaadeldavate paindlike arhitektuuride põhiolemus on nende "disaini" modulaarsus.
See omadus võimaldab:
- Pärast metaandmete juurutamise ja põhiliste ETL-algoritmide kirjutamisega seotud esialgset ettevalmistust, anda kliendile kiiresti esimene tulemus paari aruande kujul, mis sisaldavad andmeid vaid mõnest lähteobjektist. Selleks ei ole vaja kogu objektimudelit lõpuni läbi mõelda (isegi tipptasemel).
- Andmemudel võib hakata töötama (ja kasulik) vaid 2–3 objektiga ja seejärel kasvada järk-järgult (seoses Ankru mudeliga Nikolai ilus võrdlus seeneniidistikuga).
- Enamik täiustusi, sealhulgas teemavaldkonna laiendamine ja uute allikate lisamine ei mõjuta olemasolevat funktsionaalsust ega põhjusta juba töötava asja katki minemise ohtu.
- Tänu standardseteks elementideks lagunemisele näevad ETL-i protsessid sellistes süsteemides välja ühesugused, nende kirjutamine sobib algoritmiseerimiseks ja lõpuks automatiseerimine.
Selle paindlikkuse hind on etendus. See ei tähenda, et selliste mudelite puhul oleks võimatu saavutada vastuvõetavat jõudlust. Enamasti võite soovitud mõõdikute saavutamiseks vajada rohkem pingutust ja tähelepanu detailidele.
Apps
Olemitüübid Andmehoidla
Lisateavet Data Vaulti kohta:
Olemitüübid Ankru mudel
Lisateavet ankrumudeli kohta:
Kokkuvõtlik tabel vaadeldavate lähenemisviiside ühiste tunnuste ja erinevustega:
Allikas: www.habr.com