digna Data Reconciliation: czy Twoje tabele docelowe nadal zgadzają się ze źródłami?

Każda platforma danych jest pełna tabel budowanych z innych tabel: dziennych agregatów sumowanych z pozycji transakcji i data martów składanych z kilkunastu systemów źródłowych. Każde z tych ładowań może zakończyć się bez błędu, a mimo to dać tabelę docelową, która nie zgadza się już z danymi, z których pochodzi, bo zmienił się filtr, pominięto spóźniony plik albo join po cichu zgubił wiersze. Najważniejsze pytanie brzmi: czy liczby nadal się zgadzają? Zwykle odpowiada się na nie ręcznie, o ile w ogóle.

digna to platforma Data Quality & Observability, a digna Data Reconciliation, nowość w Release 2026.11, zadaje to pytanie za Ciebie każdego dnia. Porównuje docelowe źródło danych ze źródłami, z których zostało zbudowane, i ostrzega, gdy przestają się zgadzać. To krótkie wideo pokazuje oba rodzaje reguł w projektach demonstracyjnych digna, na fikcyjnych danych i w prawdziwym produkcie.

Konfiguracja po stronie celu

Uzgadnianie zaczyna się od tabeli, której poprawność jest dla Ciebie ważna. Otwierasz docelowe źródło danych, przechodzisz do jego Data Reconciliation tab i tam definiujesz reguły, wykorzystując jako źródła dowolne źródła danych w projekcie, które mają włączone uzgadnianie.

Istnieją dwa rodzaje reguł, ponieważ niektóre zależności są proste i dokładne, a inne obejmują wiele źródeł i transformacji, których nikt nie chce odtwarzać w postaci kontroli.

Reguły dokładne dla uzgodnień, które już znasz

Reguła dokładna działa jak reguła jakości danych dla jednego źródła i jednego celu. Łączysz kontrole w pary według statystyki i atrybutu, na przykład liczbę wierszy w celu z liczbą wierszy w źródle albo sumę kwot z tą samą sumą o poziom niżej, i ustawiasz tolerancję bezwzględną lub względną. Oś czasu pokazuje następnie dzienną różnicę na tle tej tolerancji, dzięki czemu widać, czy rozbieżność jest jednorazowa, czy narasta od tygodni.

W demo dla handlu detalicznego dzienny agregat sprzedaży pos_sales_daily jest porównywany z pozycjami sprzedaży, z których powstaje, czyli pos_sales_lines. Przychód brutto zestawiany jest z przychodem zsumowanym z pozycji przy tolerancji ± 0,01%. 26 sierpnia agregat wykazywał 51 747 €, podczas gdy jego własne pozycje sumowały się do 66 205 €. Cel był więc zaniżony o 21,8% i daleko poza tolerancją.

Zespoły finansów, ryzyka i controllingu już wykonują takie kontrole w ramach standardowych procedur uzgadniania; jako reguły dokładne są one zapisywane raz i uruchamiane przy każdej inspekcji.

Reguły AI dla celów budowanych z wielu źródeł

Reguły dokładne przestają być praktyczne, gdy cel jest składany z wielu tabel za pomocą joinów, filtrów i agregacji, bo sprawdzanie go w ten sposób oznacza utrzymywanie drugiej kopii logiki pipeline'u.

Reguły AI idą inną drogą. Łączysz kontrole z kilku źródeł z jednym celem, bez definiowania joinów, filtrów czy agregacji i bez pisania SQL. Model uczy się na podstawie historii, jak cel podąża za swoimi źródłami, i ostrzega, gdy cel wychodzi poza pasmo dotychczasowych błędów reguły. Każda reguła AI ma trzy ustawienia, Sensitivity, Memory i Model Complexity, dzięki którym dopasujesz ją do konkretnego celu.

W demo data mart zamówień jest budowany z dziesięciu tabel źródłowych. 6 października zawierał 1742 zamówienia, podczas gdy jego źródła przewidywały około 2771, czyli mniej więcej o tysiąc mniej. Reguła to wychwyciła, choć nikt nie musiał opisywać, jak mart jest składany z tych dziesięciu tabel.

W Dashboard i w powiadomieniach

Kontrole uzgadniania pojawiają się w Dashboard z osią czasu dla każdej reguły. Wliczają się do ogólnego statusu inspekcji, obok pozostałych kontroli, i wyzwalają powiadomienia, dzięki czemu właściwe osoby dowiadują się o rozbieżności tego samego dnia, w którym wystąpiła.

Kto na tym zyskuje

Data engineerowie zyskują bezpośredni sposób walidacji wyników ETL: nie tylko tego, że ładowanie się wykonało, ale też tego, że jego wynik nadal zgadza się z danymi wejściowymi. Zespoły finansów, ryzyka i controllingu dostają swoje standardowe uzgodnienia jako reguły dokładne z widoczną historią. A ponieważ digna działa on-premises lub w Twojej chmurze prywatnej, dane nigdy nie opuszczają Twojej infrastruktury podczas sprawdzania. Dokumentacja Data Reconciliation wyjaśnia, jak skonfigurować oba rodzaje reguł.

digna Data Reconciliation pojawiło się w Release 2026.11 razem z digna Agentic i digna Engine, a przegląd wydania pokazuje, jak te trzy elementy ze sobą współgrają.

Zobacz wycieczkę po produkcie, aby poznać digna Data Reconciliation i resztę platformy w działaniu.

Najczęściej zadawane pytania

Co porównuje digna Data Reconciliation?

Porównuje docelowe źródło danych ze źródłami, z których zostało zbudowane, i ostrzega, gdy przestają się zgadzać. Reguły konfiguruje się w Data Reconciliation tab celu, a źródłem może być każde źródło danych w projekcie z włączonym uzgadnianiem.

Czym różnią się reguły dokładne od reguł AI?

Reguła dokładna łączy jedno źródło z jednym celem, zestawia kontrole w pary według statystyki i atrybutu, np. liczby wierszy lub sumy kwot, i stosuje tolerancję bezwzględną lub względną. Reguła AI łączy kontrole z kilku źródeł z jednym celem, uczy się z historii, jak cel za nimi podąża, i ostrzega, gdy cel wychodzi poza pasmo dotychczasowych błędów reguły.

Czy do reguł AI trzeba pisać SQL lub definiować joiny?

Nie. Reguła AI nie wymaga joinów, filtrów ani agregacji i nie trzeba pisać SQL. Każdą regułę można dostroić za pomocą ustawień Sensitivity, Memory i Model Complexity.

Jak raportowane są wyniki uzgadniania?

Każda reguła ma własną oś czasu w Dashboard. Kontrole uzgadniania wliczają się do ogólnego statusu inspekcji i wyzwalają powiadomienia, tak jak pozostałe kontrole digna.