Jak wdrożyć proces jakości danych

Jakość danych (DQ) w systemach hurtowni danych nabiera coraz większego znaczenia. Rosnące wymagania regulacyjne, ale także rosnąca złożoność rozwiązań hurtowni danych, zmuszają firmy do zintensyfikowania (lub rozpoczęcia) inicjatywy w zakresie jakości danych.

W tym artykule skupimy się głównie na „tradycyjnej” hurtowni danych, ale jakość danych jest również problemem w bardziej „nowoczesnych” koncepcjach, takich jak jeziora danych. Pokaże kilka głównych punktów do rozważenia, a także kilka typowych pułapek, których należy unikać podczas wdrażania strategii jakości danych. Nie obejmuje części dotyczącej wyboru odpowiedniej technologii/narzędzia do zbudowania frameworka DQ.

Jednym z najbardziej przeszkadzających problemów projektu DQ jest fakt, że na pierwszy rzut oka generuje dużo pracy dla jednostek biznesowych, nie zapewniając żadnej dodatkowej funkcjonalności. Inicjatywa na rzecz jakości danych ma zwykle silnych zwolenników tylko wtedy, gdy:

• Występują problemy z jakością danych, które mają poważny wpływ na biznes.
• Organy regulacyjne egzekwują standardy jakości danych (np. BCBS 239 w branży finansowej).

Traktowanie DQ jest podobne do testowania w tworzeniu oprogramowania — jeśli projektowi zabraknie czasu i/lub budżetu, ta część jest zwykle zmniejszana w pierwszej kolejności.

To oczywiście nie jest cała prawda. Dobry system jakości danych pozwala na wczesne wykrywanie błędów, przyspieszając tym samym proces dostarczania użytkownikom danych „wystarczająco dobrej” jakości.

Określenie warunków

Przed omówieniem tematu ważne jest wspólne zrozumienie użytych terminów.

Hurtownia danych (DWH)

Hurtownia danych (DWH) to nieoperacyjny system służący głównie do wspomagania decyzji. Konsoliduje dane systemów operacyjnych (wszystkie lub mniejszy podzbiór) i dostarcza zoptymalizowane pod kątem zapytań dane dla użytkowników systemu DWH. Hurtownia danych powinna zapewniać „pojedynczą wersję prawdy” w przedsiębiorstwie. Hurtownia danych jest zwykle zbudowana z etapów/warstw:

Dane operacyjne są przechowywane w większości w postaci niezmienionej w warstwie pomostowej . Warstwa szkieletowa zawiera skonsolidowane i ujednolicone dane. Następnym opcjonalnym etapem jest obszar derywacji , dostarczający dane pochodne (na przykład ocena klienta dla sprzedaży) i agregacje. Warstwa data mart zawiera dane zoptymalizowane dla danej grupy użytkowników. Bazy danych często zawierają agregacje i wiele pochodnych metryk. Użytkownicy hurtowni danych często pracują tylko z warstwą zbiorczą danych.

Pomiędzy każdym etapem następuje jakaś transformacja danych. Zwykle hurtownia danych jest okresowo ładowana ekstrakcjami delta danych operacyjnych i zawiera algorytmy do przechowywania danych historycznych.

Jakość danych

Jakość danych jest zwykle definiowana jako miara tego, jak dobrze produkt spełnia wymagania użytkownika. Różni użytkownicy mogą mieć różne wymagania dotyczące produktu, więc wdrożenie zależy od perspektywy użytkownika i ważne jest, aby zidentyfikować te potrzeby.

Jakość danych nie oznacza, że ​​dane muszą być całkowicie lub prawie wolne od błędów — zależy to od wymagań użytkowników. „Wystarczająco dobre” podejście to dobry wybór na początek. Obecnie większe firmy mają „politykę rządu dotyczącą danych (lub informacji)”, a jakość danych jest jej częścią. Polityka zarządzania danymi powinna opisywać, w jaki sposób Twoja firma postępuje z danymi i w jaki sposób zapewnia odpowiednią jakość danych i nie narusza zasad prywatności danych .

Jakość danych to stały temat. Należy zaimplementować pętlę obwodu DQ (patrz następny rozdział). Wymagania prawne i zasady zgodności mają również wpływ na wymaganą jakość danych, np. TCPA (amerykańska ustawa o ochronie konsumentów telefonicznych) lub RODO w Europie w kwestiach prywatności, ale także zasady branżowe, takie jak Solvency II dla ubezpieczeń w UE, BCBS 239 i inne dla bankowości i tak dalej.

Pętla obwodu jakości danych

Podobnie jak w przypadku wszystkich tematów dotyczących jakości, DQ jest stałą działalnością mającą na celu utrzymanie satysfakcjonującej jakości. W wyniku projektu DQ musi zostać zaimplementowana pętla obwodu podobna do poniższej:

Kroki w ramach tej pętli zostaną opisane w kolejnych rozdziałach.

Role dotyczące jakości danych

Aby wdrożyć udaną inicjatywę DQ, potrzebne są następujące role:

• Właściciel danych. Właściciel danych odpowiada za jakość danych, ale także za ochronę prywatności danych. Właściciel danych jest „właścicielem” domeny danych, kontroluje dostęp i jest odpowiedzialny za zapewnienie jakości danych i podejmowanie działań w celu naprawienia ustaleń. W większych organizacjach często można znaleźć kilku właścicieli danych. Domeny danych mogą obejmować na przykład dane marketingowe, dane kontrolne itp. Jeżeli w firmie istnieje więcej niż jeden właściciel danych, powinna istnieć jedna osoba (właściciel danych lub ktoś inny) odpowiedzialna za ogólny proces jakości danych. Właściciel danych powinien mieć silne uprawnienia do egzekwowania jakości danych i wspierania procesu DQ; dlatego właściciele danych są często starszymi interesariuszami. Ważne jest dobre zrozumienie domeny biznesowej oraz dobre umiejętności komunikacyjne.
• Zarządca danych. Zarządzający danymi pomaga we wdrażaniu jakości danych w przedsiębiorstwie, wspierając użytkowników danych w kwestiach dotyczących interpretacji danych/modelu danych, problemów z jakością danych itp. Zarządzający danymi są często personelem właściciela danych lub mogą być zorganizowani w centrum kompetencji ds. jakości danych lub zespół DQ. Administratorzy danych mogą mieć doświadczenie informatyczne lub biznesowe, ale powinni znać obie strony. Umiejętności analityczne wraz z dobrym zrozumieniem obsługiwanej przez nich domeny biznesowej, w połączeniu z silnymi umiejętnościami komunikacyjnymi, są głównymi warunkami skutecznego zarządzania danymi.
• Użytkownik danych. Są to użytkownicy hurtowni danych pracujący z danymi. Użytkownicy danych zwykle pracują z warstwą zbiorczą danych i są odpowiedzialni za wyniki pracy z danymi. Użytkownicy danych upewniają się, że istnieją odpowiednie kontrole jakości danych dla wymaganego poziomu jakości. Użytkownicy danych potrzebują silnego zrozumienia swoich danych, dziedziny biznesowej oraz wymaganych umiejętności analitycznych do interpretacji danych. Rozsądne jest znalezienie wśród użytkowników danych w każdej jednostce biznesowej kilku osób, które będą odpowiedzialne za kwestie jakości danych.

Aby zapewnić sukces, ważne jest, aby te role były jasno zdefiniowane i powszechnie akceptowane w Twojej organizacji na wczesnych etapach projektu DQ. Równie ważne jest znalezienie kompetentnych specjalistów ds. danych dla tych ról, którzy wspierają projekt.

Zdefiniuj zasady

Znajdź i zaimplementuj przydatne kontrole/reguły DQ. Definiowanie reguł DQ wymaga dobrego zrozumienia hurtowni danych i jej wykorzystania.

Jak znaleźć reguły DQ?

Jak wspomniano wcześniej, użytkownicy danych (i właściciel danych) są odpowiedzialni za wykorzystanie danych, a zatem również za wymagany poziom jakości danych. Użytkownicy danych powinni dobrze rozumieć swoje dane, aby mogli zapewnić najlepsze dane wejściowe dla przydatnych reguł jakości danych.

To oni również analizują wyniki reguł jakości danych, więc zawsze dobrze jest pozwolić im zdefiniować własne reguły. To dodatkowo zwiększa akceptację sprawdzenia i oceny wyników reguł DQ przypisanych do jednostki użytkownika danych (patrz rozdział „Analiza”).

Wadą tego podejścia jest to, że użytkownicy danych zwykle znają tylko warstwę zbiorczą danych, a nie wcześniejsze warstwy hurtowni danych. Jeśli dane zostały uszkodzone na „niższych” etapach, nie zostanie to wykryte przez sprawdzenie tylko „górnej” warstwy hurtowni danych.

Rozwiązywanie błędów

Jakie znane błędy mogą wystąpić w hurtowni danych?

• Niewłaściwa logika transformacji w hurtowni danych
  • Im bardziej złożony jest twój krajobraz IT, tym bardziej złożona jest logika transformacji. Są to najczęstsze problemy z DQ, a efektem takich błędów mogą być „utracone” dane, duplikaty, nieprawidłowe wartości itp.
• Niestabilny proces załadunku lub niewłaściwa obsługa ładunków
  • Obciążenie hurtowni danych może być złożonym procesem, który może zawierać błędy w definicji aranżacji zadania (zadania rozpoczynające się za wcześnie lub za późno, zadania niewykonane itp.). Błędy spowodowane ręczną interwencją (np. niektóre zadania są pomijane, niektóre zadania są uruchamiane z niewłaściwym terminem lub z wczorajszymi plikami danych) zdarzają się często, gdy proces ładowania jest poza pasmem z powodu zakłóceń.
• Niewłaściwy transfer danych ze źródeł danych
  • Transfer danych jest często realizowany jako zadanie systemu źródłowego. Anomalie lub zakłócenia w przepływach zadań mogą spowodować dostarczenie pustych lub niekompletnych danych.
• Błędne dane operacyjne
  • Dane w systemie operacyjnym zawierają błędy dotychczas nierozpoznane. Może to zabrzmieć dziwnie, ale w projektach hurtowni danych jest banałem, że jakość danych operacyjnych często nie jest widoczna, dopóki dane nie zostaną uwzględnione w DWH.
• Błędna interpretacja danych
  • Dane są poprawne, ale użytkownicy nie wiedzą, jak je poprawnie zinterpretować. Jest to bardzo powszechny „błąd”, który nie jest wyłącznie kwestią jakości danych, ale czymś, co ma związek z zarządzaniem danymi i jest zadaniem administratorów danych.

Problemy te są często powodowane przez osoby, które nie mają odpowiedniej wiedzy i umiejętności do definiowania, wdrażania, uruchamiania i pracy z rozwiązaniem hurtowni danych.

Wymiary jakości danych

Wymiary DQ są powszechnym sposobem identyfikowania i grupowania kontroli DQ. Istnieje wiele definicji, a liczba wymiarów znacznie się różni: możesz znaleźć 16 lub nawet więcej wymiarów. Z praktycznego punktu widzenia mniej dezorientujące jest rozpoczęcie od kilku wymiarów i znalezienie ogólnego ich zrozumienia wśród użytkowników.

• Kompletność: Czy wszystkie wymagane dane są dostępne i dostępne? Czy wszystkie potrzebne źródła są dostępne i załadowane? Czy dane zostały utracone między etapami?
• Spójność: czy istnieją błędne/sprzeczne/niespójne dane? Na przykład data rozwiązania umowy w stanie „Rozwiązana” musi zawierać prawidłową datę wyższą lub równą dacie rozpoczęcia umowy.
• Wyjątkowość: czy są jakieś duplikaty?
• Integralność: czy wszystkie dane są prawidłowo połączone? Na przykład, czy istnieją zamówienia łączące się z nieistniejącymi identyfikatorami klientów (klasyczny problem z integralnością referencyjną)?
• Terminowość: czy dane są aktualne? Na przykład w hurtowni danych z codziennymi aktualizacjami spodziewałbym się, że wczorajsze dane są dostępne dzisiaj.

Pomocne mogą być również dane generowane przez proces ładowania hurtowni danych.

• Tabele z odrzuconymi danymi. W hurtowni danych mogą istnieć procesy pomijania/opóźniania danych, których nie można załadować z powodu problemów technicznych (np. konwersji formatu, brakujących wartości obowiązkowych itp.).
• Rejestrowanie informacji. Zauważalne problemy mogą być zapisywane w tabelach rejestrowania lub plikach dziennika.
• List przewozowy. Niektóre systemy używają „zestawów dostaw” dla danych dostarczanych przez systemy operacyjne (np. liczba rekordów, liczba odrębnych kluczy, sumy wartości). Można ich używać do sprawdzania zgodności (patrz poniżej) między hurtownią danych a systemami operacyjnymi.

Należy pamiętać, że każda kontrola jakości danych musi zostać przeanalizowana przez co najmniej jednego użytkownika danych (patrz rozdział „Analiza”) w przypadku znalezienia błędów, do których potrzebna będzie osoba odpowiedzialna i dostępna, która zajmie się każdą wdrożoną kontrolą.

W złożonej hurtowni danych możesz skończyć z wieloma (czasami tysiącami) regułami DQ. Proces wykonywania reguł jakości danych powinien być solidny i wystarczająco szybki, aby sobie z tym poradzić.

Nie sprawdzaj faktów, które są gwarantowane przez implementację techniczną. Na przykład, jeśli dane są przechowywane w relacyjnym DBMS, nie jest konieczne sprawdzanie, czy:

• Kolumny zdefiniowane jako obowiązkowe zawierają wartości NULL.
• Wartości pól klucza podstawowego są unikatowe w tabeli.
• W tabeli z włączonym sprawdzaniem integralności relacyjnej nie ma istniejących kluczy obcych.

To powiedziawszy, zawsze pamiętaj, że hurtownia danych podlega ciągłym zmianom i że definicje danych pól i tabel mogą się zmieniać w czasie.

Bardzo ważne jest sprzątanie. Reguły zdefiniowane przez różne jednostki użytkowników danych mogą się nakładać i powinny być skonsolidowane. Im bardziej złożona organizacja, tym więcej potrzebnych będzie sprzątania. Właściciele danych powinni wdrożyć proces konsolidacji reguł jako rodzaj „jakości danych dla reguł jakości danych”. Ponadto kontrole jakości danych mogą stać się bezużyteczne, jeśli dane nie są już używane lub jeśli ich definicja uległa zmianie.

Klasy zasad jakości danych

Reguły jakości danych można sklasyfikować na podstawie rodzaju testu.

• Kontrola jakości danych. Przypadek „normalny”, sprawdzanie danych w jednej warstwie hurtowni danych (patrz rysunek 1) w obrębie jednej tabeli lub zestawu tabel.
• Pojednanie. Reguły sprawdzające, czy dane zostały prawidłowo przetransportowane między warstwami hurtowni danych (patrz Rysunek 1). Reguły te są najczęściej używane do sprawdzania wymiaru DQ „Kompletność”. Uzgadnianie może wykorzystywać pojedynczy wiersz lub podejście podsumowane. Sprawdzanie pojedynczych wierszy jest znacznie bardziej szczegółowe, ale będziesz musiał odtworzyć etapy transformacji (filtrowanie danych, zmiany wartości pól, denormalizacja, łączenia itp.) między porównywanymi warstwami. Im więcej pominiętych warstw, tym bardziej złożona logika transformacji musi zostać zaimplementowana. Dlatego dobrym wyborem jest przeprowadzenie uzgadniania między każdą warstwą a jej poprzedniczką zamiast porównywania przemieszczania z warstwą zbiorczą danych. Jeśli przekształcenia mają być zaimplementowane w regułach uzgadniania, użyj specyfikacji, a nie kodu hurtowni danych! W przypadku uzgodnienia podsumowanego znajdź znaczące pola (np. podsumowanie, liczba odrębnych wartości itp.).
• Monitorowanie. Hurtownia danych zwykle zawiera dane historyczne i jest ładowana ekstraktami delta danych operacyjnych. Istnieje niebezpieczeństwo powolnego powiększania się luki między hurtownią danych a danymi operacyjnymi. Budowanie podsumowanych szeregów czasowych danych pomaga zidentyfikować takie problemy (np. porównanie danych z ostatniego miesiąca z danymi z bieżącego miesiąca). Użytkownicy danych z dobrą znajomością swoich danych mogą zapewnić przydatne miary i wartości progowe dla reguł monitorowania.

Jak określić ilościowo problem z jakością danych

Po określeniu, co należy sprawdzić, będziesz musiał określić, jak określić ilościowo zidentyfikowane problemy. Informacje takie jak „pięć wierszy danych narusza regułę DQ o identyfikatorze 15” nie mają większego sensu dla jakości danych.

Brakuje następujących części:

• Jak określić ilościowo/policzyć wykryte błędy. Możesz policzyć „liczbę wierszy”, ale możesz również użyć skali pieniężnej (na przykład ekspozycji). Pamiętaj, że wartości pieniężne mogą mieć różne znaki, więc musisz zbadać, jak je sensownie podsumować. Możesz rozważyć użycie obu jednostek kwantyfikacji (liczba wierszy i podsumowanie) dla reguły jakości danych.
• Populacja. Jaka jest liczba jednostek sprawdzanych przez regułę jakości danych? „Pięć wierszy danych na pięć” ma inną jakość niż „pięć z 5 milionów”. Populacja powinna być mierzona przy użyciu tych samych kwantyfikacji, co w przypadku błędów. Często pokazuje się wynik reguły jakości danych jako procent. Populacja nie może być identyczna z liczbą wierszy w tabeli. Jeśli reguła DQ sprawdza tylko podzbiór danych (np. tylko rozwiązane kontrakty w tabeli kontraktów), ten sam filtr powinien być zastosowany do pomiaru populacji.
• Definicja wyniku. Nawet jeśli kontrola jakości danych wykryje problemy, nie zawsze musi to spowodować błąd. W przypadku jakości danych bardzo pomocny jest system sygnalizacji świetlnej (czerwony, żółty, zielony) wykorzystujący wartości progowe do oceny wyników. Na przykład zielony: 0-2%, żółty: 2-5%, czerwony: powyżej 5%. Pamiętaj, że jeśli jednostki użytkownika danych mają te same reguły, mogą mieć bardzo różne progi dla danej reguły. Marketingowa jednostka biznesowa może nie mieć nic przeciwko utracie kilku zamówień, podczas gdy jednostka księgowa może mieć nic przeciwko nawet centom. Powinna istnieć możliwość określenia progów w procentach lub w liczbach bezwzględnych.
• Zbierz przykładowe wiersze błędów. Pomaga, jeśli reguła jakości danych zawiera próbkę wykrytych błędów — zwykle klucze (biznesowe!) i sprawdzone wartości danych są wystarczające do zbadania błędu. Dobrym pomysłem jest ograniczenie liczby wierszy z błędami pisanymi w regule jakości danych.
• Czasami możesz znaleźć „znane błędy” w danych, które nie zostaną naprawione, ale zostaną znalezione przez przydatne kontrole jakości danych. W takich przypadkach zaleca się stosowanie białych list (kluczy rekordów, które powinny być pominięte podczas kontroli jakości danych).

Inne metadane

Metadane są ważne dla kierowania „Analizy” i monitorowania faz pętli kontroli jakości danych.

• Sprawdzone pozycje. Pomaga przypisać zaznaczone tabele i pola do reguły jakości danych. Jeśli masz ulepszony system metadanych, może to pomóc w automatycznym przypisaniu użytkowników danych i właściciela danych do tej reguły. Ze względów regulacyjnych (takich jak BCBS 239) konieczne jest również udowodnienie, w jaki sposób dane są sprawdzane przez DQ. Jednak automatyczne przypisywanie reguł do użytkowników danych/właścicieli danych poprzez rodowód danych (*) może być mieczem obosiecznym (patrz poniżej).
• Użytkownik danych. Każda reguła DQ musi mieć co najmniej jednego użytkownika danych/jednostkę użytkownika danych przypisaną do sprawdzania wyniku podczas fazy „Analiza” i decydowania, czy i jak wynik wpływa na ich pracę z danymi.
• Właściciel danych. Każda reguła DQ musi mieć przypisanego właściciela danych.

(*) Linia danych pokazuje przepływ danych między dwoma punktami. Dzięki pochodzeniu danych możesz znaleźć wszystkie elementy danych wpływające na dane pole docelowe w Twojej hurtowni.

Używanie pochodzenia danych do przypisywania użytkowników do reguł może być problematyczne. Jak wspomniano wcześniej, użytkownicy biznesowi zwykle znają tylko warstwę zbiorczą danych (i system operacyjny), ale nie niższe poziomy hurtowni danych. Dzięki mapowaniu przez pochodzenie danych użytkownicy danych otrzymają reguły, których nie znają. Na niższych poziomach może być potrzebny personel IT do oceny wyników dotyczących jakości danych. W wielu przypadkach pomocne może być mapowanie ręczne lub podejście mieszane (mapowanie poprzez pochodzenie danych tylko w ramach hurtowni danych).

Pomiar jakości danych

Mierzenie jakości danych oznacza wykonywanie dostępnych reguł jakości danych, co powinno odbywać się automatycznie , wyzwalane przez procesy obciążenia hurtowni danych. Jak widzieliśmy wcześniej, może istnieć niezwykła liczba reguł jakości danych, więc kontrole będą czasochłonne.

W idealnym świecie hurtownia danych byłaby ładowana tylko wtedy, gdyby wszystkie dane były wolne od błędów. W prawdziwym świecie rzadko tak się dzieje (realistycznie rzecz biorąc, prawie nigdy tak nie jest). W zależności od ogólnej strategii ładowania hurtowni danych, proces jakości danych powinien lub nie powinien (to drugie jest znacznie bardziej prawdopodobne) rządzić procesem ładowania. Dobrym projektem jest posiadanie procesów jakości danych (sieci zadań) równoległych i połączonych z „zwykłymi” procesami ładowania hurtowni danych.

Jeśli istnieją zdefiniowane umowy dotyczące poziomu usług, upewnij się, że kontrole jakości danych nie utrudniają ładowania hurtowni danych. Błędy/zawinięcia w procesach jakości danych nie powinny wstrzymywać regularnego procesu ładowania. Nieoczekiwane błędy w procesach jakości danych powinny być zgłaszane i pokazywane w fazie „Analiza” (patrz następny rozdział).

Pamiętaj, że reguła jakości danych może ulec awarii z powodu nieoczekiwanych błędów (być może sama reguła została niewłaściwie zaimplementowana lub podstawowa struktura danych uległa zmianie w czasie). Pomogłoby, gdyby Twój system jakości danych zapewniał mechanizm dezaktywacji takich reguł, zwłaszcza jeśli Twoja firma ma niewiele wydań rocznie.

Procesy DQ powinny być wykonywane i raportowane jak najwcześniej — najlepiej zaraz po załadowaniu sprawdzanych danych. Pomaga to wykryć błędy tak wcześnie, jak to możliwe, podczas ładowania hurtowni danych (niektóre złożone obciążenia systemu hurtowni trwają kilka dni).

Analizować

W tym kontekście „analiza” oznacza reagowanie na wyniki dotyczące jakości danych. To zadanie dla przypisanych użytkowników danych i właściciela danych.

Sposób reagowania powinien być jasno określony w projekcie jakości danych. Użytkownicy danych powinni być zobowiązani do komentowania reguły z wynikami (przynajmniej reguł z czerwonym światłem), wyjaśniając, jakie środki są podejmowane w celu obsłużenia tego ustalenia. Właściciel danych musi zostać poinformowany i powinien podjąć decyzję wspólnie z użytkownikiem(ami) danych.

Możliwe są następujące działania:

• Poważny problem: problem musi zostać naprawiony, a ładowanie danych powtórzone.
• Problem jest akceptowalny: spróbuj naprawić go dla przyszłych obciążeń danych i rozwiąż problem w hurtowni danych lub raportowaniu.
• Wadliwa reguła DQ: Napraw problematyczną regułę DQ.

W idealnym świecie każdy problem z jakością danych zostałby rozwiązany. Jednak brak zasobów i/lub czasu często powoduje obejścia.

Aby móc zareagować na czas, system DQ musi informować użytkowników danych o „ich” regułach wraz z wynikami. Dobrym pomysłem jest korzystanie z panelu jakości danych (może z wysyłaniem wiadomości, że coś się pojawiło). Im wcześniej użytkownicy zostaną poinformowani o ustaleniach, tym lepiej.

Panel jakości danych powinien zawierać:

• Wszystkie reguły przypisane do danej roli
• Wyniki reguł (sygnalizacja, miary i przykładowe wiersze) z możliwością filtrowania reguł według wyników i dziedziny danych
• Obowiązkowy komentarz, który użytkownicy danych muszą wprowadzić w celu dokonania ustaleń
• Funkcja opcjonalnie „uchylania” wyniku (jeśli reguła jakości danych zgłasza błędy spowodowane na przykład wadliwą implementacją). Jeśli więcej niż jedna jednostka biznesowa ma przypisaną tę samą regułę jakości danych, „nadrzędne” jest ważne tylko dla jednostki biznesowej użytkownika danych (nie dla całej firmy).
• Pokazywanie reguł, które nie zostały wykonane lub które zostały naruszone

Kokpit powinien również pokazywać aktualny stan ostatniego procesu ładowania hurtowni danych, dając użytkownikom pełny wgląd w proces ładowania hurtowni danych.

Właściciel danych jest odpowiedzialny za upewnienie się, że każdy wynik został skomentowany, a stan jakości danych (oryginalny lub unieważniony) jest co najmniej żółty dla wszystkich użytkowników danych.

Aby uzyskać szybki przegląd, pomocne byłoby zbudowanie pewnego rodzaju prostych wskaźników KPI (kluczowych wskaźników wydajności) dla użytkowników danych/właścicieli danych. Posiadanie ogólnej sygnalizacji świetlnej dla wyników wszystkich powiązanych reguł jest dość łatwe, jeśli każda reguła ma taką samą wagę.

Osobiście uważam, że obliczanie ogólnej wartości jakości danych dla danej domeny danych jest dość złożone i wydaje się być kabalistyczne, ale można przynajmniej pokazać liczbę ogólnych reguł pogrupowanych według wyników dla domeny danych (np. „100 reguł DQ z wynikami 90% zielony, 5% żółty i 5% czerwony”).

Zadaniem właściciela danych jest zapewnienie, że ustalenia zostaną naprawione, a jakość danych poprawiona.

Doskonalenie procesów

Ponieważ procesy hurtowni danych często się zmieniają, mechanizm jakości danych również wymaga konserwacji.

Właściciel danych powinien zawsze dbać o następujące punkty:

• Utrzymuj go na bieżąco. Zmiany w hurtowni danych należy uchwycić w systemie jakości danych.
• Zwiększyć. Wdróż nowe reguły dotyczące błędów, które nie są jeszcze objęte regułami jakości danych.
• Opływowy. Wyłącz reguły jakości danych, które nie są już potrzebne. Skonsoliduj nakładające się reguły.

Monitorowanie procesów jakości danych

Monitorowanie całego procesu jakości danych pomaga z czasem go ulepszać.

Rzeczy warte obejrzenia to:

• Pokrycie Twoich danych regułami jakości danych
• Odsetek wyników dotyczących jakości danych w ramach aktywnych reguł w czasie
• Liczba aktywnych reguł jakości danych (Miej to na oku — widziałem, jak użytkownicy danych rozwiązują swoje ustalenia, po prostu wyłączając coraz więcej reguł jakości danych).
• Czas potrzebny w załadowaniu danych na ocenę i naprawę wszystkich wyników

Wniosek

Wiele z poniższych punktów jest ważnych w każdym projekcie.

Przewiduj opór. Jak widzieliśmy, jeśli nie ma pilnego problemu z jakością, jakość danych jest często postrzegana jako dodatkowe obciążenie bez oferowania nowych funkcji. Pamiętaj, że może to spowodować dodatkowe obciążenie dla użytkowników danych. W wielu przypadkach wymagania dotyczące zgodności i przepisów mogą pomóc przekonać użytkowników, aby postrzegali to jako nieuniknione wymaganie.

Znajdź sponsora. Jak wspomniano powyżej, DQ nie jest produktem szybko sprzedającym się, więc potrzebny jest potężny sponsor/udziałowiec – im wyższe kierownictwo, tym lepiej.

Znajdź sojuszników. Podobnie jak w przypadku sponsora, najbardziej pomocny byłby każdy, kto podziela ideę wysokiej jakości danych. Pętla obwodu DQ jest procesem ciągłym i wymaga ludzi, aby utrzymać pętlę obwodu przy życiu.

Zacznij od małych. Jeśli do tej pory nie było strategii DQ, poszukaj jednostki biznesowej, która potrzebuje lepszej jakości danych. Zbuduj prototyp, aby pokazać im korzyści z lepszych danych. Jeśli Twoim zadaniem jest ulepszenie lub nawet zastąpienie danej strategii jakości danych, przyjrzyj się sprawom, które działają dobrze / są akceptowane w organizacji i zachowaj je.

Nie trać z oczu całego obrazu. Chociaż zaczynasz od małych rzeczy, pamiętaj, że niektóre punkty, zwłaszcza role, są warunkiem wstępnym udanej strategii DQ.

Po wdrożeniu nie odpuszczaj. Proces jakości danych musi być częścią wykorzystania hurtowni danych. Z biegiem czasu koncentracja na jakości danych jest nieco zagubiona i od Ciebie zależy, czy ją utrzymasz.