Przetwarzanie w bazie danych (in-database processing) uruchamia analitykę i monitorowanie bezpośrednio w silniku bazy danych klienta, dzięki czemu dane pozostają na miejscu, a narzut związany z transferem znika. Ma to największe znaczenie, gdy hurtownia jest duża, wrażliwa lub jedno i drugie, ponieważ wybór nie dotyczy tylko szybkości, lecz tego, czy kontrola odbywa się tam, gdzie dane już się znajdują.

Słabość zwykle ujawnia się najpierw w poniedziałek rano. Pulpit przestaje się aktualizować, w raporcie finansowym brakuje wierszy albo alert o aktualności uruchamia się dopiero wtedy, gdy użytkownicy biznesowi już zauważyli problem – a pierwotna przyczyna jest często ta sama: dane musiały opuścić jeden system, zanim mogły zostać przeanalizowane w innym.

Spis treści

• Gdy przenoszenie danych psuje pulpity

• Jak ewoluowało i jak działa przetwarzanie w bazie danych

  • Od przyspieszania hurtowni do analityki natywnej dla bazy danych

• Wykonywanie w bazie danych a procesy typu ekstrakcja–analiza

  • Kiedy które podejście zwykle wygrywa

• Jak digna realizuje obserwowalność wewnątrz Twojej hurtowni

  • Co dzieje się wewnątrz hurtowni

• Kiedy przetwarzanie w bazie danych nie jest właściwym wyborem

  • Tryby awarii są praktyczne, a nie teoretyczne

• Zastosowania branżowe wymagające niezawodności w bazie danych

  • Wspólne ograniczenie tych branż

• Podejmowanie decyzji: czy przetwarzanie w bazie danych pasuje do Twojego stosu

  • Krótka lista kontrolna do podjęcia decyzji

Gdy przenoszenie danych psuje pulpity

Awaria zazwyczaj zaczyna się bez ostrzeżenia. Strumień danych do hurtowni dociera na czas, zadanie ekstrakcji się wykonuje, a zewnętrzny silnik otrzymuje coś, co wygląda na czystą kopię. Potem jedno opóźnienie w systemie źródłowym, jedna źle sformatowana kolumna lub jedna zbyt duża partia sprawia, że liczby odchylają się na tyle, iż pulpit przestaje odpowiadać oczekiwaniom biznesu.

Na tym polega główna zaleta przetwarzania w bazie danych. Silnik bazy danych wykonuje pracę tam, gdzie dane już się znajdują, dzięki czemu zespoły unikają etapu ekstrakcji, który zwiększa opóźnienia, tworzy dodatkowe kopie i poszerza powierzchnię ataku. Argumenty historyczne za tym modelem są spójne od połowy lat 90., ale szersze zastosowanie przyszło dopiero w połowie pierwszej dekady XXI wieku, gdy analityka przeniosła się z zewnętrznych stacji roboczych do korporacyjnych hurtowni danych, a kolumnowe bazy danych sprawiły, że skanowanie i agregacja po stronie hurtowni stały się praktyczne. Historyczny przegląd przetwarzania w bazie danych wyraźnie pokazuje ten łuk rozwoju.

Dobry przykład pulpitu pomaga zarysować problem. Jeśli obserwowana metryka jest już wyprowadzana z tabel hurtowni, to wyciąganie tych tabel do innego silnika tylko po to, by sprawdzić aktualność lub dryf schematu, tworzy drugi punkt awarii. Aby szybko zobaczyć, jak zwykle wyglądają powierzchnie raportowe, przejrzyj przykłady pulpitów GTM od Yalc i porównaj, w jaki sposób metryki operacyjne zależą od czystych, aktualnych danych źródłowych.

Praktyczna zasada: jeśli kontrola może zawieść, ponieważ dane musiały zostać przeniesione, architektura już wykonuje więcej pracy, niż oczekiwał użytkownik.

Dlatego nowoczesne platformy obserwowalności coraz częściej traktują samą hurtownię jako miejsce wykonywania. Osobny silnik nadal może być przydatny, ale koszt przenoszenia regulowanych danych o dużych wolumenach często przewyższa wygodę zewnętrznego procesu. Zespoły, które utrzymują obliczenia blisko danych, zwykle zyskują lepszą kontrolę nad ładem danych i unikają niezręcznej luki między stwierdzeniem „źródło jest w porządku” a „kopia raportowa jest błędna”.

Jeśli już teraz widzisz zduplikowane tabele, opóźnione pulpity lub prace uzgadniające, które powtarzają się każdego ranka, problemem prawdopodobnie nie jest definicja metryk. Jest nim dodatkowy przeskok.

W przypadku pokrewnego trybu awarii zobacz, jak redundancja danych powoduje anomalie w systemach analitycznych i raportowych, ponieważ zduplikowane kopie często wyjaśniają, dlaczego jeden zespół ufa liczbom, a inny nie.

Jak ewoluowało i jak działa przetwarzanie w bazie danych

Ta architektura nie pojawiła się z dnia na dzień. Systemy analityki w bazie danych zyskały znaczenie komercyjne w połowie lat 90., a następnie szerszą popularność w połowie pierwszej dekady XXI wieku, gdy zespoły odpowiedzialne za hurtownie przestały traktować analitykę jako coś, co musi odbywać się na osobnej stacji roboczej. Kluczowa idea była prosta: pozostawić dane na miejscu, ograniczyć ich przenoszenie i wykonywać prace statystyczne tam, gdzie dane już się znajdowały.

Często przywoływanym kamieniem milowym tej zmiany była konferencja Teradata Partners w Orlando w dniach 18–22 września 2005 roku, podczas której Thomas Tileston przedstawił koncepcję przyspieszenia eksploracji danych przez połączenie SAS i Teradata wewnątrz hurtowni. Ten moment miał znaczenie, ponieważ przekształcił niszową optymalizację we wzorzec korporacyjny. Kolumnowe bazy danych, zbudowane z myślą o analityce, hurtowniach danych i raportowaniu, uczyniły to podejście praktycznym, usprawniając sposób, w jaki systemy skanują i agregują duże zbiory danych.

Od przyspieszania hurtowni do analityki natywnej dla bazy danych

Nowoczesne systemy wykonują obecnie obliczenia bezpośrednio w silniku bazy danych, zamiast wyodrębniać dane do pamięci roboczej. Dokumentacja IBM stwierdza, że operowanie na danych w bazie danych pozwala uniknąć problemów z bezpieczeństwem związanych z ich wyodrębnianiem, a projekt MADlib opisuje się jako oparta na SQL biblioteka uczenia maszynowego, eksploracji danych i statystyki, która działa na dużą skalę w silniku bazy danych bez importu ani eksportu do innych narzędzi. Z punktu widzenia architektury analityka staje się sprawą bazy danych, a nie dodatkiem obok niej.

Funkcje analityczne Teradata działające w bazie danych rozwinęły tę ideę w kierunku szerokiego modelu bibliotecznego, a jedno z cytowanych źródeł wskazuje ponad 200 funkcji analitycznych w architekturze shared-nothing, w tym profilowanie, statystyki opisowe i próbkowanie. Właśnie dzięki takiemu zakresowi model ten przetrwał dłużej niż wczesne strojenie hurtowni i stał się przydatny w operacjach z silnym naciskiem na ład danych.

Praktyczny kompromis nadal istnieje. Gdy baza danych przejmuje więcej logiki, wydajność zależy od planowania zapytań, indeksowania, lokalności pamięci i wykonywania wektorowego. Dobrze dostrojony silnik może uczynić z tego atut, ale źle dostrojony zamienia pracę w bazie danych w wąskie gardło.

Historia ma znaczenie, ponieważ wyjaśnia, dlaczego nie jest to już eksperyment. Zespoły nie wdrażają sprytnej sztuczki, lecz stosują dojrzały wzorzec wykonywania, który został już ukształtowany przez ograniczenia skali hurtowni.

Jeśli porównujesz nowoczesne wzorce przechowywania i wykonywania, przydatną lekturą uzupełniającą jest artykuł czym jest otwarty format tabel, ponieważ dyskusja o otwartym przechowywaniu często pokrywa się z pytaniem, gdzie powinna działać analityka.

Wykonywanie w bazie danych a procesy typu ekstrakcja–analiza

Zasadnicze pytanie brzmi: gdzie powinna odbywać się praca i jak ten wybór wpływa na bezpieczeństwo, opóźnienia i złożoność operacyjną.

Wykonywanie w bazie danych utrzymuje duże lub wrażliwe zbiory danych w systemie źródłowym, więc inny silnik nie musi odczytywać ich przez sieć. Ma to znaczenie w środowiskach korporacyjnych, w których hurtownia źródłowa już podlega wymaganiom w zakresie ładu danych, kontroli dostępu i audytu. Kompromis nie jest teoretyczny. Silnik bazy danych ma teraz więcej pracy, więc złe plany zapytań, słabe indeksowanie lub duże obciążenie współbieżne mogą jednocześnie spowolnić zadania produkcyjne i kontrole obserwowalności.

Wytyczne IBM dotyczące analityki w bazie danych jasno wskazują, że utrzymywanie danych w bazie danych pozwala uniknąć problemów z bezpieczeństwem związanych z ich wyodrębnianiem, dlatego ten model często pojawia się w środowiskach regulowanych. Praktyczne porównanie bezpieczniejszego wykonywania w bazie danych z zewnętrznymi potokami znajdziesz w porównaniu wykonywania w bazie danych i zewnętrznych potoków.

Dryf schematu jeszcze wyraźniej uwydatnia tę różnicę. Artykuł Jak redundancja powoduje anomalie w systemach analitycznych i raportowych wyjaśnia, dlaczego dodatkowe kopie często tworzą sprzeczne wersje tego samego faktu. Gdy obserwowalność, kontrole jakości lub wykrywanie anomalii działają poza hurtownią, zespoły często poświęcają więcej czasu na uzgadnianie kopii niż na naprawę rzeczywistego problemu.

Kiedy które podejście zwykle wygrywa

• Przetwarzanie w bazie danych wygrywa, gdy dane są zbyt wrażliwe, by je przenosić, zbyt duże, by je często kopiować, lub zbyt ważne, by nie sprawdzać ich zaraz po dotarciu.

• Ekstrakcja–analiza wygrywa, gdy zbiór danych jest mały, logika ma charakter eksperymentalny lub hurtownia nie powinna przejmować dodatkowego obciążenia analitycznego.

• Wzorce hybrydowe wygrywają, gdy ład danych musi pozostać blisko hurtowni, ale prace eksploracyjne wymagają osobnego środowiska.

Badania o charakterze benchmarków dotyczące obciążeń hurtowni mierzą czas odpowiedzi, przepustowość i całkowity koszt. Benchmarki czasu rzeczywistego sprawdzają, czy system potrafi przyjmować napływające strumienie bez opóźnień. Ma to znaczenie, ponieważ kontrole obserwowalności zachowują się jak wrażliwe na opóźnienia obciążenia hurtowni, a nie jak zadania raportowania offline.

Jak digna realizuje obserwowalność wewnątrz Twojej hurtowni

digna utrzymuje obliczanie metryk we własnych bazach danych klienta, dzięki czemu dane pozostają na miejscu, podczas gdy platforma je ocenia. To właściwy model dla zespołów, dla których ład danych jest priorytetem, ponieważ warstwa obserwowalności nie musi kopiować danych produkcyjnych w inne miejsce, zanim będzie mogła sprawdzić aktualność, schemat lub zachowanie.

Model operacyjny koncentruje się na pięciu wymiarach: aktualności, wolumenie, schemacie, rozkładzie i pochodzeniu danych. To praktyczne mechanizmy monitorowania zachowania danych, a nie tylko sprawdzania, czy pojedyncza reguła była spełniona w danym momencie. Hurtownia może wyglądać zdrowo w jednej partii, a mimo to dryfować w innej, dlatego kontrole muszą śledzić dane w czasie.

Co dzieje się wewnątrz hurtowni

Monitorowanie dryfu schematu porównuje przychodzący lub wywnioskowany schemat z oczekiwaną linią bazową lub schematem kontraktowym, a następnie klasyfikuje dodania, usunięcia, zmiany nazw i zmiany typów danych w celu obsługi według ważności. Ten szczegół ma znaczenie, ponieważ brakująca kolumna i kolumna o zmienionej nazwie zwykle nie wymagają tej samej reakcji. Rygorystyczny alert przy każdej zmianie generuje szum, a brak jakiegokolwiek alertu pozostawia systemy w dalszych etapach bez ochrony.

Monitorowanie terminowości sprawdza, czy dane dotarły zgodnie z harmonogramem, wcześniej czy później, a wykrywanie anomalii uczy się zachowania zbioru danych bez konieczności ręcznego konfigurowania reguł dla każdego przypadku. To przejście od sztywnych reguł do uczenia się linii bazowej sprawia, że system jest praktyczny w skali przedsiębiorstwa, zwłaszcza gdy strumienie danych różnią się w zależności od dnia, źródła lub cyklu biznesowego.

Wykonywanie w bazie danych na platformie dobrze odpowiada także na typowe pytanie przedsiębiorstw: jak monitorować aktualność i naruszenia reguł biznesowych, nie zamieniając każdego incydentu w ręcznie budowany projekt utrzymaniowy? Odpowiedzią jest zwykle pozostawienie obliczeń hurtowni, a interpretacji wzorców warstwie obserwowalności.

Zasada operacyjna: jeśli monitor wymaga ciągłego ręcznego dostrajania tylko po to, by nie generować szumu, to nie jest obserwowalność, lecz zmęczenie alertami z dodatkowymi krokami.

Dokumentacja digna opisuje również licencjonowanie modułowe z opłatą podstawową oraz opłatą za każdą aktywną tabelę w każdym module. Taka struktura ma znaczenie operacyjne, ponieważ zespoły rzadko potrzebują wszystkich funkcji od pierwszego dnia – zwykle zaczynają od jednego problemu, a następnie rozszerzają zakres, gdy wzorzec się sprawdzi.

Dla zespołów porównujących style implementacji przydatnym przykładem pokrewnym są kontrole dotyczące usunięcia OpenDatabase, pokazujące, jak inspekcję po stronie hurtowni można ująć jako kontrolowaną czynność audytową, a nie zewnętrzny eksport danych.

Praktyczna korzyść jest prosta. Dane pozostają w środowisku klienta, metryki są obliczane tam, gdzie dane już się znajdują, a liczba miejsc, w których nieaktualna kopia może stać się „prawdą”, maleje.

Kiedy przetwarzanie w bazie danych nie jest właściwym wyborem

Nawet najlepsza konfiguracja przetwarzania w bazie danych ma swoje ograniczenia. Jeśli silnik nie potrafi dobrze zaplanować zapytania, wykorzystać lokalności pamięci ani skorzystać z wykonywania wektorowego, praca związana z obserwowalnością staje się narzutem dla środowiska produkcyjnego, a nie zabezpieczeniem.

Tryby awarii są praktyczne, a nie teoretyczne

Pierwszym z nich jest kompatybilność. Nie każda baza danych udostępnia te same funkcje analityczne i nie każde środowisko pozwala na ten sam poziom pushdown. Jeśli platforma nie może wykonać potrzebnych kontroli w silniku, zespoły zwykle kończą na przywróceniu eksportów tylnymi drzwiami.

Drugim jest rywalizacja o zasoby. Hurtownia, która już obsługuje BI i analizy ad hoc, może zostać spowolniona, jeśli zadania obserwowalności są źle zaplanowane lub zbyt kosztowne, by wykonywać je bezpośrednio. Planowanie zapytań i indeksowanie mają tu znaczenie, a „utrzymuj to w bazie danych” nigdy nie oznacza „uruchamiaj wszystko natychmiast”.

Trzecim jest przesadny zakres. Lekka analityka, krótkotrwałe analizy lub zbiory danych o niskim ryzyku często nie uzasadniają kosztów konfiguracji. W takich przypadkach prostszy proces zewnętrzny może być łatwiejszy w utrzymaniu i łatwiejszy do późniejszego wycofania, zwłaszcza gdy zespoły mają już potok danych ETL, który przejmuje obciążenie operacyjne.

Utrzymuj kontrole tam, gdzie znajdują się dane, tylko wtedy, gdy silnik może przejąć tę pracę, nie stając się sam problemem.

Kompromis w przedsiębiorstwie jest jasny. Wykonywanie w bazie danych może ograniczyć przenoszenie danych i pomóc w utrzymaniu regulowanych danych w środowisku klienta, ale stawia też większe wymagania stosowi bazodanowemu. Jeśli zespół nie kontroluje kształtu zapytań, projektu indeksów ani izolacji obciążeń, model nadal może zawieść przy dużej skali.

Wybór nie jest kwestią ideologii. Sprowadza się do tego, czy hurtownia może przejąć obciążenie związane z monitorowaniem bez tworzenia nowych wąskich gardeł, nowej pracy związanej ze strojeniem lub nowej presji kosztowej. Jak wspomniano wcześniej, niektóre obciążenia lepiej obsługiwać wewnątrz hurtowni, a inne czyściej poza nią.

Zastosowania branżowe wymagające niezawodności w bazie danych

Sektory regulowane interesują się tym wzorcem z tego samego powodu: nie mogą sobie pozwolić na drugą, dryfującą kopię prawdy. Zespoły z sektora usług finansowych, ochrony zdrowia, telekomunikacji i sektora publicznego mają do czynienia z danymi wrażliwymi, wymagającymi identyfikowalności lub krytycznymi czasowo pod względem operacyjnym, więc kontrola musi odbywać się bez zbędnego przenoszenia danych.

Zespoły finansowe zwykle muszą sprawdzać dane transakcyjne, dotyczące ryzyka i regulacyjne na miejscu. Jeśli proces monitorowania eksportuje dane do innego środowiska, może kolidować z wymogami dotyczącymi lokalizacji danych, oczekiwaniami audytowymi lub kontrolami wewnętrznymi. Zespoły w ochronie zdrowia mierzą się z inną presją: opóźnione ładowania lub zmiany schematu mogą zniekształcić raportowanie kliniczne i operacyjne, a tego problemu nie chce się odkrywać po fakcie.

Zespoły telekomunikacyjne obsługują nieustanne strumienie danych o dużych wolumenach, więc ciągłe wykrywanie anomalii musi działać bez obciążającego wąskiego gardła w postaci eksportu. Zespoły z sektora publicznego potrzebują dowodów, że same kontrole podlegają audytowi, co sprawia, że wykonywanie w bazie danych jest atrakcyjne, ponieważ ślad monitorowania pozostaje blisko środowiska objętego ładem danych.

Wspólne ograniczenie tych branż

Wspólnym mianownikiem nie jest branża, lecz operacyjny charakter danych. Każde z tych środowisk potrzebuje monitorowania, które jest wystarczająco szybkie, by mieć znaczenie, wystarczająco rygorystyczne, by spełnić wymogi ładu danych, i wystarczająco odizolowane, by nie tworzyć nowych kopii odbiegających od źródła.

Dlatego pytanie o bezpieczeństwo w zestawieniu ze złożonością ma większe znaczenie niż sama definicja. Jeśli obciążenie jest wrażliwe, ma duży wolumen i jest ściśle powiązane ze zgodnością, wykonywanie w bazie danych często staje się wyborem praktycznym, a nie tylko preferencją architektoniczną. Jeśli obciążenie ma charakter doraźny lub eksploracyjny, to samo podejście może przysporzyć więcej kłopotów, niż jest warte.

Najnowszy trend w obserwowalności zmierza w tym samym kierunku – traktuje jakość danych i obserwowalność jako jeden problem analityczny skoncentrowany na bazie danych, a nie dwa osobne zadania. Jest to przydatne, ponieważ kluczowe pytanie w przedsiębiorstwach rzadko brzmi „Czy potrafimy wykryć problem?”. Brzmi raczej: „Czy potrafimy go wykryć, nie psując systemu, który próbujemy chronić?”.

Podejmowanie decyzji: czy przetwarzanie w bazie danych pasuje do Twojego stosu

Zacznij od danych, a nie od narzędzia. Jeśli zbiór danych jest zbyt wrażliwy, by opuścić środowisko, zbyt duży, by efektywnie go przenosić, lub zbyt bliski źródłu prawdy, by tolerować opóźnienia, przetwarzanie w bazie danych zasługuje na poważne rozważenie.

Następnie sprawdź obciążenie. Wykrywanie anomalii w czasie rzeczywistym, kontrole aktualności, monitorowanie dryfu schematu i walidacja reguł biznesowych zyskują, gdy działają blisko źródła danych. Jeśli te same kontrole są uruchamiane tylko od czasu do czasu albo mają charakter eksploracyjny, a nie operacyjny, prostota zewnętrznego silnika może wystarczyć.

Następnie przetestuj sam silnik. Czy obsługuje potrzebne funkcje analityczne? Czy potrafi sprawnie realizować pushdown? Czy poradzi sobie z obserwowalnością, nie pozbawiając zasobów zapytań produkcyjnych? Te pytania są ważniejsze niż etykieta marketingowa, ponieważ baza danych, która nie potrafi dobrze planować, ukarze Cię szybciej niż powolne zadanie zewnętrzne.

Krótka lista kontrolna do podjęcia decyzji

• Wybierz przetwarzanie w bazie danych, gdy dane podlegają regulacjom, wolumen jest duży lub liczą się opóźnienia.

• Preferuj analizę zewnętrzną, gdy obciążenie jest lekkie, tymczasowe lub wciąż zmienia swój charakter.

• Zweryfikuj zachowanie silnika przed wdrożeniem, zwłaszcza plany zapytań, indeksowanie i izolację obciążeń.

• Zachowaj istniejące narzędzia BI tam, gdzie już się sprawdzają, ponieważ wykonywanie w bazie danych nie wymaga rezygnacji z reszty stosu.

Największym nieporozumieniem jest przekonanie, że wykonywanie w bazie danych zastępuje wszystko inne. Tak nie jest. Zmienia ono miejsce, w którym odbywają się kontrole, a nie to, czy nadal istnieją analitycy, pulpity lub aplikacje w dalszych etapach. W praktyce najlepsze wdrożenia utrzymują hurtownię jako źródło prawdy, wykorzystują silnik bazy danych do inspekcji wymagających silnego ładu danych i unikają przebudowy całego stosu analitycznego tylko po to, by rozwiązać problem z aktualnością.

Jeśli Twoja obecna konfiguracja poświęca więcej czasu na kopiowanie danych niż na ich sprawdzanie, architektura prawdopodobnie działa przeciwko Tobie. Jeśli szukasz platformy, która oblicza metryki jakości i obserwowalności w środowisku klienta, pozostawia dane na miejscu i obsługuje modułowe monitorowanie anomalii, terminowości, walidacji, zmian schematu i metryk biznesowych, odwiedź digna i sprawdź, jak model przetwarzania w bazie danych pasuje do Twojej hurtowni i wymagań w zakresie ładu danych.

Ponieważ kompatybilność silnika decyduje o tym, czy kontrole mogą pozostać w bazie danych, lista baz danych i hurtowni, z którymi integruje się digna, to pierwsza rzecz, którą warto sprawdzić dla swojego stosu.

Najczęściej zadawane pytania

Czym jest przetwarzanie w bazie danych?

Przetwarzanie w bazie danych uruchamia analitykę i monitorowanie bezpośrednio w silniku bazy danych, dzięki czemu dane pozostają na miejscu, zamiast być wyodrębniane do zewnętrznego narzędzia. Eliminuje to narzut transferu, pozwala uniknąć dodatkowych kopii i ogranicza powierzchnię ataku, co ma największe znaczenie, gdy hurtownia jest duża, wrażliwa lub jedno i drugie.

Kiedy przetwarzanie w bazie danych weszło do głównego nurtu?

Analityka w bazie danych zyskała znaczenie komercyjne w połowie lat 90., a szeroką popularność w połowie pierwszej dekady XXI wieku. Często przywoływanym kamieniem milowym jest konferencja Teradata Partners we wrześniu 2005 roku, na której zaprezentowano połączenie SAS i Teradata wewnątrz hurtowni, a kolumnowe bazy danych uczyniły skanowanie i agregację po stronie hurtowni praktycznymi.

Czym różni się przetwarzanie w bazie danych od procesów typu ekstrakcja–analiza?

Przetwarzanie w bazie danych wykonuje obliczenia tam, gdzie znajdują się dane, natomiast procesy typu ekstrakcja–analiza najpierw kopiują lub eksportują dane do innego silnika. Pierwsze podejście sprawdza się przy dużych, wrażliwych lub wrażliwych na opóźnienia obciążeniach, ale może przeciążyć środowisko produkcyjne; drugie pasuje do lekkich lub doraźnych analiz, ale może odbiegać od źródła i tworzyć zduplikowane wersje prawdy.

Kiedy przetwarzanie w bazie danych nie jest właściwym wyborem?

Artykuł wskazuje trzy takie sytuacje: luki w kompatybilności, gdy baza danych nie ma potrzebnych funkcji analitycznych lub mechanizmu pushdown, rywalizację o zasoby, gdy zadania obserwowalności spowalniają zapytania BI, oraz przesadny zakres, gdy lekka, krótkotrwała lub niskiego ryzyka analiza nie uzasadnia kosztów konfiguracji w silniku.

Jak digna wykorzystuje przetwarzanie w bazie danych do obserwowalności danych?

digna utrzymuje obliczanie metryk we własnych bazach danych klienta i tam monitoruje aktualność, wolumen, schemat, rozkład i pochodzenie danych. Kontrole dryfu schematu porównują przychodzącą strukturę z oczekiwaną linią bazową i klasyfikują dodania, usunięcia, zmiany nazw i zmiany typów według ważności, a wykrywanie anomalii uczy się zachowania zbioru danych bez ręcznych reguł.