Kontrola kompletności danych – praktyczny przewodnik dla nowoczesnych zespołów

Możesz mieć hurtownię danych, która na papierze wygląda na zdrową, a i tak przed lunchem wysłać błędny wynik do działu finansów. Codzienne ładowanie kończy się powodzeniem, pulpity nawigacyjne się odświeżają i nikt nie zauważa, że jedno wymagane pole nagle stało się puste, jedna partycja nie dotarła lub jedno źródło zmieniło format na tyle nieznacznie, aby prześlizgnąć się przez zwykłą, wyrywkową kontrolę liczby wierszy. W ten sposób zaufanie zaczyna topnieć, na długo przed tym, jak ktokolwiek zwoła sztab kryzysowy.

Testy kompletności danych to barierka ochronna między surowym pobieraniem danych a decyzjami, których ludzie są gotowi bronić. Trudność polega na tym, że kompletność to nie tylko pytanie „czy istnieją wartości puste”, ale także „czy właściwe rekordy dotarły na czas, we właściwe miejsce i z polami potrzebnymi firmie”. Dlatego najbardziej efektywne podejście traktuje kompletność jako kwestię przydatności do użycia, a nie tylko estetyczny miernik.

Spis treści

• Dlaczego braki w kompletności niszczą zaufanie, zanim ktokolwiek to zauważy

• Co weryfikują testy kompletności danych

  • Ujęcie na poziomie atrybutów i na poziomie rekordów

• Cztery formy testów kompletności, które będziesz wdrażać

  • Testy wierszy, kolumn, partii danych i relacji

• Techniki wykrywania: od zwykłego liczenia po porównania CDC

  • Zacznij od punktu odniesienia

  • Dodaj agregaty, znaczniki czasu i różnice

• Projektowanie SLA i alertów odróżniających opóźnienie od utraty danych

• Badanie i naprawianie nieudanego testu kompletności

• Jak platforma Observability działająca wewnątrz bazy danych zmienia postać rzeczy

• Tygodniowa lista kontrolna kompletności dla Twoich potoków danych

Dlaczego braki w kompletności niszczą zaufanie, zanim ktokolwiek to zauważy

Zespół finansowy, jakiego można by się spodziewać w każdej dużej strukturze hurtowni danych, dobrze zna ten schemat. Pulpit nawigacyjny nie przestaje działać, po prostu po codziennym ładowaniu przestaje zgadzać się z systemem źródłowym, a pierwszą wskazówką jest test porównawczy z sumami z zeszłego tygodnia. Ktoś ponownie sprawdza model, ktoś inny ponownie uruchamia raport i wtedy pojawia się problem. Kolumna wypadła z zasilania danych, ale potok wciąż zgłasza sukces.

Tego typu przeoczenie to dokładnie ten powód, dla którego oficjalne wytyczne dotyczące jakości statystycznej traktują kompletność jako kontrolę pierwszego stopnia. Rząd Szkocji zaleca sprawdzanie brakujących wartości, weryfikację oczekiwanej liczby wpisów danych, potwierdzanie obecności wszystkich zmiennych oraz porównywanie sum częściowych i sum wierszy lub kolumn ze sobą oraz z poprzednimi latami przed publikacją, a następnie testowanie anomalii pod kątem danych historycznych i innych opublikowanych źródeł w celu ustalenia, czy zmiana jest rzeczywista, czy to tylko błąd (Wytyczne rządu Szkocji dotyczące jakości statystycznej). Przekładając to na język hurtowni danych, jest to zadanie uzgadniania, a nie tylko wyszukiwanie wartości null.

Zespół, który sprawdza jedynie, czy kolumna zawiera wartości null, może przeoczyć niezauważalną utratę wierszy, zduplikowane wpisy lub ładowanie, które jest opóźnione, ale technicznie nie jest puste. Właśnie dlatego brak kompletności często najpierw objawia się eskalacją ze strony interesariuszy, a dopiero potem badaniem przyczyny źródłowej. Zanim raport zostanie przebudowany, szkody mają już charakter w równym stopniu wizerunkowy, co techniczny.

Zasada praktyczna: jeśli rozbieżność w pulpicie nawigacyjnym można pomylić ze zmianą biznesową, potrzebujesz testów kompletności zarówno pod kątem przepływu rekordów, jak i obecności pól, a nie tylko jednego z nich.

Jeśli oceniasz narzędzia pod kątem tego problemu, przydatne może być porównanie, jak różne produkty radzą sobie z operacyjnymi testami danych. Dobrym punktem wyjścia jest ocena oprogramowania dla wykonawców rządowych, ponieważ środowiska raportowe w sektorze publicznym mają tendencję do ujawniania tych samych mechanizmów braku kompletności, co hurtownie korporacyjne, tyle że z mniejszym marginesem na niejednoznaczność.

Co weryfikują testy kompletności danych

Użytecznym punktem wyjścia jest najprostszy miernik. Kompletność jest często wyrażana jako udział niebrakujących wartości w polu lub rekordzie, obliczany jako: Kompletność = (Liczba wartości innych niż Null / Całkowita liczba wartości) × 100%. Ten wzór jest pomocny, ponieważ sprawia, że kompletność można porównywać między tabelami, systemami i okresami, dając jeden wspólny język dla pola, wiersza lub całego zbioru danych (definicja miernika kompletności).

Zespół hurtowni danych zazwyczaj odczuwa ten miernik dopiero wtedy, gdy coś dalej w łańcuchu ulega awarii. Codzienne zasilanie zamówień może wyglądać na zdrowe na poziomie kolumny, podczas gdy kilka brakujących kluczy powoduje błędy złączeń, błędy w zliczaniu na pulpitach nawigacyjnych, a ścieżki audytu tracą ciągłość. Tabela klientów może nadal nadawać się do fakturowania, nawet jeśli jedno pole wzbogacające jest puste, ponieważ do fakturowania potrzebna jest tylko węższa część rekordu. Dlatego testy kompletności tak naprawdę dotyczą przydatności do użycia, a nie zmuszania do zapełnienia każdej komórki.

Ujęcie na poziomie atrybutów i na poziomie rekordów

Kompletność ma co najmniej dwie warstwy, które warto rozdzielić. Kompletność na poziomie atrybutu odpowiada na pytanie, czy określona kolumna jest uzupełniona. Kompletność na poziomie rekordu odpowiada na pytanie, czy wiersz zawiera wszystkie pola wymagane w danym scenariuszu użycia. Kolumna może średnio wyglądać dobrze, a mimo to pozostawiać garść krytycznych wierszy bezużytecznymi na dalszych etapach.

To rozróżnienie ma największe znaczenie podczas pobierania i ładowania do hurtowni danych. Jeśli w tabeli zamówień brakuje customer_id, order_date lub status, potok może nadal zapisywać wiersze, ale model nie pozwala już na bezpieczne wykonywanie złączeń, zestawień ani analiz audytowych. Wytyczne IBM dotyczące metod testowania danych wskazują ten sam kierunek: kompletność powinna skupiać się na krytycznych elementach danych, ponieważ nie każde pole ma taką samą wartość operacyjną (Metody testowania danych IBM).

Po zdefiniowaniu przypadku użycia test staje się znacznie wyraźniejszy. Decydujesz, które pola są wymagane, które stanowią opcjonalne wzbogacenie, a które wiersze nigdy nie mogą dotrzeć częściowo załadowane. W praktyce oznacza to, że reguły kompletności podążają najpierw za procesem biznesowym, a dopiero potem za schematem.

Hurtownia może być niekompletna dla celów analitycznych, a jednocześnie wystarczająco kompletna do celów raportowania kontrolnego. Różnica ta sprawia, że kompletność staje się decyzją dotyczącą terminowości i pokrycia SLA, zwłaszcza gdy spóźnione załadowanie jest bardziej szkodliwe niż załadowanie niepełne, ale wykonane na czas.

Cztery formy testów kompletności, które będziesz wdrażać

Test kompletności powinien odpowiadać awarii, którą próbujesz wychwycić. Model detaliczny z jednym oczekiwanym wierszem na sklep wymaga innego testu niż wymiar klienta z wymaganymi atrybutami, a oba te przypadki różnią się od codziennej partii danych, która w ogóle nie dotarła. Błędem jest traktowanie jednego schematu tak, jakby pokrywał każdą lukę.

Testy wierszy, kolumn, partii danych i relacji

Testy na poziomie wiersza weryfikują, czy każda oczekiwana encja jest obecna. Jeśli źródło wskazuje, że powinien istnieć jeden rekord na każdego aktywnego klienta, hurtownia powinna zawierać tę pełną populację, a nie tylko zbliżoną wartość. Ten wzorzec wychwytuje niezauważalną utratę wierszy i obcięcie ładowania danych, ale nie powie Ci, czy dane pole wewnątrz każdego wiersza jest puste.

Testy na poziomie kolumny sprawdzają, czy wymagane atrybuty są uzupełnione. Jeśli w tabeli faktów brakuje customer_id lub order_date, wiersz może nadal istnieć, podczas gdy model końcowy staje się niewiarygodny. Ten wzorzec sprawdza się dobrze w przypadku pól obowiązkowych, ale słabiej przy utracie danych między źródłem a celem.

Testy przyrostowe lub na poziomie partycji porównują partię danych z oczekiwaną zmianą (delta). Są one przydatne w przypadku codziennych plików, godzinowych strumieni lub tabel partycjonowanych, gdzie największym ryzykiem jest brakujący element. Test partycji wychwyci pominięty plik, ale nie wykryje, że jedna kolumna wewnątrz niego została uszkodzona.

Testy spójności referencyjnej potwierdzają, że klucze obce nadal działają. Wiersz faktów z wartością customer_id, która nie istnieje już w wymiarze, jest kompletny w wąskim sensie liczby wierszy, ale niekompletny pod kątem relacji. Zespoły zajmujące się CDC i hurtowniami danych często odkrywają to po zmianie schematu lub spóźnionej partii wymiaru.

Perspektywa CDC i monitorowania ma znaczenie, ponieważ problemy z kompletnością zwykle nakładają się na inne rodzaje awarii. Sformułowane przez firmę Monte Carlo ujęcie kompletności na poziomie atrybutów oraz poziomie rekordów jest przydatne, ponieważ oddziela luki w kolumnach od luk w wierszach (Przegląd kompletności Monte Carlo). Podejście źródło-cel firmy Adverity jest równie praktyczne, ponieważ traktuje kompletność jako weryfikację, czy wszystkie przewidywane dane zostały przeniesione ze źródła do celu (Test kompletności Adverity). Dla zespołów, które potrzebują konkretnego porównania źródła z celem, uzgadnianie danych w hurtowni nadaje temu sprawdzeniu bezpośredni wymiar operacyjny.

Hurtownia może być niekompletna dla celów analitycznych, a jednocześnie wystarczająco kompletna do celów raportowania kontrolnego. To sprawia, że kompletność staje się decyzją o przydatności do użycia powiązaną z terminowością i pokryciem SLA. Spóźnione ładowanie może zaszkodzić bardziej niż niepełne dane wprowadzone na czas, ponieważ zadania na dalszych etapach mogły już stracić swoje okno czasowe.

Techniki wykrywania: od zwykłego liczenia po porównania CDC

Nie potrzebujesz potężnego frameworka, aby zacząć. Zespoły rozpoczynają od liczenia wierszy i współczynnika wartości pustych, a następnie dodają silniejsze mechanizmy kontrolne w miarę wzrostu wartości lub wrażliwości danych. Chodzi o to, aby łączyć techniki tak, by każda z nich wychwytywała inną klasę przeoczeń.

Zacznij od punktu odniesienia

Test punktu odniesienia jest zazwyczaj pierwszą linią obrony.

select count(*) as row_count
from fact_orders;

select count(*) as row_count
from fact_orders;

select count(*) as row_count
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

select
  count(*) as total_rows,
  sum(case when customer_id is not null then 1 else 0 end) as populated_customer_id
from fact_orders;

Te testy są tanie, zrozumiałe i łatwe do zautomatyzowania. Wychwytują oczywistą utratę rekordów oraz puste pola, dlatego warto je stosować nawet w dojrzałych hurtowniach.

Dodaj agregaty, znaczniki czasu i różnice

Gdy proste zliczanie wierszy to za mało, dodaj agregacje i sumy kontrolne.

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

select
  sum(order_total) as total_amount,
  count(distinct order_id) as distinct_orders
from fact_orders;

Ten wzorzec wykrywa sytuacje, w których liczba wierszy wygląda poprawnie, ale ładunek zmienił się w trakcie przesyłania. W przypadku modeli przyrostowych najbardziej wymownym sygnałem jest często znacznik czasu (watermark).

select max(updated_at) as high_water_mark
from fact_orders_incremental;

select max(updated_at) as high_water_mark
from fact_orders_incremental;

select max(updated_at) as high_water_mark
from fact_orders_incremental;

Jeśli znacznik czasu przestaje się przesuwać, potok utknął w miejscu, nawet jeśli wczorajsza liczba rekordów wciąż wygląda normalnie. W przypadku systemów źródłowych generujących zdarzenia zmian, różnice CDC są skuteczniejsze, ponieważ porównujesz to, co trafiło do hurtowni, z tym, co wysłało źródło.

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

, pseudocode
compare source_events to target_events by primary_key and operation_type
report missing_rows and extra_rows

Jednym z użytecznych odniesień dla tego wzorca porównywania źródła z celem jest artykuł wyjaśniający znalezienie różnic uzgadniania, ponieważ kompletność i uzgadnianie to bardzo bliskie sobie operacyjnie pojęcia.

W tym zestawie mieści się również terminowość. Zbiór danych może być strukturalnie obecny, ale wciąż niekompletny z punktu widzenia decyzji operacyjnej, jeśli dotrze po oknie SLA. Dlatego opóźnionych danych nie należy traktować marginalnie. Często jest to ta sama klasa awarii, tyle że w innej masce.

Jeśli firma potrzebuje danych do godziny 8 rano, idealnie uzupełniona tabela o godzinie 11 wciąż jest niekompletna dla decyzji, którą miała wspierać.

Projektowanie SLAs i alertów, które odróżniają opóźnienia od utraty danych

Hurtownia danych może być pełna, a mimo to spóźnić się na określony termin. Partia danych zostaje wgrana, liczba wierszy wygląda dobrze, a pulpit nawigacyjny świeci na zielono, ale zespół biznesowy potrzebował tej tabeli przed porannym odcięciem. Projektowanie SLA musi odróżniać opóźnienie od utraty danych, zanim powiadomienie trafi na dyżurny komunikator, ponieważ te dwie sytuacje wymagają różnych reakcji.

Kategoryzacja daje praktyczny sposób na rozwiązanie tego problemu. Poziom 1 (Tier 1) powinien obejmować pola leżące u podstaw kluczowych decyzji, w których brakujące wartości oznaczają, że dane nie nadają się do użytku. Poziom 2 (Tier 2) sprawdza się w przypadku kolumn operacyjnych, gdzie niewielka luka ma znaczenie, ale nie zawsze uzasadnia natychmiastowe wzywanie programisty. Poziom 3 (Tier 3) pasuje do pól dodatkowych (enrichment), które lepiej po prostu obserwować pod kątem odchyleń, niż eskalować każdą zmianę. Arkusz roboczy jakości danych instytucji CDC dobrze wpisuje się w ten schemat, ponieważ zaczyna od minimalnych i kluczowych elementów najważniejszych dla danego zastosowania, a rozszerza się o dodatkowe pola tylko wtedy, gdy wpływają one na decyzję (Arkusz jakości danych CDC).

Punkty odniesienia muszą pochodzić bezpośrednio z samego źródła. Spadek wolumenu zdarzeń może być normalny dla jednego strumienia i stanowić duży problem w innym, więc próg ustawiony dla całej hurtowni zazwyczaj więcej ukrywa niż ujawnia. Ładowany co noc plik, którego rozmiar jest stabilny od miesięcy, wymaga ściślejszych reguł niż API, którego ruch naturalnie waha się wraz z aktywnością użytkowników. Wytyczne rządu Szkocji zwracają uwagę na to samo innymi słowy: analitycy powinni porównać zmianę z wcześniejszymi wzorcami i innymi punktami odniesienia, zanim uznają ją za rzeczywistą (Wytyczne rządu Szkocji dotyczące jakości statystycznej).

Prosty model ruterowania pozwala dopasować reakcję do wpływu biznesowego.

• Tabele krytyczne: natychmiastowe wezwanie dyżurnego właściciela.

• Tabele operacyjne: wysłanie alertu na kanał danych i utworzenie zgłoszenia.

• Tabele dodatkowe: wysłanie raportu okresowego i przeanalizowanie trendu na cotygodniowym spotkaniu dotyczącym governance.

Model wykonania również ma znaczenie. Jeśli testy są uruchamiane bezpośrednio w bazie danych klienta, zespół może porównywać aktualność, zmiany schematu oraz kompletność na poziomie rekordu z tym samym źródłem prawdy, bez konieczności łączenia osobnych zadań i pulpitów nawigacyjnych. digna wdraża tego typu Observability wewnątrz bazy danych, łącząc historyczne punkty odniesienia z walidacją i monitorowaniem w jednym interfejsie (Przegląd Observability digna). Taka konfiguracja zmienia sytuację operacyjną, ponieważ spóźnione zasilanie danych, brakująca partycja oraz rzeczywiste uszkodzenie schematu mogą być oceniane w tym samym miejscu, zanim ktokolwiek podejmie decyzję o wezwaniu pomocy, utworzeniu zgłoszenia czy poczekaniu.

Badanie i naprawianie nieudanego testu kompletności

Tabela faktów zamówień może pomyślnie przejść zliczanie wierszy i wciąż zawieść tam, gdzie to kluczowe. Widziałem ten schemat najwyraźniej, gdy tabela miała wszystkie wiersze, ale test spójności referencyjnej z wymiarem klientów zaczął zgłaszać błędy po tym, jak spóźniona partia zaktualizowała niektóre klucze. Liczby na pierwszy rzut oka wyglądały w porządku, ale złączenie przestało być wiarygodne.

Pierwszym krokiem jest określenie zakresu. Sprawdź, które partycje uległy awarii, które źródła wyższego szczebla je zasilały i czy problem ogranicza się do jednego dnia, czy też dotyczy dłuższego okresu. Następnie porównaj czas nadejścia danych z oczekiwanym harmonogramem dostaw, ponieważ brakująca lub spóźniona partia często wyjaśnia objawy szybciej niż głęboka analiza struktury schematu.

Drugim krokiem jest odróżnienie problemów przejściowych od strukturalnych. Przejściowa luka wygląda jak opóźniona dostawa, opóźnienie w nadrabianiu zaległości (backfill) lub awaria źródła danych. Luka strukturalna zwykle wskazuje na zmianę schematu, błędną wartość domyślną, problem z ruterowaniem lub regułę transformacji, która przestała odpowiadać źródłu.

W jednym z incydentów przyczyną była zmiana schematu, która wprowadziła nowy kod statusu bez domyślnej ścieżki obsługi. Rozwiązaniem nie było proste „uruchom zadanie ponownie”. Zespół musiał zdecydować, czy uzupełnić dane wstecznie z logów CDC, zaakceptować lukę z udokumentowanym wyjątkiem, czy też zablokować odbiorców końcowych do czasu, aż wymiar klienta będzie ponownie spójny. Właściwa odpowiedź zależy od tego, czy decyzje biznesowe na dalszych etapach mogą tolerować częściowe dane.

Pomocny jest prosty schemat klasyfikacji:

1. Potwierdź charakter awarii. Czy to utrata wierszy, utrata pól czy utrata spójności referencyjnej?

2. Sprawdź czas po stronie źródła. Czy źródło dostarczyło dane z opóźnieniem, czy w ogóle ich nie przesłało?

3. Zbadaj historię zachowań. Czy to nietypowe dla tego źródła, czy mieści się w granicach normalnej zmienności?

4. Wybierz sposób naprawy. Wsteczne uzupełnienie (backfill), ignorowanie awarii, blokada lub udokumentowanie.

Wykonanie tych kroków jest szybsze, gdy Twoja hurtownia przechowuje już informacje o powiązaniach (lineage), aktualności i historię testów w sposób, który operatorzy mogą kontrolować bez przełączania się między pięcioma różnymi narzędziami.

Jak platforma Observability działająca wewnątrz bazy danych zmienia postać rzeczy

Wiele zespołów wciąż uruchamia testy kompletności jako zaplanowane zapytania SQL, przegląda wyniki w narzędziach BI i przesyła alerty przez czat. To działa do momentu, gdy liczba potoków danych rośnie, a testowanie zaczyna konkurować z bieżącą pracą nad produktem. Platforma Observability działająca wewnątrz bazy danych zmienia ten układ operacyjny, wykonując zadania tam, gdzie dane już się znajdują, i ucząc się na podstawie wskaźników historycznych, zamiast wymagać ręcznego dostrajania każdego testu.

To rozróżnienie ma znaczenie z dwóch powodów. Po pierwsze, dane klientów pozostają w środowisku klienta, gdy platforma działa bezpośrednio w bazie, co ogranicza przesyłanie danych i pozwala zachować wrażliwe rekordy w prywatnej chmurze lub strukturach lokalnych (on-premise). Po drugie, platforma może łączyć sygnały Observability – takie jak wykrywanie anomalii, sprawdzanie terminowości i śledzenie zmian schematu – z regułami walidacji jakości danych w jednym miejscu, zamiast zmuszać inżynierów do konfigurowania osobnych narzędzi dla każdej warstwy.

Praktycznym rezultatem jest prostszy stos technologiczny do wykrywania błędów. Zamiast dziesiątek zaplanowanych zadań otrzymujesz spójny zestaw stale działających procesów kontrolnych, które wychwytują brak danych, zmiany w schemacie i nieoczekiwane zachowania w odniesieniu do wyuczonych punktów odniesienia. To sprawdza się znacznie lepiej, gdy hurtownia jest duża, źródła są niestabilne, a biznes potrzebuje szybkiej odpowiedzi na pytanie, czy brak danych to opóźnienie, czy trwała utrata.

Dla zespołów, które chcą utrzymać mechanizmy kontrolne blisko danych, opis platformy digna jasno pokazuje ten model. Nie zastąpi on dobrego projektu hurtowni danych ani nie naprawi braku odpowiedzialności za procesy, ale znacznie skraca czas od wykrycia problemu przez analizę po reakcję.

Tygodniowa lista kontrolna kompletności dla Twoich potoków danych

Zacznij od wybrania dwóch krytycznych elementów danych na potok, a następnie zdefiniuj dla każdego z nich jeden test na poziomie atrybutu i jeden na poziomie rekordu. Zapobiegnie to klasycznemu błędowi monitorowania każdego pola z tym samym priorytetem i przeoczenia tych, które decydują o poprawności procesów kontrolnych.

W następnym kroku dodaj znacznik czasu (watermark) lub porównanie CDC. Pozwoli to wychwycić cichą utratę partii danych i zatrzymanie przyrostowego ładowania, czego samo liczenie wierszy może nie wykazać. Jeśli potok opiera się na przetwarzaniu wsadowym, porównuj czasy nadejścia z oczekiwanym harmonogramem, aby spóźnione zasilanie nie wywołało takiej samej reakcji jak całkowity brak danych.

Następnie skonfiguruj kategoryzację SLA. Nadaj najważniejszym tabelom twarde wartości progowe i szybkie ścieżki powiadamiania, a dla pól dodatkowych zastosuj monitorowanie trendów, aby nie niepokoić ludzi nieistotnymi powiadomieniami.

Zaplanuj cotygodniowy przegląd, podczas którego operatorzy przeanalizują anomalie, dostosują progi i udokumentują wyjątki. To moment, w którym kompletność staje się stale utrzymywanym procesem kontrolnym, a nie tylko jednorazową regułą.

Kompletność to nie jest stała liczba, którą po prostu osiągasz – to wynikająca z Twoich potrzeb decyzja o przydatności danych do użycia, którą podejmujesz i stale weryfikujesz.

digna pomaga zespołom uruchamiać testy kompletności danych bezpośrednio tam, gdzie te dane się znajdują, a następnie łączyć je z monitorowaniem anomalii, aktualności i spójności schematu w jednym kontrolowanym środowisku. Jeśli chcesz zwiększyć zaufanie do swojej hurtowni bez rozpraszania testów po różnych skryptach i pulpitach nawigacyjnych, odwiedź platformę digna i zobacz, jak in-database Observability może wpisać się w proces przeglądu Twoich potoków danych.