Zarządzanie projektem opartym na architekturze Data Vault

Projekty stricte bazodanowe wciąż postrzegane są jako „generyczne” – powtarzalne, proste, a czasem po prostu nudne. Osobom patrzącym z zewnątrz, lub tylko pobieżnie obserwującym warstwę danych, może się wydawać, że każdy tego typu projekt jest taki sam. Nic bardziej mylnego! Tezę tę udowodnię na przykładzie projektu opartego o niezwykle ciekawą architekturę stworzoną w myśl metodyki Data Vault. 

Zarządzanie tradycyjnym projektem bazodanowym

Zanim jednak przejdziemy do spraw związanych ściśle z Data Vault, warto przyjrzeć się specyfice zarządzania projektami bazodanowymi. Projekty te (jak i tzw. „okołobazodanowe”) nie tylko wykorzystują dane, ale przede wszystkim kładą nacisk na ich magazynowanie, czyszczenie i późniejsze raportowanie. Znaczącą ich część stanowią procesy z zakresu ETL (ang. Extract Transform Load), polegające na pobraniu, transformacji i załadowaniu danych do struktury docelowej. Strukturą docelową bywa transakcyjna baza danych, innym razem jest to klasyczna hurtownia (w schemacie gwiazdy lub płatka śniegu), ostatnio natomiast coraz większą popularność zyskuje metodyka Data Vault.

Warto nadmienić, że w przypadku projektów opartych na danych (szczególnie realizowanych dla banków inwestycyjnych), często musimy brać pod uwagę bardzo rygorystyczne wymagania regulacyjne i przyzwyczajenia użytkowników jeżeli chodzi o raportowanie. Przede wszystkim jednak pracujemy na ogromnych wolumenach danych (często rzędu terabajtów, a nawet i większych).

Jak w tym kontekście odnajduje się koncepcja Data Vault?

Modelowanie w Data Vault

O samym Data Vault możecie przeczytać w poprzednich częściach naszej serii, autorstwa Arka Kasprzaka i Łukasza Samelaka. Arek i Łukasz są znakomitymi ekspertami w obszarze przetwarzania danych i ich opisy oferują szczegółowe, a jednocześnie przystępne wprowadzenie do tematyki. 

Ja natomiast chciałbym zwrócić uwagę na wąskie gardło w zakresie zarządzania tego rodzaju projektami – czyli model danych. 

Jak wynika z artykułów moich kolegów, model danych w Data Vault zawiera z reguły więcej obiektów niż modele konstruowane w innych podejściach. Co więcej, są to obiekty różnego rodzaju – podzielone na huby, satelity, linki, bridge, PITy i inne. 

Na pierwszy rzut oka model może się wydawać niejasny i przytłaczający, a jego zrozumienie rzeczywiście wymaga sporego wysiłku. Mimo to, po zaznajomieniu się z jego istotą oraz zależnościami między obiektami, zrozumienie i stworzenie fizycznej reprezentacji modelu przychodzi znacznie łatwej. 

Jest to na tyle krytyczna i skomplikowana część pracy w projekcie, że organizacje często decydują się na wyodrębnienie dedykowanej osoby (lub zespołu), która będzie zajmowała się tylko i wyłącznie modelem danych – stąd pojawienie się funkcji Data Modellera. 

Osoba taka musi znać dziedzinę problemu, być zaznajomiona z pełnym modelem istniejącym w danej chwili w Data Vaulcie i być w stanie zamodelować cały logiczny i fizyczny model danych wymagany przez biznes – np. model związany z informacjami dotyczącymi kontrahentów banku czy transakcji zawieranych przez daną instytucję. Aby to osiągnąć, wymagana jest ścisła współpraca z analitykami biznesowymi, poznanie wymagań i istoty problemu, czy wreszcie dokładne opisanie danych, które chcemy zamodelować.

Stanowisko to jest bardzo odpowiedzialne i od niego zależy powodzenie całego projektu. Osoba modelująca dane daje zielone światło dla implementacji – bierze wówczas pod uwagę wszystkie wymagania związane z danymi, proces ich ładowania, jak i odczyt z poziomu Data Mart w celach raportowych.

Ze względu na złożoność procesu, każda zmiana w modelu, zachodząca podczas lub – co gorsza – po zakończeniu implementacji, jest bardzo czasochłonna i nierzadko wymaga zmian w wielu miejscach, pochłaniając czas, pieniądze i wymuszając kolejny cykl regresji. Warto zaznaczyć, że rozszerzenie modelu (dodanie nowych obiektów czy kolumn), w przeciwieństwie do zmian w modelu istniejącym, jest mało złożone i jest to główna zaleta Data Vaulta.

Model danych jest więc kluczowym elementem tego typu projektów i powinniśmy mieć pewność, że wersja, na której pracujemy jest ostateczna zanim przystąpimy do implementacji. 

Oczywiście jest to scenariusz idealny – jeżeli dostarczenie finalnej wersji modelu się przedłuża, możemy spróbować podzielić go na niezależne fragmenty i implementować „po kawałku”, wraz z potwierdzaniem kolejnych części. Takie podejście sprawdza się głównie w przypadku, gdy model jest bardzo rozbudowany – gdy zawiera dziesiątki, czy nawet setki obiektów.

Zarządzanie implementacją

W tym przypadku liczba obiektów do zapełnienia, a także kolejność, w jakich muszą zostać załadowane, sprawia, że implementacja procesu ładowania danych do Data Vaulta jest nietrywialnym zagadnieniem. 

Dane najpierw należy pobrać ze źródła i zapisać w obszarze przejściowym (ang. staging), następnie należy odpowiednio dobrać atrybuty zapisane w tym obszarze i określić gdzie dokładnie będą one zapisane w Data Vaulcie. Jest to proces tzw. mapowania, którego wynikiem powinien być dokument określający w której kolumnie w docelowym modelu należy zapisać każdy atrybut otrzymany ze źródła.

Interesującą koncepcją pozwalającą zebrać i uporządkować wszystkie atrybuty dostępne w Data Vault jest słownik danych (ang. data dictionary), który przechowuje m.in. nazwy atrybutów, ich złote źródło (czyli źródło, z którego dany atrybut powinien być pobierany), definicję biznesową i inne parametry pozwalające łatwo określić czy dany atrybut znajduje się już w Data Vaulcie – i skąd pochodzi (ang. data lineage).

Następnie należy zająć się kolejnością ładowania danych do obiektów, gdyż hub populowany jest na początku – po nim linki, satelity i inne obiekty. Kolejność taka wymuszona jest przez relacje między różnymi rodzajami obiektów, a także przez fizyczne klucze istniejące w bazie danych. 

Oczywiście trzeba też brać pod uwagę czas, w jakim dane będą dostarczane, jak i moment, w którym mają być dostępne w Data Vault w celu ich pobrania przez konsumentów danych (często jest to Data Mart), a także fakt, że więcej procesów może jednocześnie zapisywać dane do tych samych obiektów.

Zazwyczaj Definition of Done (czyli moment, w którym uznajemy zadanie za ukończone) dla ładowania danych w tego typu projekcie określane jest poprzez porównanie czy dane z obszaru przejściowego zostały odpowiednio zapisane w miejscu docelowym, zachowując kompletność i spójność – stanowi to podstawę planu testów tworzonego dla danego zestawu wymagań. 

Są to kluczowe zagadnienia w procesie zarządzania projektem Data Vaultowym, które zawsze należy brać pod uwagę planując pracę zespołu i cały proces (end-to-end) zasilania danymi struktury docelowej. Konieczne jest więc zbudowanie u klienta biznesowego świadomości, że korzystając z Data Vaulta, zagadnienia z pozoru dla niego trywialne (takie jak załadowanie danych ze źródła o bardzo prostej strukturze) mogą zająć więcej czasu, niż w tradycyjnym projekcie bazodanowym, z którym najpewniej do tej pory miał do czynienia.

Świadomość ta jednak powinna być zbudowana na tym, że mimo wyższego progu wejścia, wysiłek ten opłaci się długofalowo, szczególnie, jeżeli zautomatyzujemy proces zasilania struktury docelowej. Patrząc perspektywicznie, utrzymanie, a przede wszystkim sama rozbudowa modelu poprzez dodanie nowych obiektów jest prostsza, niż w tradycyjnym podejściu, tak więc wysiłek ten bardzo szybko zaczyna przynosić realne korzyści biznesowe.

Vault Vaultowi nierówny

Miałem przyjemność prowadzić projekt w momencie, w którym odbywało się przejście z metodyki Data Vault 1.0 na 2.0. Uważam, że warto chociaż po krótce wspomnieć o tym w kontekście zarządzania projektem. Choć różnice techniczne w opisie mogą się wydawać niewielkie, z punktu widzenia zarządzania, różnica między wersjami jest ogromna. 

Data Vault 2.0 jest dużo bardziej wydajny, jeżeli chodzi o ładowanie danych, eliminację duplikatów, a przede wszystkim, w odpowiednim modelu, dane zajmują znacznie mniej powierzchni dyskowej niż w wersji 1.0. Odpowiednio zaimplementowane klucze hashowe (ang. hash keys) pociągają za sobą spory wzrost wydajności, a także umożliwiają błyskawiczną eliminację duplikatów. Porównanie dwóch hashy jest dużo bardziej wydajne niż podobna operacja na kluczu złożonym z kilku kolumn, szczególnie, jeżeli co najmniej jedna z nich jest typu dowolnego ciągu znaków (VARCHAR), a nie liczbą. 

To tylko niektóre z zalet wersji 2.0, dlatego jeżeli w swoich projektach rozpatrujecie możliwość przechowywania danych w Data Vaulcie, to zdecydowanie polecam od razu budować model oparty na wersji 2.0 – zarządzanie nim w dłuższej perspektywie jest po prostu łatwiejsze. Docenicie to zarówno Wy, jak i Wasz klient.

Projekt jako całość

Kluczowym etapem w tego typu projektach jest dogłębne zrozumienie wymagań, warunków wstępnych i zależności między różnymi elementami – bazą danych, modelem, różnymi źródłami danych, a także orkiestracją (zarządzaniem co i kiedy ma się wykonać), jak i samym ładowaniem danych. Wszystko to ma wpływ na estymację czasu wykonania zadań. Jak już wspomniałem wyżej – absolutnie kluczowa jest analiza biznesowa danych i stworzenie odpowiedniego ich modelu.

Musimy mieć świadomość, że głównym źródłem ryzyka (poza błędnymi danymi otrzymanymi ze źródła) pozostaje każda zmiana w modelu. W tak rozbudowanej strukturze, z wieloma zależnościami, pociąga ona za sobą najczęściej zmiany w innych obiektach (często wielu) i naturalnie wymusza kolejny cykl testowania. Jednak, jak wspomniałem wyżej, dzięki swojej strukturze, jest to mimo wszystko łatwiejsze niż w innych podejściach do hurtowni danych.

Podsumowując, aby projekt działał sprawnie, musimy być w maksymalnym stopniu pewni następujących punktów:

1. Struktura i zawartość danych źródłowych (w rozumieniu fizycznym i biznesowym),
2. Odpowiednie modelowanie tych danych w Data Vaulcie,
3. Czas, w którym dane mają być dostępne – orkiestracja,
4. Wymagania określone przez konsumentów danych.

Wszystko to powinniśmy spisać i zatwierdzić zanim przejdziemy do właściwej implementacji. Możemy tego dokonać w postaci dokumentu o nazwie Feed Onboarding Contract (FOC), gdzie w odpowiedniej strukturze opisane są wszystkie szczegóły dotyczące danego źródła danych, a także sposobu, w jaki dane te należy przenieść do Data Vaulta.

Jest to kluczowe szczególnie w okresie planowania wysokopoziomowego, które często odbywa się per źródło danych. Jeżeli mamy dostęp do wszystkich wymaganych dokumentów FOC i posiadamy określony model danych, jesteśmy w stanie bardzo precyzyjnie oszacować czas pracy potrzebny do zakończenia tworzenia fizycznej reprezentacji modelu, a także jego zasilana oraz testów.

Jeżeli zmiana wymagań nastąpi w momencie, gdy cały proces jest już zakończony, to poprzez mnogość zależności wydłuża ona czas pracy zdecydowanie bardziej niż w innych typach projektów. Dlatego przed przystąpieniem do implementacji musimy uzyskać wystarczający stopień pewności, by nie powtarzać tej samej pracy kilkukrotnie. W przypadku wielu źródeł danych, dobrą praktyką jest najpierw przystąpić do pracy nad tymi relatywnie prostymi, obarczonymi mniejszym prawdopodobieństwem zmian, czekając na stabilizację wymagań dotyczących pozostałych źródeł.

Ważne jest również odbywanie cyklicznych spotkań z analitykami i biznesem, aby upewnić się, że wspólnie zmierzamy w dobrą stronę.

Podsumowanie – zarządzanie zmianą a utrzymanie

Dodanie nowego źródła danych w projekcie korzystającym z metodyki Data Vault może wydawać się bardziej skomplikowane niż w tradycyjnym projekcie bazodanowym, lecz gdy mamy już stabilny model, proces ładowania danych jest rozpoznany i oprogramowany, a jednocześnie współpracujemy blisko z producentami danych i ograniczamy występowanie ryzyka, to praca w tego typu projekcie staje się, mówiąc kolokwialnie, łatwa i przyjemna. Zbierając odpowiednie statystyki, posiadając odpowiednie mechanizmy logowania błędów, a także korzystając z narzędzi, które zapewnia Data Vault 2.0, jesteśmy w stanie poradzić sobie z niemal każdym problemem, na jaki natrafimy.

Jedynym wyzwaniem pozostaje mnogość obiektów w bazie danych, które najpierw musimy wypuścić na produkcję, a następnie utrzymać – same obiekty, klucze i indeksy pochłaniają zazwyczaj bardzo dużo miejsca.

Jeżeli jednak uda nam się nad tym wszystkim zapanować na początku (tak jak w przypadku naszego projektu), to dodanie każdego nowego źródła danych przestaje być czasochłonne – jest to aktualnie najbardziej elastyczne podejście, gdy bierzemy pod uwagę dodawanie danych z zupełnie nowych źródeł. Sam Data Vault zapewnia idealne środowisko przechowywania danych, spełniając zarazem większość wymagań postawionych przez agencje regulacyjne. Dlatego też warto rozważyć stosowanie tej metodyki w projektach bazodanowych – duże banki inwestycyjne będą po nią sięgać coraz częściej.