DATA VAULT’i arendamine ja üleminek BUSINESS DATA VAULT’ile

Eelmises artiklis rääkisin DATA VAULTi põhialustest, kirjeldasin DATA VAULTi põhielemente ja nende eesmärke. Kuid teema DATA VAULT ei ole ammendatud, on oluline arutada järgmisi samme DATA VAULTi evolutsioonis.

Selles artiklis keskendun DATA VAULTi arengule ja üleminekule BUSINESS DATA VAULTile ehk lihtsalt BUSINESS VAULTile.

BUSINESS DATA VAULTi tekkimise põhjused

Oluline on märkida, et kuigi DATA VAULTil on teatud tugevused, ei ole tal vähetähtsaid puudusi. Üks neist puudustest on analüüsipäringute kirjutamise keerukus. Päringutes on märkimisväärne hulk JOIN'e, mistõttu kood muutub pikaks ja mahukaks. Samuti ei toimu DATA VAULTis sisalduvate andmete puhul mingeid muundurite rakendamist, seega ei oma DATA VAULT puhtal kujul äri seisukohalt absoluutset väärtust.

Just nende puuduste kõrvaldamiseks on DATA VAULTi metodoloogiat laiendatud selliste elementidega nagu:

• PIT (point in time) tabelid;
• BRIDGE tabelid;
• PREDEFINED DERIVATIONS.

Vaatame neid elemente lähemalt.

PIT tabelid

Tavaliselt võib ühe ärilise objekti (HUB) koostises olla andmeid erineva värskendussagedusega. Näiteks, kui räägime inimese iseloomustavatest andmetest, siis võime öelda, et telefoninumber, aadress või e-posti aadress muutuvad sagedamini kui näiteks nimi, passiandmed, perekonnaseis või sugu.

Seetõttu tuleb satelliitide määramisel arvestada nende värskendussagedust. Miks see on oluline?

Kui ühes tabelis hoida atribuute erineva värskendussagedusega, tuleb iga kord, kui kõige sagedamini muutuva atribuudi väärtus uuendatakse, tabelisse rida lisada. Selle tagajärjel suureneb kettaruumi maht ja päringute täitmise aeg.

Nüüd, kui oleme satelliidid värskendussageduse kaupa jaganud ja saame andmeid laadida sõltumatult, tuleb tagada võimalus saada ajakohaseid andmeid. Parim on teha seda ilma liigsete JOIN'ide kasutamiseta.

Selgitame, et näiteks on vajalik saada ajakohast (viimase värskenduse kuupäeva järgi) teavet satelliitidelt, millel on erinev värskenduse sagedus. Selleks on vajalik mitte ainult JOIN teostamine, vaid ka mitme sisemist päringute loomine (iga satelliidi kohta, mis sisaldab teavet) maksimaalse värskenduse kuupäeva MAX(Värskenduse kuupäev) valimisega. Iga uue JOIN'iga kasvab selline kood ja muutub kiiresti arusaamatuks.

PIT tabel on mõeldud selliste päringute lihtsustamiseks; PIT tabelid täidetakse samal ajal uute andmete salvestamisega DATA VAULT'i. PIT tabel:

Nii on meil teave andmete asjakohasuse kohta kõikide satelliitide kohta igal ajahetkel. Kasutades JOIN'e PIT tabeliga, saame täielikult vältida sisemisi päringuid, tingimusel et PIT täidetakse iga päev ja ilma vahepealseteta. Isegi kui PIT'is on vahepealseid andmete puudusi, on ajakohaste andmete saamiseks piisav ainult ühe sisemise päringu kasutamine PIT-i juurde. Üks sisemine päring töötab kiiremini kui sisemised päringud iga satelliidi kohta.

BRIDGE

BRIDGE tüüpi tabelid aitavad samuti analüütiliste päringute lihtsustamisel. Kuid erinevalt PIT-ist on need vahendiks, mis lihtsustab ja kiirendab päringute tegemist erinevate hubide, linkide ja nende satelliitide vahel.

Tabel sisaldab kõiki vajalikke võtmeid kõigi satelliitide jaoks, mis sageli esinevad päringutes. Lisaks võivad vajadusel hajutatud ärivõtmed olla täiendatud tekstivormingus võtmetega, kui võtmete nimetused on analüüsiks vajalikud.

Asi on selles, et ilma BRIDGE'i kasutamiseta on erinevate hubide satelliitide andmete saamisel vajalik teostada JOIN mitte ainult satelliitide endi, vaid ka linkide vahel, mis ühendavad hubid.

BRIDGE'i olemasolu või puudumine sõltub andmete ladustamise konfiguratsioonist ja päringute täitmise kiirusest. Üksikut BRIDGE'i näidet on keeruline välja mõelda.

EELMÄÄRATUD TULETUSED

Üks veel objekti tüüp, mis toob meid lähemale BUSINESS DATA VAULT'ile, on tabelid, mis sisaldavad eelnevalt arvutatud näitajaid. Need tabelid on äri jaoks tõeliselt olulised, sest nad sisaldavad teavet, mis on koondatud antud reeglite järgi, ja võimaldavad sellele suhteliselt lihtsalt juurde pääseda.

Arhitektuuriliselt PREDEFINED DERIVATIONS esindavad nad mitte midagi muud kui veel üht satelliiti teatud hub'i ümber. Nagu tavaline satelliit sisaldab see äri võtit ja kirje loomise kuupäeva satelliidis. Siinkohal lõpevad sarnasused. Sellise „spetsialiseeritud“ satelliidi atribuutide edasine koosseis määratakse äri kasutajate poolt, tuginedes kõige nõutuimatele eelnevalt arvutatud näitajatele.

Näiteks, hub, mis sisaldab teavet töötaja kohta, võib sisaldada satelliiti selliste näitajatega nagu:

• Minimaalne palk;
• Maksimaalne palk;
• Keskmine palk;
• Kogusumma arvutatud palgast jne.

On loogiline lisada PREDEFINED DERIVATIONS selle sama hub'i PIT tabelisse, et oleks lihtne saada andmevälju töötaja kohta valitud kuupäeval.

KOKKUVÕTE

Kuidas praktika näitab, et DATA VAULTi kasutamine äri kasutajate poolt on mitmel põhjusel keeruline:

• Koodi päringud on keerukad ja mahukad;
• Rohkus JOIN'e mõjutab päringute jõudlust;
• Analüütiliste päringute kirjutamiseks on vajalik erakordne teadmiste tase andmete ladustamise struktuurist.

Juurdepääsu lihtsustamiseks laiendatakse DATA VAULTi täiendavate objektidega:

• PIT (point in time) tabelid;
• BRIDGE tabelid;
• PREDEFINED DERIVATIONS.

Järgmisel artiklis Kavan, et rääkida, minu arvates, kõige huvitavamast, neile, kes töötavad BI'ga. Tutvustan, kuidas luua faktitabelite ja mõõtmetabelite aluseid DATA VAULTist.

Artikli materjalid põhinevad:

• VDS-l on võimalik installida: avalikustamist Kenta Graciano artikkel, kus on lisaks põhjalikule kirjeldusele ka mudeli skeemid;
• Raamatul: 'Building a Scalable Data Warehouse with DATA VAULT 2.0';
• Artikkel Data Vaulti alused.

Allikas: habr.com