Data Vault – O prezentare generală

Data Vault este o metodologie inovatoare de modelare a datelor pentru platformele Data Warehouse de mari dimensiuni. Inventată de Dan Linstedt, Data Vault este concepută pentru a furniza un Enterprise Data Warehouse, abordând în același timp dezavantajele tehnicilor de modelare normalizată (a treia formă normală) și dimensională. Aceasta combină depozitul centralizat de date brute al abordării Inmon cu avantajele construcției incrementale ale Kimball.

Acest articol rezumă dezavantajele abordării 3NF și a modelelor dimensionale și enumeră avantajele și dezavantajele abordării Data Vault. În cele din urmă, include link-uri către unele lecturi de fond utile și își propune să răspundă la întrebarea:

Ar trebui să folosesc Data Vault în proiectul meu de Data Warehouse?

Ce problemă încearcă să rezolve Data Vault?

Înainte de a rezuma provocările pe care Data Vault încearcă să le abordeze, merită să luăm în considerare abordarea alternativă de modelare a datelor și arhitecturile de date corespunzătoare. Diagrama de mai jos prezintă o potențială arhitectură de date de întreprindere.

Enterprise Data Warehouse

Cu abordarea EDW, datele sunt încărcate într-o zonă de aterizare tranzitorie, după care se utilizează o serie de procese ETL pentru a încărca datele într-un depozit de date de întreprindere de forma a treia normală. Datele sunt ulterior extrase în marți de date dimensionale pentru analiză și raportare.

Cele mai semnificative dezavantaje ale acestei abordări includ:

1. Timpul de introducere pe piață: Enterprise Data Warehouse trebuie mai întâi să integreze datele din fiecare dintre sistemele sursă într-un depozit central de date înainte ca acestea să fie disponibile pentru raportare, ceea ce adaugă timp și efort la proiect.
2. Complexitate și abilitate: Este posibil ca un depozit de date să trebuiască să integreze date dintr-o sută de surse, iar proiectarea unui model de date la nivel de întreprindere pentru a susține un mediu de afaceri complex este o provocare semnificativă care necesită experți în modelare de date cu înaltă calificare.
4. Lipsa de flexibilitate: Un al treilea model de formă normală tinde să modeleze relațiile de date existente, ceea ce poate produce o soluție relativ inflexibilă care are nevoie de o refacere semnificativă pe măsură ce se adaugă surse suplimentare. Mai rău, experții prea zeloși în modelarea datelor încearcă adesea să depășească acest aspect prin furnizarea unor modele generice prea complexe care sunt aproape imposibil de înțeles.

Abordare de proiectare dimensională

Diagrama de mai jos ilustrează o potențială arhitectură de date pentru o proiectare clasică a unui depozit de date dimensional.

Abordarea de mai sus renunță la EDW pentru a furniza rapid rezultate utilizatorilor finali. Am folosit această tehnică în 2008 la o bancă de investiții de nivel 1 din Londra pentru a furniza evaluări ale riscului de credit utilizatorilor de afaceri în câteva săptămâni de la începerea proiectului. Dacă am fi așteptat să construim un depozit de date tradițional, am fi dat faliment înainte de a livra ceva util.

La început, utilizatorii de afaceri au fost încântați de viteza de livrare; cu toate acestea, în timp, am găsit multe provocări care au devenit din ce în ce mai dureroase de rezolvat. Acestea au inclus:

1. Creșterea complexității codului: Codul ETL (Extract, Transform, and Load) devenea atât de complicat încât nu mai era gestionabil. Înlocuirea instrumentului ETL (Informatica) cu scripturi Oracle a ajutat, (deoarece am simplificat soluția pe parcurs), dar aceasta nu era rădăcina problemei. Încercam să restructurăm datele primite, să deduplicăm, să curățăm și să conformăm datele și să aplicăm reguli de afaceri în schimbare în timp. Efectuarea tuturor acestor pași într-o singură bază de cod a fost într-adevăr foarte dificilă.

2. Lipsa datelor brute: Deoarece zona de aterizare era pur tranzitorie (ștearsă și reîncărcată de fiecare dată), nu aveam o înregistrare istorică a datelor brute. Acest lucru a făcut dificil pentru analiști să descopere noi relații valoroase de date, iar importanța crescândă a științei datelor, care are nevoie (mai presus de toate) de date brute, a fost pur și simplu ignorată.

3. Gestionarea istoricului: Deoarece nu aveam un istoric al datelor brute și încărcam doar atributele necesare pentru analiză, a devenit dificil să alimentăm din nou cu date suplimentare.

4. Liniajul a fost o provocare: Deoarece atât logica tehnică, cât și cea de afaceri a fost implementată în straturi sedimentare din ce în ce mai mari de cod sursă, a fost aproape imposibil să urmărim traseul unui element de date de la raport înapoi la sistemul sursă.

Compania a apreciat viteza inițială de livrare. Cu toate acestea, pe măsură ce trecea timpul, a devenit din ce în ce mai greu de menținut ritmul, deoarece soluția devenea din ce în ce mai complexă, iar regulile de afaceri se schimbau în timp.

Arhitectura Data Vault

Diagrama de mai jos prezintă o potențială arhitectură de date utilizată de metodologia Data Vault.

În timp ce, la prima vedere, pare foarte asemănătoare cu arhitectura Enterprise Data Warehouse de mai sus, aceasta are câteva diferențe și asemănări semnificative, care includ:

• Încărcarea datelor: Pe măsură ce datele sunt încărcate din zona de aterizare în Raw Data Vault, procesul este pur și simplu unul de restructurare a formatului (mai degrabă decât a conținutului) datelor. Datele sursă nu sunt nici curățate, nici modificate, și ar putea fi reconstruite în întregime fără probleme.
• Separarea responsabilităților: Raw Vault deține datele brute nemodificate, iar singura prelucrare este în întregime tehnică, pentru restructurarea fizică a datelor. Regulile de afaceri furnizează tabele și rânduri suplimentare pentru a extinde Raw Vault cu un Business Vault. Aceasta înseamnă că regulile de afaceri sunt atât derivate din datele brute, cât și stocate separat de acestea. Această separare a responsabilităților facilitează gestionarea modificărilor regulilor de afaceri în timp și reduce complexitatea generală a sistemului.
• Reguli de afaceri: Rezultatele regulilor de afaceri, inclusiv dedublarea, rezultatele conforme și chiar calculele sunt stocate la nivel central în Business Vault. Acest lucru ajută la evitarea calculului duplicat și a potențialelor neconcordanțe atunci când rezultatele sunt calculate pentru două sau mai multe marje de date.
• Data Marts: Spre deosebire de metoda Kimball în care rezultatele calculate sunt stocate în tabelele Fact și Dimension din Data Marts, folosind abordarea Data Vault, Data Marts sunt adesea efemere și pot fi implementate ca vizualizări direct peste Business și Raw Vault. Acest lucru înseamnă că sunt mai ușor de modificat în timp și se evită riscul unor rezultate incoerente. Dacă vizualizările nu oferă nivelul de performanță necesar, atunci există opțiunea de a stoca rezultatele într-un tabel.

Vantajele Data Vault

Data Vault abordează dificultățile inerente atât la a treia formă normală a Enterprise Data Warehouse cât și la abordarea Dimensional Design prin combinarea celor mai bune aspecte ale ambelor într-o singură abordare hibridă. Avantajele includ:

1. Livrare incrementală: Deși este rațional să se construiască orice Data Warehouse în contextul unui model general de întreprindere, Data Vault suportă o livrare în întregime incrementală. La fel ca și în cazul abordării de proiectare dimensională a lui Kimball, puteți începe cu dimensiuni mici și puteți adăuga surse suplimentare în mod incremental în timp.

2. Flexibilitate: Spre deosebire de abordarea de modelare a celei de-a treia forme normale, care poate fi inflexibilă, Data Vault nu necesită nicio reelaborare atunci când se adaugă surse suplimentare. Deoarece Data Vault stochează separat datele brute și datele derivate din afaceri, suportă cu ușurință modificări ale regulilor de afaceri.

3. Complexitate redusă: Deoarece Data Vault este construit într-o abordare în doi pași, separă restructurarea datelor tehnice de aplicarea regulilor de afaceri, ceea ce ajută la izolarea acestor etape potențial complexe. În mod similar, curățarea datelor este considerată o regulă de afaceri și poate fi gestionată independent de efortul inițial de încărcare a datelor.

4. Date brute incluse: Înregistrarea datelor brute în Data Vault înseamnă că este posibilă alimentarea din nou a zonei de prezentare cu atribute istorice care nu au fost puse la dispoziție inițial. Dacă Data Marts sunt implementate ca vizualizări, acest lucru poate fi la fel de simplu ca adăugarea unei coloane suplimentare la o vizualizare existentă.

5. Suportă în mod elegant schimbarea în timp: Similar cu dimensiunea care se schimbă lent în abordarea Kimball, Data Vault suportă în mod elegant schimbările în timp. Spre deosebire de designul dimensional pur, însă, Data Vault separă datele brute și datele derivate din afaceri și suportă modificările care rezultă atât din sistemul sursă, cât și din regulile de afaceri.

6. Linie și audit: Deoarece Data Vault include metadate care identifică sistemele sursă, este mai ușor să se susțină liniarizarea datelor. Spre deosebire de abordarea Dimensional Design în care datele sunt curățate înainte de încărcare, modificările Data Vault sunt întotdeauna incrementale, iar rezultatele nu sunt niciodată pierdute, ceea ce oferă o pistă de audit automată.

7. Încărcări paralele de înaltă performanță: Odată cu introducerea cheilor Hash Keys în Data Vault 2.0, dependențele de încărcare a datelor sunt eliminate, ceea ce înseamnă că este posibilă încărcarea datelor aproape în timp real, pe lângă încărcările paralele de terabytes până la petabytes de date.

8. Posibil de automatizat: În timp ce atât modelarea relațiilor între entități (Entity Relationship Modelling), cât și proiectarea dimensională (Dimensional Design) necesită timp și experiență pentru a construi abilități, Data Vault tinde să fie mai ușor de automatizat și există mai multe instrumente (enumerate mai jos) pentru a ajuta la furnizarea soluției.

Dezavantajele Data Vault

Data Vault nu este soluția perfectă și unică pentru fiecare depozit de date și are câteva dezavantaje care trebuie luate în considerare. Printre acestea se numără:

1. Curba de învățare: Exact în același mod în care a treia formă normală, modelarea relațiilor între entități și proiectarea dimensională sunt abilități specifice care necesită timp pentru a fi stăpânite, există o curbă de învățare cu Data Vault. Îmbarcarea într-un proiect de transformare a unui Data Warehouse vine cu riscuri semnificative, iar adăugarea Data Vault poate crește riscul, mai ales dacă această echipă nu are experiență în Data Vault. Asigurați-vă că beneficiați de consiliere și sprijin de specialitate, pe lângă instruirea persoanelor cheie.

2. Multe îmbinări: O proiectare Data Vault prost concepută va produce un număr masiv de tabele derivate din sistemul sursă, dar chiar și o soluție bine concepută înmulțește numărul de tabele sursă de un factor de 2 sau 3. Numărul de tabele și, prin urmare, al îmbinărilor poate părea greoi și poate duce la condiții complexe de îmbinare. Totuși, acest lucru poate fi rezolvat prin utilizarea corectă a tabelelor-punte în Business Vault și, ca în cazul oricărei soluții, este vorba de un compromis între complexitatea aparentă și flexibilitate.

Unde se utilizează Data Vault?

Data Vault necesită o anumită rigoare în realizarea unei bune proiectări și respectarea principiilor Data Vault 2.0. Ca și Enterprise Data Warehouse, este conceput pentru a integra date din mai multe surse de date și, prin urmare, poate fi exagerat în unele situații.

În concluzie, dacă aveți o cerință de analiză de dimensiuni mici sau medii, cu o echipă mică (sub 10) de arhitecți, proiectanți și ingineri care livrează o soluție cu date provenite din câteva sisteme, atunci Data Vault poate fi nepotrivit pentru nevoile dumneavoastră.

Dacă, totuși, aveți un proiect mare, cu 30 sau mai multe sisteme sursă, care duce la o provocare enormă de integrare a datelor și sunteți pregătit să vă asumați competențele și rigoarea unei noi metodologii, atunci Data Vault poate adăuga potențial o valoare masivă proiectului.

Alte resurse și instrumente

Următoarele resurse pot ajuta la evaluarea și înțelegerea metodei Data Vault:

• Kent Graziano (Certified Data Vault Master) are un rezumat al Data Vault care merită să fie citit.
• Genesee Academy (Training) oferă o bună introducere la principiile principale ale Data Vault.
• Firma britanică de consultanță Data Vault oferă un rezumat informativ al Întrebărilor Frecvente (Frequently Asked Questions) care abordează multe dintre preocupările imediate.
• Dan Linstedt are un număr foarte mare de articole aprofundate cu privire la detaliile din jurul Data Vault.
• Building a Scalable Data Warehouse with Data Vault 2.0 – este cartea de referință a lui Dan Linstedt.
• The Elephant in the Fridge – este o introducere accesibilă în Data Vault.

Deși acestea nu ar trebui să fie considerate în nici un fel o recomandare, iată o listă scurtă a instrumentelor care pot ajuta la automatizarea livrării de Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – Un cadru ușor de automatizare open source

Concluzie

Pe măsură ce proiectele de depozite de date on-premise sunt mutate în cloud, un număr din ce în ce mai mare de întreprinderi regândesc modul de arhitectură a depozitului de date. Trecerea de la mai multe silozuri de date independente on-premise la o soluție modernă bazată pe cloud este o oportunitate unică de a integra datele din întreaga întreprindere într-un depozit unic și coerent.

Dacă aceasta este provocarea cu care vă confruntați, atunci Data Vault ar putea foarte bine să vă ajute să oferiți soluția.

Dacă acest articol vi s-a părut util, s-ar putea să vă intereseze site-ul meu personal de blog (absolut zero publicitate), la www.Analytics.Today.

Disclaimer: Opiniile exprimate în articolele mele sunt ale mele și nu le vor reflecta neapărat pe cele ale angajatorului meu (trecut sau prezent) sau chiar ale oricărui client cu care am lucrat.

.