Hurtownia danych zawiera warstwy. W zależności od modelu jaki wybierzesz możesz mieć na przykład dwie warstwy: Staging i Data Mart. Albo więcej: Staging, Data Vault, operational data store (ODS), data mart, warstwa raportowa.
Koszt takich warstw, to podatność na błędy programistyczne, zwiększony czas ładowania danych i więcej danych do obsługi. To tak jakbyś jeden wiersz ze źródła przechowywał w pięciu kopiach.
Ale po co są te wszystkie warstwy w hurtowniach danych? Dlaczego dane nie są pobierane bezpośrednio ze źródła (czy to pliku lub z innej bazy danych) do raportu.
Po co tak komplikować?
Jakość danych
Jakie masz źródło? Ufasz mu? Nie ma duplikatów? Zawsze dla atrybutu, na przykład, PESEL dostajesz ciąg liczb? Czy czasami zdarza się, że znajdziesz tam też inne znaki? Czy data urodzenia to zawsze data? Czy numer VIN pojazdu jest zawsze prawidłowo wypełniony?
To tylko proste przykłady, żeby pokazać Ci, że do źródła należy mieć zaufanie, ale ograniczone.
Czy plik albo dane źródłowe zawsze są dostępne? Czy zdarza się, że na przykład plik nie zostanie dostarczony, albo będzie opóźnienie w dostarczeniu danych? Jak przygotowujesz się na taki scenariusz?
Brak zaufania do danych, to pierwszy z powodów, dla których dodanie warstwy to dobry pomysł.
Filtrowanie, aplikowanie reguł biznesowych i bezpieczeństwo
Czy potrzebujesz wszystkich danych źródłowych? Czy może jest ich trochę za dużo?
A może potrzeba zaaplikować na nich kalkulacje? Powielić?
Albo na przykład zanonimizować lub tworzyć reguły dostępu do danych. Czyli w oparciu o różne kryteria określić, kto ma mieć do danych dostęp.
Na przykład dział marketingu ma dostęp do innego fragmentu danych, niż dział sprzedaży. Albo centrala widzi inny zakres niż pojedynczy sprzedawca.
Potrzeba wykonania operacji na danych to drugi z powodów, dla których warstwy to dobry pomysł.
Jedno źródło? Czy wiele źródeł?
Masz tylko jeden plik z danymi na wejściu? I tam są wszystkie dane, których potrzebujesz? Użytkownik, nie przychodzi do Ciebie i nie mówi:
"Jeszcze tylko dane z tego Excela proszę dodać i już będzie wszystko"?
Szczęściarz.
Zazwyczaj plik z danymi to dopiero początek. Jest jeszcze potrzeba, dołączenia do niego dane z innych systemów, albo z plików dostarczonych przez użytkowników. Albo wolno zmiennych danych statycznych, na przykład słowniki.
Potrzeba dodania kontekstu do danych, to trzeci z powodów, dla którego warstwy to dobry pomysł.
DRY (Don't repeat yourself)
Widać to czasami dopiero w warstwie raportowej. Gdyby dane w źródle były przygotowane trochę lepiej, wtedy nie trzeba byłoby tych samych operacji powtarzać w raportach. I to nie myśl o dwóch raportach, myśl o 20, 100.
Albo jeszcze spójrz na to z perspektywy 'Self Service BI'. Kiedy użytkownicy końcowi mają dostęp do twoich danych i robią na nich takie same operacje. Powtarzają te same transformacje. Może wtedy warto zaaplikować je w warstwie wcześniej.
Gdy wykonasz te operacje w warstwie poprzedniej, wtedy oszczędzasz im:
- Frustracji
- Czasu
A sobie:
- Problemów wydajnościowych
- Uporczywych pytań od użytkowników: "Dlaczego mój raport wolno działa"
Względy ograniczania zbędnych powtórzeń, to kolejny z powodów, dla których warstwy to dobry pomysł.
Detekcja błędów - raz jeszcze jakość danych
Aplikacja typów danych, filtrowanie, dodawanie reguł biznesowych, łączenie z wieloma źródłami, agregacje, liczenie miar, konwersje walut, transpozycja danych, bezpieczeństwo.
Warstwy to też sposób na to, żeby łatwiej wykrywać błędy. Niestety aplikowanie wielu reguł, pociąga za sobą możliwość popełniania błędów w implementacji. Gdy jest więcej warstw, łatwiej te błędy poprawiać i potem przeładowywać dane.
Rozwiązywanie problemów z jakością kodu, to kolejny z powodów, dla którego warstwy to dobry pomysł.
Historia - anonimizacja i unifikacja
Nie postrzegaj hurtowni danych, jako statycznego systemu.
Postrzeganie rozwiązań typu BI jako systemów przechowujących i prezentujących dane, jest znacznym uproszczeniem. Takie założenie, może pociągnąć za sobą myśl, że są to dane statyczne, które nigdy się nie zmieniają.
Wyobraź sobie przypadek reorganizacji. Nazwy departamentów się zmieniają. I w źródle nadal chcesz mieć dwie starą i nową nazwę departamentu, ale już raportować chcesz tylko pod nową nazwą.
Przypadek GDPR to też jeden ze scenariuszy, gdzie dane historyczne uległy zmianie. Zaszła potrzeba wyszukania i anonimizacji danych klientów, w historycznych danych.
Gdy masz zrobiony podział na warstwy łatwiej przeładować część danych. gdzie zaszła potrzeba poprawienia błędów albo aplikacji nowych reguł.
Ułatwione zarządzanie, to kolejny z powodów, dla którego warto rozważyć warstwy.
Ale czy są przypadki, kiedy warstwy nie są potrzebne?
Oczywiście, że tak.
Na przykład, jeżeli nie masz rozwiązania klasy enterprise.
Nie potrzebujesz tylu warstw. Potrzebujesz źródło, do którego masz zaufanie i rozwiązanie raportowe, żeby zaprezentować MVP (minimum viable product).
Drugi scenariusz to na przykład, gdy dopiero zaczynasz i chcesz zobaczyć, czy dane, które masz "nadają się"?
Chcesz "sprzedać" komuś swój pomysł i zrobić rozwiązanie "quick and dirty".
Dopiero potem przyjdzie kolej na hurtownie danych i praca nad jakością i czyszczeniem danych.
Zbudowanie jednego raportu to fraszka, ale pomyśl, że masz ich 100. Robisz bardzo podobne operacje na danych źródłowych, w każdym z rozwiązań.
I zakładam, że nie chcesz potem całego swojego czasu przeznaczyć na utrzymanie kodu.
Nie dość, że to jest uciążliwe, to jeszcze nieefektywne i nudne.
Oczywiście niektóre rozwiązania raportowe umożliwiają zbudowanie wspólnego modelu i łączenie raportu bezpośrednio do tego modelu, już nie do źródła.
Zmiany wykonujesz wtedy w jednym centralnym punkcie, a nie w każdym z pojedynczych raportów. Takie rozwiązanie można zaimplementować w Qlik w postaci np. QVD oraz w Power BI datasets.
Ale to już zupełnie inna historia.
| Czy warstwa raportowa to część hurtowni danych ? |
|---|
| Warstwa raportowa to coraz częściej nie tylko warstwa prezentacji.
Ale to też miejsce, które przechowuje i przetwarza dane. Przetwarza, gdyż zazwyczaj źródło (czy to plik, czy data mart) nie zawierają danych w oczekiwanym formacie, albo na potrzeby raportu potrzebne są agregacje. Przechowuje, gdyż tak jest wydajniej potem zaserwować dane odbiorcy. Są już załadowane ze źródła. Nie pytamy źródła za każdym razem, gdy jest potrzeba przeładowania danych w raporcie, gdyż to trwa czas, a źródło może być obciążone. Na taki koszt nie można czasami sobie pozwolić. Dlatego przechowywanie danych "w raporcie" to taki ciekawy feature i to kolejne miejsce, gdzie może zajść potrzeba zarządzania danymi, które już raz zostały załadowane. |
Warstwy w hurtowniach danych - Podsumowanie
Patrząc z jeszcze innej perspektywy: warstwy mają pomóc w budowie niezawodnych, skalowalnych i łatwych w utrzymaniu rozwiązań.
Powyżej masz przypadki, gdzie warstwy w hurtowniach danych ułatwiają życie. Nie zawsze jest konieczne ich stosowanie ale czasami ułatwiają życie.
Daj mi znać jakie Ty masz wyzwania, gdy tworzysz warstwy w rozwiązaniach typu BI.
Takeaways
Czy zawsze warstwy w hurtowniach danych są potrzebne?
Tak: gdy masz duże rozwiązanie.
Warte rozważenia, gdy masz niewielkie rozwiązanie albo dopiero zaczynasz.
Nie ma jednoznacznej odpowiedzi, gdyż to zależy od kontekstu, w jakim tworzysz rozwiązanie.
Ile scenariuszy zmiany wymagań przez użytkowników możesz wymyśleć?
Tak co najmniej dziesięć przykładów, czas start 😉
- Zmiana w module bezpieczeństwa
- Dodanie systemu źródłowego
- Usunięcie systemu źródłowego
- Dodanie, zmiana, modyfikacja atrybutów.
- Dodanie przechowywania historii dla tabeli
- Zmiana na potrzeby optymalizacji pobierania danych przez raporty
- Modyfikacja, usunięcie już raz wstawionych danych na podstawie incydentu a nie na podstawie zmiany danych w systemach źródłowych
- Dodanie danych statycznych (słownika, metadanych)
- Zmiana wymuszona przez regulatora (zmiany w systemach bankowych)
- Zmiany reguł biznesowych
- Zmiany na potrzeby nowego konsumenta danych.
Czy dane raz załadowane do hurtowni danych się nie zmieniają?
Przykład GDPR albo potrzeba anonimizacji danych pokazuje, że jest potrzeba zmiany raz załadowanych danych. Reorganizacje w firmie, średnio co dwa lata, też przyczyniają się do tego, że zachodzi potrzeba zmiany danych w hurtowni danych.