Tzw. data quality to ważne, ale często mylnie rozumiane pojęcie w świecie cyfrowej obróbki informacji.
Złe dane mogą mieć znaczące konsekwencje biznesowe dla firm. Dane niskiej jakości są często uważane za źródło błędów operacyjnych, niedokładnych analiz i nieprzemyślanych strategii biznesowych. Przykłady szkód ekonomicznych, jakie mogą powodować problemy z jakością danych, obejmują dodatkowe wydatki, gdy produkty są wysyłane na niewłaściwe adresy klientów, firma notuje utracone możliwości sprzedaży z powodu błędnych lub niekompletnych danych o klientach albo musi płacić kary za niewłaściwe raportowanie swoich finansów. Konsultant ds. jakości danych Thomas Redman oszacował w artykule napisanym dla MIT Sloan Management Review w 2017 roku, że korygowanie błędów danych i radzenie sobie z problemami biznesowymi spowodowanymi przez złe dane kosztuje firmy średnio od 15% do 25% ich rocznych przychodów.
Sprawdź E i L w ELT
W świecie przetwarzania, składowania oraz analizy danych (czy jak kto woli: w data engineeringu) stosuje się pojęcie ELT. Proces ETL składa się z 3 kroków:
- Extract – pozyskanie danych ze źródeł i zapisanie ich w tymczasowej lokalizacji (staging area);
- Load – załadowanie danymi hurtowni już na serwerze docelowym;
- Transform – przetwarzanie danych uzupełnione o ich uzgadnianie, czyszczenie i poprawianie.
Przez większość czasu, kiedy mówimy o testowaniu danych, większość specjalistów pierwsze o czym myśli to testowanie samych danych, a nie testowanie poprawności transformacji, które wykonujemy na tych danych, aby uczynić je użytecznymi. W tym miejscu okazuje się, że terminologia „jakości danych” i „testowania danych” zaczyna się wielu z nas rozmywać.
Głównym celem testów jakości danych jest sprawdzenie, czy E (extract) lub L (load) w ELT jest zgodne z oczekiwaniami. Chodzi o zapewnienie, że wykryjemy problemy z danymi u źródła lub problemy z wydobyciem tych danych na zewnątrz. Dzieje się tak, ponieważ powinieneś wiedzieć, co robi twój kod (tj. co Ty robisz z danymi) w zakresie metody generowania danych. Jeśli dane wejściowe nie są zgodne z założeniami (wymaganiami, jakim powinny one odpowiadać) to możemy być pewni wystąpienia zupełnie nieoczekiwanych rezultatów.
Pytania do zadania
Z tego też powodu kontrole jakości danych są nastawione na odpowiedź na nieco inny zestaw pytań niż te, które są używane do sprawdzania poprawności transformacji, takie jak:
- Czy mój schemat jest zgodny z oczekiwaniami?
- Czy wszystkie wartości w wierszach mają prawidłowy typ?
- Czy są jakieś dziwne wartości w moich danych?
- Czy są zduplikowane wartości?
Zdefiniujmy jakość danych
Najogólniej rzecz ujmując, jakość danych oznacza po prostu, że dane nadają się do użycia. Preferujemy, aby ta „jakość” pochodziła ze źródła danych, ale jak doskonale wiemy, nie zawsze tak się dzieje. Tak więc, jakość danych w aspekcie, w jakim myśli o niej większość inżynierów, oznacza sprawdzenie, czy dane nadają się do użycia.
Sprawdzenia te to szereg metod, które wykonują asercje. Asercje mogą być takie same jak te, które mogą być potencjalnie użyte przy generowaniu danych, z tą różnicą, że tym razem dane są prawdziwe. Mogą one być dość wyrafinowane: można stosować ograniczenia pod kątem nullability i unikalności, wyrażenia regularne czy żądać aby wartości mieściły się w określonym przedziale. Dostarczanie ram do definiowania tych asercji jest istotą większości narzędzi stosowanych do pomiaru jakości danych.
W skrócie wygląda to tak…
Jakoś danych NIE:
- daje gwarancji na to jak zachowywać się będzie kod transformacji (ponieważ dane wejściowe mogą się zmieniać);
- zapewnia wystarczająco rygorystycznego testowania dla dobrych linii ciągłego dostarczania (ponieważ nie możesz być pewien, co twój kod robi z danymi wejściowymi, których przecież nie znasz);
- dostarcza żadnych korzyści znanych nam z pracy w IT nad danymi statycznymi (ponieważ dane ciągle się zmieniają).
Jakość danych natomiast:
- oferuje Ci inny rodzaj testowania, o którym niekoniecznie myślisz, kiedy generujesz dane do testów (ponieważ wiesz jakie masz dane wejściowe skoro sam je wygenerowałeś);
- powstrzymuje „złe” dane przed zrujnowaniem ci dnia (ponieważ dane w prawdziwym świecie są nieporządne i zawsze musisz je sprawdzać);
- testuje prawdziwe dane i dlatego daje ci mechanizm, który sprawi, że twoje testy poprawności transformacji prawidłowo zadziałają na produkcji.
