Data Vault – áttekintés

A Data Vault egy innovatív adatmodellezési módszertan nagyméretű adattárház platformokhoz. A Dan Linstedt által kitalált Data Vault célja egy vállalati adattárház létrehozása, miközben kezeli a normalizált (3. normál forma) és a dimenziós modellezési technikák hátrányait. Egyesíti az Inmon megközelítés központosított nyersadattárát a Kimball megközelítés inkrementális építési előnyeivel.

Ez a cikk összefoglalja a 3NF és a dimenziós tervezési megközelítés hátrányait, és felsorolja a Data Vault megközelítés előnyeit és hátrányait. Végül hasznos háttéranyagokra mutató linkeket tartalmaz, és célja, hogy választ adjon a kérdésre:

Kell-e használnom a Data Vaultot az adattárház-projektemben?

Milyen problémát próbál megoldani a Data Vault?

A Data Vault által megoldani próbált kihívások összefoglalása előtt érdemes megvizsgálni az alternatív adatmodellezési megközelítést és a megfelelő adatarchitektúrákat. Az alábbi ábra egy lehetséges vállalati adatarchitektúrát mutat be.

Enterprise Data Warehouse

Az EDW megközelítésnél az adatokat egy átmeneti Landing Area-ba töltik be, majd egy sor ETL folyamat segítségével az adatokat egy 3rd Normal form enterprise data warehouse-ba töltik be. Az adatokat ezt követően dimenziós adatmárkákba vonják ki elemzés és jelentéskészítés céljából.

A megközelítés legjelentősebb hátrányai a következők:

1. Time to Market: A vállalati adattárháznak először integrálnia kell az adatokat az egyes forrásrendszerekből egy központi adattárba, mielőtt a jelentésekhez rendelkezésre állnának, ami növeli a projekt idejét és erőfeszítéseit.
2. Komplexitás és szakértelem: Az adattárháznak esetleg száz forrásból származó adatokat kell integrálnia, és a komplex üzleti környezetet támogató vállalati szintű adatmodell megtervezése jelentős kihívást jelent, amely magasan képzett adatmodellező szakértőket igényel.
3. Rugalmasság hiánya: A harmadik normál formájú modell hajlamos a meglévő adatkapcsolatokat modellezni, ami viszonylag rugalmatlan megoldást eredményezhet, amely további források hozzáadásával jelentős átdolgozást igényel. Ami még rosszabb, hogy a túlbuzgó adatmodellezési szakértők gyakran úgy próbálják ezt áthidalni, hogy túlságosan bonyolult általános modelleket szállítanak, amelyeket szinte lehetetlen megérteni.

Dimenziós tervezési megközelítés

Az alábbi ábra egy klasszikus dimenziós adattárház tervezésének lehetséges adatarchitektúráját mutatja be.

A fenti megközelítés nélkülözi az EDW-t, hogy gyorsan eredményeket szolgáltasson a végfelhasználóknak. Ezt a technikát 2008-ban egy londoni székhelyű, első szintű befektetési banknál használtam arra, hogy a projekt megkezdését követő heteken belül hitelkockázat-értékeléseket nyújtsak az üzleti felhasználóknak. Ha megvártuk volna, hogy hagyományos adattárházat építsünk, csődbe mentünk volna, mielőtt bármi hasznosat szállítottunk volna.

Az üzleti felhasználók kezdetben el voltak ragadtatva a szállítás gyorsaságától; idővel azonban számos kihívást találtunk, amelyek kezelése egyre fájdalmasabbá vált. Ezek közé tartozott:

1. A kód növekvő összetettsége: Az ETL-kód (Extract, Transform, and Load) annyira bonyolulttá vált, hogy már nem volt kezelhető. Az ETL-eszköz (Informatica) Oracle-szkriptekkel való helyettesítése segített (mivel menet közben egyszerűsítettük a megoldást), de nem ez volt a probléma gyökere. Megpróbáltuk átstrukturálni a beérkező adatokat, deduplikálni, megtisztítani és konformizálni az adatokat, valamint idővel változó üzleti szabályokat alkalmazni. Mindezen lépéseket egyetlen kódbázisban elvégezni valóban nagyon nehéz volt.

2. A nyers adatok hiánya: Mivel a leszállási terület tisztán átmeneti volt (minden alkalommal törölték és újratöltötték), nem rendelkeztünk a nyers adatok történeti nyilvántartásával. Ez megnehezítette az elemzők számára az értékes új adatkapcsolatok felfedezését, és az adattudomány növekvő jelentőségét, amelynek (mindenekelőtt) nyers adatokra van szüksége, egyszerűen figyelmen kívül hagyták.

3. Az előzmények kezelése: Mivel nem rendelkeztünk a nyers adatok előzményeivel, és csak az elemzéshez szükséges attribútumokat töltöttük be, nehézzé vált a további adattáplálások visszatöltése.

4. A vonalvezetés kihívást jelentett: Mivel mind a technikai, mind az üzleti logikát a forráskód egyre növekvő üledékrétegeiben valósítottuk meg, szinte lehetetlen volt nyomon követni egy adatelem származását a jelentéstől a forrásrendszerig.

Az üzletág imádta a kezdeti szállítási sebességet. Az idő előrehaladtával azonban egyre nehezebbé vált a tempó fenntartása, mivel a megoldás egyre összetettebbé vált, és az üzleti szabályok idővel megváltoztak.

Data Vault architektúra

Az alábbi ábra a Data Vault módszertan által használt lehetséges adatarchitektúrát mutatja.

Míg első pillantásra nagyon hasonlónak tűnik a fenti Enterprise Data Warehouse architektúrához, van néhány jelentős különbség és hasonlóság, amelyek a következők:

• Adattöltés: Mivel az adatokat a leszállóhelyről töltik be a nyers adattárházba, a folyamat pusztán az adatok formátumának (és nem tartalmának) átstrukturálásáról szól. A forrásadatok nem kerülnek sem tisztításra, sem módosításra, és problémamentesen teljesen rekonstruálhatók.
• A felelősség szétválasztása: A nyers páncélteremben vannak a változatlan nyers adatok, és az egyetlen feldolgozás kizárólag technikai jellegű, az adatok fizikai átstrukturálása. Az üzleti szabályok további táblákat és sorokat szállítanak a nyers trezor üzleti trezorral való bővítéséhez. Ez azt jelenti, hogy az üzleti szabályokat a nyers adatokból származtatják és a nyers adatoktól elkülönítve tárolják. Ez a felelősség szétválasztása megkönnyíti az üzleti szabályok idővel történő módosításainak kezelését, és csökkenti a rendszer általános összetettségét.
• Üzleti szabályok: Az üzleti szabályok eredményei, beleértve a deduplikációt, a konform eredményeket és még a számításokat is, központilag az üzleti trezorban tárolódnak. Ez segít elkerülni a duplikált számításokat és az esetleges következetlenségeket, amikor az eredményeket két vagy több adatmárta számára számítják ki.
• Adatmárkák: A Kimball-módszertől eltérően, amelyben a számított eredményeket az adatmárkák Fact és Dimension tábláiban tárolják, az Data Vault megközelítéssel az adatmárkák gyakran efemerek, és közvetlenül a Business és Raw Vault felett nézetekként valósíthatók meg. Ez azt jelenti, hogy idővel könnyebben módosíthatók, és elkerülhető az inkonzisztens eredmények kockázata. Ha a nézetek nem biztosítják a szükséges teljesítményszintet, akkor lehetőség van az eredmények táblázatban történő tárolására.

A Data Vault előnyei

A Data Vault a 3. normál formájú vállalati adattárház és a dimenziótervezés megközelítésében rejlő nehézségeket úgy kezeli, hogy a kettő legjobb aspektusait egyetlen hibrid megközelítésben egyesíti. Az előnyök a következők:

1. Inkrementális szállítás: Bár minden adattárházat egy átfogó vállalati modell kontextusában célszerű felépíteni, a Data Vault támogatja a teljesen inkrementális szállítást. A Kimball Dimensional Design megközelítéséhez hasonlóan kicsiben kezdheti, és idővel fokozatosan hozzáadhat további forrásokat.

2. Rugalmasság: A 3. normálforma modellezési megközelítéssel ellentétben, amely rugalmatlan lehet, a Data Vault nem igényel átdolgozást további források hozzáadásakor. Mivel a Data Vault külön tárolja a nyers és az üzleti származtatott adatokat, könnyedén támogatja az üzleti szabályok módosítását.

3. Csökkentett komplexitás: Mivel a Data Vault kétlépcsős megközelítésben épül fel, elválasztja a technikai adatátstrukturálást az üzleti szabályok alkalmazásától, ami segít elkülöníteni ezeket a potenciálisan összetett szakaszokat. Hasonlóképpen, az adattisztítás üzleti szabálynak minősül, és a kezdeti adatbetöltési erőfeszítéstől függetlenül kezelhető.

4. Nyers adatokat tartalmaz: A nyers adatok Data Vaultban történő rögzítése azt jelenti, hogy a prezentációs területet vissza lehet tölteni olyan múltbeli attribútumokkal, amelyeket eredetileg nem tettek elérhetővé. Ha az adatmárkák nézetként vannak megvalósítva, ez olyan egyszerű lehet, mint egy további oszlop hozzáadása egy meglévő nézethez.

5. Elegánsan támogatja az időbeli változásokat: A Kimball megközelítés lassan változó dimenziójához hasonlóan a Data Vault elegánsan támogatja az időbeli változásokat. A tiszta dimenziótervezéstől eltérően azonban a Data Vault szétválasztja a nyers és az üzleti származtatott adatokat, és támogatja mind a forrásrendszerből, mind az üzleti szabályokból eredő változásokat.

6. Vonalvezetés és ellenőrzés: Mivel a Data Vault tartalmazza a forrásrendszereket azonosító metaadatokat, megkönnyíti az adatok vonalvezetésének támogatását. A dimenziótervezési megközelítéssel ellentétben, amelyben az adatokat betöltés előtt megtisztítják, a Data Vault módosításai mindig inkrementálisak, és az eredmények soha nem vesznek el, ami automatikus ellenőrzési nyomvonalat biztosít.

7. Nagy teljesítményű párhuzamos betöltések: A Hash Keys bevezetésével a Data Vault 2.0-ban megszűnnek az adatbetöltési függőségek, ami azt jelenti, hogy a terabájtos és petabájtos adatok párhuzamos betöltése mellett közel valós idejű adatbetöltés is lehetséges.

8. Automatizálható: Míg mind az Entity Relationship Modelling, mind a Dimensional Design készségek kiépítéséhez időre és tapasztalatra van szükség, a Data Vault általában könnyebben automatizálható, és számos (alább felsorolt) eszköz segíti a megoldás megvalósítását.

A Data Vault hátrányai

A Data Vault nem a tökéletes, minden adattárháznak megfelelő megoldás, és van néhány hátránya, amelyet figyelembe kell venni. Ezek közé tartozik:

1. A tanulási görbe: Pontosan ugyanúgy, ahogy a 3. normálforma, az entitáskapcsolat-modellezés és a dimenziótervezés olyan speciális készségek, amelyek elsajátításához időre van szükség, a Data Vault esetében is van tanulási görbe. Az adattárház átalakítási projektbe való belevágás jelentős kockázatokkal jár, és a Data Vault hozzáadása növelheti a kockázatot, különösen, ha a csapat nem rendelkezik Data Vault-tapasztalattal. Győződjön meg róla, hogy a kulcsfontosságú személyek képzése mellett szakértői tanácsadással és támogatással is rendelkezik.

2. Sok Joins: Egy rosszul megtervezett Data Vault-tervezés rengeteg forrásrendszeri származtatott táblát eredményez, de még egy jól megtervezett megoldás is kétszeresére vagy háromszorosára növeli a forrástáblák számát. A táblák és így az illesztések száma nehézkesnek tűnhet, és összetett illesztési feltételekhez vezethet. Ez azonban kezelhető a Business Vaultban található hídtáblák megfelelő használatával, és mint minden megoldás esetében, itt is a látszólagos bonyolultság és a rugalmasság közötti kompromisszumot kell kötni.

Hol használjuk a Data Vaultot?

A Data Vault némi szigort igényel a jó tervezés megvalósításában és a Data Vault 2.0 alapelveinek betartásában. Az Enterprise Data Warehouse-hoz hasonlóan több adatforrásból származó adatok integrálására tervezték, ezért bizonyos helyzetekben túlzásba eshet.

Összefoglalva, ha kis vagy közepes analitikai igénye van, és egy kis (10 fő alatti) építész, tervező és mérnöki csapat néhány rendszerből származó adatokkal szállít megoldást, akkor a Data Vault nem biztos, hogy megfelel az Ön igényeinek.

Ha azonban nagy projektje van 30 vagy több forrásrendszerrel, ami hatalmas adatintegrációs kihívást jelent, és hajlandó egy új módszertan készségeit és szigorát vállalni, akkor a Data Vault potenciálisan hatalmas értéket adhat a projekthez.

Egyéb források és eszközök

A Data Vault módszer értékelését és megértését a következő források segíthetik:

• Kent Graziano (minősített Data Vault Master) összefoglalóját érdemes elolvasni a Data Vaultról.
• A Genesee Academy (képzés) jó bevezetést nyújt a Data Vault fő elveibe.
• UK Consultancy Data Vault Provide an informative summary of Frequently Asked Questions that addressing many of the immediate concerns.
• Dan Linstedt rengeteg mélyreható cikket tartalmaz a Data Vault körüli részletekről.
• Building a Scalable Data Warehouse with Data Vault 2.0 – a Dan Linstedt által írt referencia könyv.
• The Elephant in the Fridge – a Data Vault közérthető bevezetése.

Noha ezek semmiképpen sem tekinthetők ajánlásnak, íme egy rövid lista azokról az eszközökről, amelyek segíthetnek a Data Vault szállításának automatizálásában.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – Egy könnyű, nyílt forráskódú automatizálási keretrendszer

Következtetés

Amint a helyhez kötött adattárházi projektek a felhőbe kerülnek, egyre több vállalat gondolja újra az adattárház architektúráját. A több független, helyben lévő adatsilóról egy modern felhőalapú megoldásra való áttérés egyszeri lehetőséget kínál arra, hogy az egész vállalatból származó adatokat egyetlen, egységes adattárba integrálják.

Ha ez az a kihívás, amellyel Ön szembesül, akkor a Data Vault segíthet a megoldás megvalósításában.

Ha hasznosnak találta ezt a cikket, talán érdekli személyes blogoldalam (teljesen reklámmentes), a www.Analytics.Today.

Disclaimer: A cikkeimben kifejtett vélemény a sajátom, és nem feltétlenül tükrözi munkáltatóm (korábbi vagy jelenlegi) véleményét, vagy akár egyetlen ügyfélét sem, akivel együtt dolgoztam.