digna Engine: wybierz, gdzie profilowane są Twoje dane
|
4
min. czyt.
Od początku digna profiluje dane tam, gdzie się znajdują: kontrole działają w Twojej własnej bazie danych, a digna pracuje na wynikach, a nie na kopiach tabel. Dla większości połączeń to nadal właściwe rozwiązanie i dlatego pozostaje ono ustawieniem domyślnym.
Nie każdy system źródłowy jest jednak wygodnym miejscem do takiej pracy i nie na każde pytanie da się odpowiedzieć w obrębie jednej bazy danych. Release 2026.11 rozwiązuje oba problemy: wprowadza digna Engine, drugie miejsce, w którym może działać profilowanie, oraz kontrolę integralności referencyjnej obejmującą dwa połączenia, nawet jeśli wskazują one na dwie różne technologie baz danych. Jednominutowe wideo pokazuje obie nowości.
Jedno ustawienie dla każdego połączenia z bazą danych
Każde połączenie z bazą danych w digna ma teraz lokalizację profilowania z dwiema wartościami. Source Database to ustawienie domyślne, działające tak jak dotychczas: profilowanie odbywa się w bazie danych, na którą wskazuje połączenie. digna Engine przenosi tę pracę do Engine, więc system źródłowy dostarcza dane, a Engine wykonuje profilowanie. Ustawienie jest dostępne dla każdej technologii źródłowej obsługiwanej przez digna, a ponieważ należy do połączenia, decyzję podejmujesz raz dla każdego systemu, a nie tabela po tabeli.
Kiedy zostawić profilowanie w źródłowej bazie danych
Gdy kontrole działają w źródle, dane pozostają w systemie, do którego należą. To upraszcza konfigurację i odpowiada politykom, które wymagają właśnie tego. Analityczne hurtownie danych są ponadto zbudowane do tego typu pracy i agregują duże tabele blisko miejsca ich przechowywania. Na platformie z zapasem mocy profilowanie na miejscu jest więc często najbardziej naturalnym wyborem: cała praca w jednym systemie i jedno miejsce, w którym sprawdzisz, co i kiedy zostało uruchomione.
Kiedy profilować w digna Engine
Sytuacja wygląda inaczej, gdy źródło jest mocno obciążone. Operacyjna baza danych obsługująca aplikacje przez cały dzień, hurtownia pracująca na granicy możliwości w nocnym oknie przetwarzania wsadowego czy platforma, na której każde zapytanie konkuruje z obciążeniami biznesowymi: w takich systemach zespół może chcieć, aby monitoring dokładał jak najmniej obciążenia. Przełączenie takiego połączenia na digna Engine odciąża źródło od pracy związanej z profilowaniem.
To, która opcja jest lżejsza, zależy od wielkości tabel, sieci i obciążenia danego źródła, dlatego ustawienie dotyczy pojedynczego połączenia: w ramach tego samego projektu digna możesz profilować na miejscu w hurtowni z wolnymi zasobami i używać Engine dla systemu produkcyjnego, który ich nie ma.
Integralność referencyjna między połączeniami i technologiami
W digna Data Validation kontrola integralności referencyjnej potwierdza, że każdy klucz w zbiorze danych ma odpowiadający mu rekord w zbiorze, do którego się odwołuje. W obrębie jednej bazy danych to proste porównanie, ale środowiska danych rzadko mieszczą się dziś w jednej bazie. Dane podstawowe klientów mogą znajdować się w Oracle, podczas gdy odwołujące się do nich zamówienia trafiają do PostgreSQL, albo hurtownia może przechodzić z Teradata na Snowflake obszar po obszarze, przez co tabele nadrzędne i podrzędne leżą na różnych platformach.
Od Release 2026.11 te relacje można sprawdzać bezpośrednio, między źródłami danych w różnych połączeniach i technologiach: Teradata i Snowflake, Oracle i PostgreSQL, Databricks i SQL Server lub dowolne inne dwie technologie obsługiwane przez digna. Kontrola działa z obiema lokalizacjami profilowania, a gdy połączenie profiluje w źródłowej bazie danych, do Engine eksportowane są na potrzeby porównania tylko kolumny kluczy. W Dashboard widać, kiedy kontrola obejmuje dwa połączenia, więc każdy, kto czyta wynik, wie, że dotyczy on dwóch systemów.
Twoja infrastruktura, niezależnie od wybranej lokalizacji
Obie lokalizacje profilowania działają w Twojej własnej infrastrukturze, on-premises lub w Twojej chmurze prywatnej, a digna Engine działa tam razem z resztą digna. Jej wybór zmienia miejsce profilowania w Twoim środowisku, a nie to, czy dane je opuszczają.
Dokumentacja profilowania szczegółowo objaśnia lokalizację profilowania, a dokumentacja Data Validation opisuje kontrole integralności referencyjnej i pozostałe typy reguł.
digna Engine jest częścią Release 2026.11, które wprowadziło także digna Agentic i digna Data Reconciliation; przegląd wydania omawia wszystkie trzy nowości.
Umów demo, aby zobaczyć obie lokalizacje profilowania i kontrolę integralności referencyjnej między technologiami na własnych połączeniach.
Najczęściej zadawane pytania
Czym jest lokalizacja profilowania połączenia z bazą danych?
To ustawienie każdego połączenia z bazą danych, które określa, gdzie odbywa się profilowanie: Source Database, ustawienie domyślne, uruchamia kontrole w samej bazie danych, a digna Engine wykonuje profilowanie w digna Engine. Jest dostępne dla każdej technologii źródłowej obsługiwanej przez digna.
Którą lokalizację profilowania wybrać?
To zależy od źródła. Profilowanie w źródłowej bazie danych utrzymuje całą pracę w jednym miejscu, co sprawdza się na platformach z zapasem mocy, a digna Engine odciąża mocno obciążone źródło. Ponieważ ustawienie dotyczy pojedynczego połączenia, dla każdego systemu możesz wybrać inaczej.
Czy digna może sprawdzać integralność referencyjną między Teradata a Snowflake?
Tak. digna Data Validation sprawdza integralność referencyjną między źródłami danych w różnych połączeniach i technologiach, m.in. Teradata i Snowflake, Oracle i PostgreSQL czy Databricks i SQL Server, przy dowolnej lokalizacji profilowania.
Czy nasze dane opuszczają naszą infrastrukturę, gdy używamy digna Engine?
Nie. digna Engine działa w Twojej własnej infrastrukturze, on-premises lub w Twojej chmurze prywatnej, tak jak reszta digna.
