Co może pójść źle w testowaniu hurtowni danych? Przecież to jest proste!
Dostajesz dane na wejściu. Przetwarzasz je. Dostajesz dane na wyjściu. Co może pójść źle?
Wyobrażasz sobie, że dane wejściowe dostajesz zawsze dobrej jakości? W wielu wypadkach tak jest. Niestety czasami jakość danych wejściowych pozostawia wiele do życzenia.
W tej kolumnie miały być tylko liczby, a dostajesz ciągi znaków.
Zamiast daty dostajesz wartość TRUE albo FALSE.
Albo jeszcze gorzej, miałeś dostawać zysk brutto a dostajesz dochód brutto. To już nie tak łatwo wychwycić.
Faktura miała mieć zawsze przypisane dane klienta, a czasami brakuje tych danych.
Wartość rezydualna miała być zawsze dodatnia, a jest ujemna.
Zdarza się, że z biegiem czasu logika w systemie źródłowym ewaluowała i próba pobrania historii to budowa zupełnie innego przetwarzania niż przetwarzanie bieżących danych.
Już sama analiza tego, co jest na wejściu to gotowy ból głowy.
A dane wejściowe to dopiero początek drogi.
Testowanie hurtowni danych - Błędy na wejściu
Skąd biorą się dane na wejściu do procesu ETL? Z systemu źródłowego albo z innych przetwarzań ETL. To rozróżnienie jest ważne w zrozumieniu, do kogo adresować znalezione odstępstwa.
Błędy wynikające z nieodpowiedniego działania systemu źródłowego adresujesz do zewnętrznego zespołu. Czasami potrafią naprawić dane, a czasami rozkładają ręce i twierdzą, że nic nie mogą zrobić. Wtedy wymagana jest zmiana procesu ETL po stronie hurtowni danych, w celu obsłużenia kolejnego wyjątku w danych.
Jak wiesz hurtownia danych ma warstwy.
Znaczy to też, że jest wiele procesów ETL zależnych od siebie. Jedno przetwarzanie "produkuje" dane do innego procesu ETL. Jeżeli jeden z elementów tego łańcuszka zawiedzie (wypuści błędne dane), wtedy na wejściu do zależnego procesu dostaniesz niepoprawne dane.
Jeżeli wiesz, że błędy spowodowane są nieodpowiednimi danymi wejściowymi, warto w takich przypadkach zapytać, a co było wcześniej? Kto dostarczył mi dane? Kto jest dostawcą?
Błędy w przetwarzaniu (ETL)
No dobrze. Już wiemy, że nie zawsze dane na wejściu są dobrej jakości. W celu poprawy jakości przygotowany został ETL. Uruchomienie ETL'a:
- Poprawiło jakość (np. odpowiednio ustawiło typ danych)
- Odfiltrowało niepotrzebne dane (na przykład duplikaty)
- Zaaplikowało reguły biznesowe
○ Dodało wiersze
○ Poprawiło lub dodało kolumny - Uzupełniło braki, danymi z innych systemów
- W przypadku braku danych wstawiło dane domyślne (np. singletony)
- Odpowiednio obsłużyło historię (co to jest CDC?)
Było to niezbędne, żeby dostać dane lepszej jakości.
Niestety każdy punkt usprawniający dane, to potencjalnie jest punkt, gdzie można coś pominąć albo źle zaimplementować. Każdy z tych punktów wymaga przetestowania.
Testowanie hurtowni danych - Błędy w pobieraniu danych
Jaka ulga.
Po wielu przetwarzaniach i sprawdzeniach mamy dane dobrej jakości.
W tym przypadku wreszcie powinno być prosto.
Tylko co z dalej robi się z danymij?
Łączy, agreguje, stosuje jeszcze inne reguły, przygotowując na przykład raporty albo ekstrakty do systemów zewnętrznych.
Więc tutaj znowu jest możliwość popełnienia błędu:
- Wybrania zbyt dużej ilości danych (mogą pojawić się duplikaty)
- Lub zbyt małej ich ilości
- Nieodpowiedniego dobrania obliczeń
- Nieodpowiedniego zaaplikowania reguły bezpieczeństwa (RLS, OLS)
- Wybrania danych historycznych, gdy potrzeba tylko aktualne (lub odwrotnie)
Wyzwania w testowaniu hurtowni danych?
W przeciwdziałaniu powstania błędów to testowanie danych.
Może zamienić na: W przeciwdziałaniu powstawania błędów wspiera nas/pomaga nam testowanie danych. Ale dane są żywe, zmieniają się i trzeba je inaczej interpretować albo widzieć w szerszym kontekście. Na przykład nie wystarczy już agregacja kosztu. Trzeba, poza zagregowaną wartością, pokazać rozbicie na pojedyncze elementy.
Kolejnym pomysłem na poprawę jakości jest budowa skryptów, raportów i automatyzacji, które monitorują jakość danych. Jeżeli jakiś problem pojawia się notorycznie, wtedy łatwo umieścić go w sprawdzeniach jakości i wychwytywać takie przypadki.
Co jeżeli przypadek pojawił się pierwszy raz i został wychwycony przez użytkownika? Czy to znaczy, że dodajemy go do sprawdzeń automatycznych? Czy błąd był po stronie hurtowni danych? Czy po stronie systemu źródłowego? Czy mogliśmy wykryć ten błąd wcześniej? Jeszcze przed tym jak użytkownik nam zgłosił? W jaki sposób myśleć z perspektywy naszego klienta?
Jeszcze jedną kwestią jest reakcja na wykryte błędy. Wyobrażasz sobie sprawdzać codziennie raport, który zgłasza 100 błędów jakości? A może te błędy już nie są błędami, tylko jest to nowe oczekiwane działanie systemu? Zdefiniowane reguły też trzeba utrzymywać i dbać o ich jakość.
To jest ciągle proces manualny, a może da się zrobić tak, żeby był to proces automatyczny?
Testowanie hurtowni danych - Podsumowanie
Wszystko jest zrobione, przetestowane, alerty jakości danych wyświetlają uspakajający zielony kolor. System jest w idealnej kondycji.
Na koniec dnia przychodzi do Ciebie użytkownik i mąci spój:
"Ale w tym raporcie, jest inna wartość niż w systemie źródłowym."
W jaki sposób analizujesz jego zgłoszenie?
Użytkownik widzi te dane w raporcie. Do tego miejsca dane przeszły długą drogę.
Od ekstraktu ze źródła, przez ETL'a po przygotowanie danych dla warstwy raportowej i budowę raportu.
Chcesz wiedzieć w jaki sposób analizuje się takie zgłoszenia? W jaki sposób bawisz się w detektywa i stwierdzasz z zadowoleniem:
"Nasze dane są prawidłowe" i jesteś w stanie przedstawić wyjaśnienie dlaczego.
To daje wielką satysfakcję!
Chcesz usłyszeć o tym historię?