Data Vault – An Overview

Data Vault jest innowacyjną metodologią modelowania danych dla platform Hurtowni Danych o dużej skali. Wynaleziona przez Dana Linstedta, Data Vault została zaprojektowana w celu dostarczenia korporacyjnej Hurtowni Danych, jednocześnie rozwiązując wady technik normalizacji (3rd normal form) i modelowania wymiarowego. Łączy w sobie scentralizowane repozytorium danych surowych podejścia Inmon z zaletami przyrostowego budowania Kimball.

Ten artykuł podsumowuje wady podejścia 3NF i Dimensional Design oraz wymienia zalety i wady podejścia Data Vault. Na koniec zawiera odnośniki do kilku przydatnych lektur pomocniczych i ma na celu odpowiedzieć na pytanie:

Czy powinienem użyć Data Vault w moim projekcie hurtowni danych?

Jaki problem próbuje rozwiązać Data Vault?

Przed podsumowaniem wyzwań, które Data Vault próbuje rozwiązać, warto rozważyć alternatywne podejście do modelowania danych i odpowiadające im architektury danych. Poniższy diagram przedstawia potencjalną korporacyjną architekturę danych.

Enterprise Data Warehouse

W przypadku podejścia EDW dane są ładowane do przejściowego Landing Area, po czym seria procesów ETL jest wykorzystywana do załadowania danych do korporacyjnej hurtowni danych o trzeciej normalnej formie. Dane są następnie ekstrahowane do wymiarowych data marts do analizy i raportowania.

Najważniejsze wady tego podejścia obejmują:

1. Time to Market: Enterprise Data Warehouse musi najpierw zintegrować dane z każdego z systemów źródłowych do centralnego repozytorium danych, zanim będą one dostępne do raportowania, co dodaje czasu i wysiłku do projektu.
2. Złożoność i umiejętności: Hurtownia danych może wymagać zintegrowania danych ze stu źródeł, a zaprojektowanie modelu danych obejmującego całe przedsiębiorstwo w celu obsługi złożonego środowiska biznesowego jest znaczącym wyzwaniem, które wymaga wysoko wykwalifikowanych ekspertów od modelowania danych.
3. Brak elastyczności: Model trzeciej postaci normalnej ma tendencję do modelowania istniejących relacji danych, co może skutkować stosunkowo mało elastycznym rozwiązaniem, które wymaga znacznych przeróbek w miarę dodawania kolejnych źródeł. Co gorsza, nadgorliwi eksperci od modelowania danych często próbują przezwyciężyć ten problem, dostarczając zbyt skomplikowane modele ogólne, które są prawie niemożliwe do zrozumienia.

Podejście do projektowania wymiarowego

Niżej przedstawiony diagram ilustruje potencjalną architekturę danych dla klasycznego projektu wymiarowej hurtowni danych.

Powyższe podejście rezygnuje z EDW, aby szybko dostarczyć wyniki użytkownikom końcowym. Użyłem tej techniki w 2008 roku w londyńskim banku inwestycyjnym, aby dostarczyć użytkownikom biznesowym oceny ryzyka kredytowego w ciągu kilku tygodni od rozpoczęcia projektu. Gdybyśmy czekali na zbudowanie tradycyjnej hurtowni danych, zbankrutowalibyśmy, zanim dostarczylibyśmy cokolwiek użytecznego.

Początkowo użytkownicy biznesowi byli zachwyceni szybkością dostarczania wyników; jednak z czasem napotkaliśmy wiele wyzwań, które stawały się coraz bardziej bolesne. Należały do nich:

1. Rosnąca złożoność kodu: Kod ETL (Extract, Transform, and Load) stawał się tak skomplikowany, że nie można już było nim zarządzać. Zastąpienie narzędzia ETL (Informatica) skryptami Oracle pomogło, (ponieważ uprościliśmy rozwiązanie w miarę postępu prac), ale to nie było źródło problemu. Próbowaliśmy zrestrukturyzować przychodzące dane, deduplikować, oczyścić i ujednolicić dane oraz zastosować zmieniające się w czasie reguły biznesowe. Wykonanie wszystkich tych kroków w jednej bazie kodu było naprawdę bardzo trudne.

2. Brak surowych danych: Ponieważ obszar lądowania był czysto przejściowy (usuwany i ładowany ponownie za każdym razem), nie mieliśmy historycznego zapisu surowych danych. Utrudniało to analitykom odkrywanie nowych, wartościowych zależności między danymi, a rosnące znaczenie Data Science, która (przede wszystkim) potrzebuje surowych danych, było po prostu ignorowane.

3. Zarządzanie historią: Ponieważ nie mieliśmy historii surowych danych i ładowaliśmy tylko atrybuty potrzebne do analizy, trudne stało się wsteczne zasilanie dodatkowymi danymi.

4. Lineage stanowiło wyzwanie: Ponieważ zarówno logika techniczna, jak i biznesowa była zaimplementowana w coraz to większych warstwach osadowych kodu źródłowego, śledzenie pochodzenia pozycji danych z raportu z powrotem do systemu źródłowego było prawie niemożliwe.

Biznes uwielbiał początkową szybkość dostarczania danych. Jednak w miarę upływu czasu coraz trudniej było utrzymać to tempo, ponieważ rozwiązanie stawało się coraz bardziej złożone, a reguły biznesowe zmieniały się w czasie.

Architektura Data Vault

Poniższy diagram przedstawia potencjalną architekturę danych wykorzystywaną przez metodologię Data Vault.

Mimo że na pierwszy rzut oka wygląda ona bardzo podobnie do powyższej architektury korporacyjnej hurtowni danych, ma kilka istotnych różnic i podobieństw, do których należą:

• Ładowanie danych: Gdy dane są ładowane z obszaru lądowania do skarbca danych surowych, proces ten polega wyłącznie na restrukturyzacji formatu (a nie zawartości) danych. Dane źródłowe nie są ani czyszczone, ani modyfikowane i mogą być całkowicie zrekonstruowane bez problemu.
• Rozdzielenie odpowiedzialności: Raw Vault przechowuje niezmodyfikowane dane surowe, a jedyne przetwarzanie jest całkowicie techniczne, aby fizycznie zrestrukturyzować dane. Reguły biznesowe dostarczają dodatkowych tabel i wierszy w celu rozszerzenia skarbca surowego o skarbiec biznesowy. Oznacza to, że reguły biznesowe są zarówno wyprowadzane, jak i przechowywane oddzielnie od danych surowych. Takie rozdzielenie odpowiedzialności ułatwia zarządzanie zmianami reguł biznesowych w czasie i zmniejsza ogólną złożoność systemu.
• Reguły biznesowe: Wyniki reguł biznesowych, w tym deduplikacja, zgodne wyniki, a nawet obliczenia, są przechowywane centralnie w Business Vault. Pomaga to uniknąć duplikatów obliczeń i potencjalnych niespójności, gdy wyniki są obliczane dla dwóch lub więcej data marts.
• Data Marts: W przeciwieństwie do metody Kimballa, w której obliczone wyniki są przechowywane w tabelach Fact i Dimension w Data Marts, przy zastosowaniu podejścia Data Vault, Data Marts są często efemeryczne i mogą być zaimplementowane jako widoki bezpośrednio nad Business i Raw Vault. Oznacza to, że są one zarówno łatwiejsze do modyfikacji w czasie, jak i unikają ryzyka niespójnych wyników. Jeśli widoki nie zapewniają niezbędnego poziomu wydajności, istnieje możliwość przechowywania wyników w tabeli.

Zalety Data Vault

Data Vault odnosi się do trudności związanych zarówno z 3. formą normalną korporacyjnej hurtowni danych, jak i podejściem Dimensional Design, łącząc najlepsze aspekty obu w jednym hybrydowym podejściu. Zalety obejmują:

1. Dostarczanie przyrostowe: Chociaż rozsądnie jest budować każdą Hurtownię Danych w kontekście ogólnego modelu przedsiębiorstwa, Data Vault wspiera całkowicie przyrostowe dostarczanie danych. Podobnie jak w przypadku podejścia Kimball’s Dimensional Design, można zacząć od małego i z czasem przyrostowo dodawać kolejne źródła.

2. Elastyczność: W przeciwieństwie do podejścia modelowania 3rd Normal Form, które może być nieelastyczne, Data Vault nie wymaga żadnych przeróbek przy dodawaniu dodatkowych źródeł. Ponieważ Data Vault przechowuje oddzielnie dane surowe i dane pochodne, z łatwością obsługuje zmiany reguł biznesowych.

3. Zmniejszona złożoność: Ponieważ Data Vault jest zbudowany w podejściu dwuetapowym, oddziela techniczną restrukturyzację danych od zastosowania reguł biznesowych, co pomaga odizolować te potencjalnie skomplikowane etapy. Podobnie, czyszczenie danych jest traktowane jako reguła biznesowa i może być zarządzane niezależnie od początkowego wysiłku ładowania danych.

4. Uwzględnienie surowych danych: Zapisywanie surowych danych w Data Vault oznacza, że możliwe jest wsteczne wypełnianie obszaru prezentacji atrybutami historycznymi, które nie zostały początkowo udostępnione. Jeśli Data Marts są zaimplementowane jako widoki, może to być tak proste, jak dodanie dodatkowej kolumny do istniejącego widoku.

5. Elegancko obsługuje zmiany w czasie: Podobnie jak powoli zmieniający się wymiar w podejściu Kimballa, Data Vault elegancko wspiera zmiany w czasie. W przeciwieństwie jednak do czystego Dimensional Design, Data Vault oddziela dane surowe od danych pochodnych i obsługuje zmiany wynikające zarówno z systemu źródłowego, jak i reguł biznesowych.

6. Lineage i Audyt: Ponieważ Data Vault zawiera metadane identyfikujące systemy źródłowe, ułatwia wspieranie liniowości danych. W przeciwieństwie do podejścia Dimensional Design, w którym dane są czyszczone przed załadowaniem, zmiany w Data Vault są zawsze przyrostowe, a wyniki nigdy nie są tracone, co zapewnia automatyczną ścieżkę audytu.

7. Wysokowydajne ładowanie równoległe: Wraz z wprowadzeniem Hash Keys w Data Vault 2.0, zależności związane z ładowaniem danych zostały wyeliminowane, co oznacza, że ładowanie danych w czasie niemal rzeczywistym jest możliwe oprócz równoległego ładowania terabajtów do petabajtów danych.

8. Możliwość automatyzacji: Podczas gdy zarówno Entity Relationship Modelling, jak i Dimensional Design wymagają czasu i doświadczenia, aby zbudować umiejętności, Data Vault ma tendencję do łatwiejszego automatyzowania, a istnieje kilka narzędzi (wymienionych poniżej), które pomagają dostarczyć rozwiązanie.

Wady Data Vault

Data Vault nie jest idealnym, uniwersalnym rozwiązaniem dla każdej hurtowni danych i ma kilka wad, które należy rozważyć. Należą do nich:

1. Krzywa uczenia się: W dokładnie taki sam sposób, w jaki 3rd Normal Form, Entity Relationship Modelling i Dimensional Design są specyficznymi umiejętnościami, których opanowanie wymaga czasu, istnieje krzywa uczenia się z Data Vault. Rozpoczęcie projektu transformacji Hurtowni Danych wiąże się z poważnym ryzykiem, a dodanie Data Vault może je zwiększyć, zwłaszcza jeśli zespół nie ma doświadczenia w Data Vault. Upewnij się, że masz fachową poradę i wsparcie, a także szkolenia dla kluczowych osób.

2. Mnóstwo złączeń: Źle zaprojektowany projekt Data Vault wytworzy ogromną liczbę tabel pochodnych systemu źródłowego, ale nawet dobrze zaprojektowane rozwiązanie mnoży liczbę tabel źródłowych przez współczynnik 2 lub 3. Liczba tabel, a więc i złączeń, może wydawać się nieporęczna i prowadzić do skomplikowanych warunków złączenia. Można temu jednak zaradzić poprzez prawidłowe wykorzystanie tabel pomostowych w Business Vault, i jak w przypadku każdego rozwiązania, jest to kompromis pozornej złożoności i elastyczności.

Gdzie stosować Data Vault?

Data Vault wymaga pewnego rygoru w dostarczaniu dobrego projektu i trzymania się zasad Data Vault 2.0. Podobnie jak hurtownia danych Enterprise Data Warehouse, został zaprojektowany do integracji danych z wielu źródeł danych i dlatego w niektórych sytuacjach może być zbyteczny.

Podsumowując, jeśli masz małe lub średnie wymagania analityczne, z małym (poniżej 10) zespołem architektów, projektantów i inżynierów dostarczających rozwiązanie z danymi pochodzącymi z kilku systemów, to Data Vault może być nieodpowiedni dla Twoich potrzeb.

Jeśli jednak masz duży projekt z 30 lub więcej systemami źródłowymi prowadzący do ogromnego wyzwania związanego z integracją danych i jesteś przygotowany na przyjęcie umiejętności i rygorów nowej metodologii, wtedy Data Vault może potencjalnie dodać ogromną wartość do projektu.

Inne zasoby i narzędzia

Następujące zasoby mogą pomóc w ocenie i zrozumieniu metody Data Vault:

• Kent Graziano (certyfikowany Data Vault Master) ma podsumowanie Data Vault warte przeczytania.
• Akademia Genesee (szkolenie) zapewnia dobre wprowadzenie do głównych zasad Data Vault.
• Brytyjska firma konsultingowa Data Vault udostępnia pouczające podsumowanie często zadawanych pytań, które dotyczą wielu bezpośrednich obaw.
• Dan Linstedt ma ogromną liczbę dogłębnych artykułów na temat szczegółów związanych z Data Vault.
• Building a Scalable Data Warehouse with Data Vault 2.0 – jest książką referencyjną autorstwa Dana Linstedta.
• The Elephant in the Fridge – jest przystępnym wprowadzeniem do Data Vault.

Chociaż nie należy ich w żaden sposób traktować jako rekomendacji, oto krótka lista narzędzi, które mogą pomóc w zautomatyzowaniu dostarczania Data Vault.

• dbtvault
• Wherescape
• VaultSpeed
• Data Vault Builder
• Joyn – A lightweight open source automation framework

Conclusion

As on-premise data warehouse projects are moved to the cloud, coraz większa liczba przedsiębiorstw ponownie zastanawia się nad tym, jak zbudowana jest hurtownia danych. Przejście z wielu niezależnych silosów danych on-premise do nowoczesnego rozwiązania opartego na chmurze jest jedyną w swoim rodzaju okazją do zintegrowania danych z całego przedsiębiorstwa w jednym, spójnym repozytorium.

Jeśli to jest wyzwanie, przed którym stoisz, to Data Vault może pomóc dostarczyć rozwiązanie.

Jeśli uznałeś ten artykuł za pomocny, możesz być zainteresowany moją osobistą stroną blogową (absolutnie zero reklam), pod adresem www.Analytics.Today.

Zastrzeżenie: Opinie wyrażone w moich artykułach są moje własne i niekoniecznie odzwierciedlają opinie mojego pracodawcy (przeszłego lub obecnego) lub jakiegokolwiek klienta, z którym pracowałem.