Jedes Tool für Datenqualität enthält eine architektonische Entscheidung: Wo findet die Prüfung statt? Wenn Sie Daten aus der Datenbank herausbewegen, um Qualitätsprüfungen extern auszuführen, führen Sie Netzwerklatenz, eine zusätzliche Verarbeitungsschicht, Egress-Kosten und eine zuvor nicht vorhandene Sicherheitsfläche ein. 

Mit wachsendem Datenvolumen verstärkt sich diese Entscheidung. Eine Million Datensätze täglich zu extrahieren, um sie extern zu validieren, ist machbar. Hundert Millionen Datensätze aus einer Snowflake-Umgebung mit Anforderungen an die Datenresidenz, aus einem Teradata-System in einer regulierten Institution, aus einer Databricks-Umgebung zu extrahieren, die Echtzeit-Ereignisdaten verarbeitet, ist eine andere Sache. Extraktionskosten, Latenz und Compliance-Risiko skalieren alle mit dem Datenvolumen. Die Qualitätsprüfung selbst muss das nicht. 

Die Ausführung von Datenqualität in der Datenbank führt die gesamte Qualitätslogik innerhalb der Datenbank-Engine aus, wo die Daten bereits liegen, und vermeidet damit alle diese Kosten. Dieser Artikel erklärt, was das in der Praxis bedeutet und wann die Entscheidung am wichtigsten ist. 

Was ist die Ausführung von Datenqualität in der Datenbank? 

Die Ausführung von Datenqualität in der Datenbank bedeutet, dass Qualitätsprüfungen, Anomalieerkennung, Schemaüberwachung und Validierungslogik als SQL-basierte Prüfungen innerhalb der Quell-Datenbank-Engine ausgeführt werden. Die Quality-Plattform verbindet sich, sendet Prüf-Abfragen, bewertet die resultierenden Metriken und schreibt Qualitätskennzeichnungen zurück in ihr eigenes Schema. Keine Datensätze verlassen die Datenbank. 

Der Unterschied zu externen Pipeline-Architekturen ist architektonischer Natur, nicht kosmetischer. Eine externe Pipeline extrahiert Daten aus der Quelle, verschiebt sie in eine separate Umgebung, in der die Qualitätsprüfungen laufen, und verwirft oder speichert anschließend die Kopie. Die Qualitätslogik arbeitet mit der Kopie. Die Quelle entwickelt sich weiter, während die Kopie altert. Die Ausführung in der Datenbank beseitigt diese Spannung vollständig. 

Die Verschiebung von ETL zu ELT spiegelt genau diese Erkenntnis wider. Laut der Forschung zu Datenpipelines in ScienceDirect-Dokumenten löste das ELT-Muster ETL ab, weil die Ausführung von Transformationslogik innerhalb des Warehouses, wo Rechenleistung und Daten bereits vorhanden sind, schneller und architektonisch sauberer ist. Dieselbe Logik gilt für Datenqualität: Warum Daten extrahieren, um sie zu prüfen, wenn die Datenbank-Engine bereits alles hat, was für die Prüfung nötig ist? 

Die Grenzen externer Data-Quality-Pipelines, die die Ausführung in der Datenbank vermeidet 

Externe Data-Quality-Pipelines bringen vier strukturelle Einschränkungen mit sich, die In-Database-Architekturen vermeiden. 

• Latenz und Veralterung: Qualitätsprüfungen laufen gegen extrahierte Kopien. Bis die Prüfung abgeschlossen ist, können sich die Quelldaten bereits geändert haben. In Umgebungen mit häufigen Aktualisierungen oder Streaming-Ingestion arbeiten externe Pipelines immer gegen einen Snapshot, der bereits hinter dem aktuellen Stand liegt. 

  
  

• Sicherheitsrisiko und Compliance-Risiko: Jede Datenbewegung ist eine Angriffsfläche. Das Extrahieren von Datensätzen erfordert Netzwerktransit, Zugangsdaten an beiden Enden und eine sekundäre Speicherschicht, die abgesichert und geprüft werden muss. Für Organisationen unter GDPR, HIPAA, BCBS 239 oder Vorschriften zur Datenresidenz kann die Extraktion selbst eine ausdrückliche Begründung erfordern. Die Ausführung in der Datenbank vermeidet dies, weil keine Daten eine Systemgrenze überschreiten. 

  
  

• Operativer Aufwand und Wartungskosten: Externe Pipelines erfordern eine Infrastruktur, um Daten getrennt von der Quelle zu extrahieren, zu transportieren und zu verarbeiten. Sie erfordern Orchestrierung, Monitoring, Kapazitätsmanagement und Fehlerbehandlung für die Extraktionspipeline selbst, unabhängig von der Logik der Qualitätsprüfung. Laut DQOps in ihrer Analyse der Data-Quality-Architektur verursachen beide Ansätze Wartungskosten, die mit der Zahl der Prüfungen wachsen, und koppeln die Qualitätslogik an die Ausführungszyklen der Pipeline. 

  
  

• Skalierungskosten bei Volumen: In Cloud-Data-Warehouse-Umgebungen wie Snowflake, Databricks oder Azure Synapse verursacht Daten-Egress direkte finanzielle Kosten. Bei Unternehmensdatenvolumen summieren sich diese Kosten. Die Ausführung in der Datenbank nutzt die bereits der Datenbank zugewiesene Rechenleistung, ohne Egress. 

Leistungs- und Sicherheitsvorteile von In-Database Data Quality in Snowflake und modernen Warehouses 

Moderne Cloud-Data-Warehouses sind für SQL-Ausführung im großen Maßstab mit nativer Parallelverarbeitung, spaltenorientierter Speicherung und Abfrageoptimierung ausgelegt. Wenn Datenqualität-Prüfungen als SQL-Inspektionen innerhalb dieser Engines laufen, profitieren sie von denselben architektonischen Vorteilen: Parallelität, Query-Pruning und native Ausführung gegen das Speicherformat, in dem die Daten bereits liegen. 

Der Leistungsvorteil ist nicht marginal. Eine Vollständigkeitsprüfung für eine Tabelle mit einer Milliarde Zeilen, die als SQL innerhalb von Snowflake ausgeführt wird, arbeitet gegen komprimierten spaltenorientierten Speicher mit Micro-Partition-Pruning. Dieselbe Prüfung in einer externen Python-Umgebung verarbeitet dekomprimierte Datensätze sequenziell, ohne native Warehouse-Optimierungen. 

Der Sicherheitsvorteil ist kategorial. Forschung aus dem Journal of Big Data identifiziert Datenbewegungen zwischen Umgebungen als primäres governance-Risiko und weist darauf hin, dass Richtlinien, die verlangen, dass die gesamte Verarbeitung in einer kontrollierten Umgebung verbleibt, mit dem EU AI Act und GDPR übereinstimmen. Die Ausführung in der Datenbank erfüllt diese Anforderungen, weil Daten niemals die Umgebung verlassen, die diese Vorschriften regeln. 

Speziell für Snowflake laufen alle Metrikberechnungen, Anomalieerkennung, Validierung und Schemaüberwachung innerhalb der Snowflake-Umgebung als natives SQL. Die digna-Plattforminstanz befindet sich in der eigenen Infrastruktur des Kunden. Nur aggregierte Metrikergebnisse, nicht Daten auf Datensatzebene, werden an das Observability-Schema von digna zurückgegeben. 

Wie In-Database Data Quality in modernen Data-Warehouse-Umgebungen funktioniert 

Die Quality-Plattform verbindet sich über einen Standard-Connector mit der Datenbank, führt SQL-basierte Prüf-Abfragen gegen konfigurierte Tabellen und Views aus, empfängt die resultierenden Metrikwerte, vergleicht sie mit erlernten Baselines oder definierten Schwellenwerten und schreibt den Qualitätsstatus in ihr eigenes Schema innerhalb derselben Umgebung. 

Dieses Modell entkoppelt Qualitätsüberwachung vollständig von Datenbewegungen. Die Pipeline, die Daten in das Warehouse lädt, läuft unabhängig von der Qualitätsprüfung. Die Prüfung liest aus Tabellen, die die Pipeline bereits befüllt hat, ohne den Datenfluss abzufangen oder zu verändern oder Änderungen daran zu erfordern, wie Daten geladen werden. 

digna implementiert dies über Snowflake, Databricks, Teradata, PostgreSQL, Oracle, MS SQL Server und Azure Synapse: digna Data Anomalies lernt Verhaltens-Baselines aus Metrikberechnungen in der Datenbank. digna Data Validation setzt Geschäftsregeln über SQL-basierte Prüfungen auf Datensatzebene durch. digna Schema Tracker überwacht strukturelle Änderungen, indem es Datenbankmetadaten direkt abfragt. digna Timeliness überwacht Datenankunftszeitstempel innerhalb der Datenbank. digna Data Analytics berechnet Trendmetriken aus in-database-Observability-Daten. Keines davon erfordert, dass Daten die Datenbank-Engine verlassen. 

Wann man In-Database Data Quality externen Pipeline-Ansätzen vorziehen sollte 

Der Fall für die Ausführung in der Datenbank ist in vier Kontexten am stärksten, die die Mehrheit der Unternehmensdatenumgebungen beschreiben. 

• Regulierte Branchen mit Anforderungen an Datenresidenz oder Sensibilität: Finanzinstitute, Gesundheitsorganisationen und Unternehmen unter GDPR, HIPAA oder Datenhoheitsvorschriften stehen vor dokumentierten Pflichten hinsichtlich der Orte, an denen Daten verarbeitet werden dürfen. Die Ausführung in der Datenbank hält das Monitoring der Datenqualität per Design innerhalb der kontrollierten Umgebung, ohne Extraktion und ohne externen Zugriff, den man einem Prüfer erklären müsste. 

  
  

• Umgebungen mit hohem Volumen, in denen Extraktionskosten nicht trivial sind: Bei Unternehmensdatenvolumen skalieren Egress-Kosten in Cloud-Warehouses, Bandbreitenverbrauch und externes Verarbeitungs-Compute allesamt mit der Datenmenge. Die Ausführung in der Datenbank skaliert mit der eigenen Rechenleistung des Warehouses, die bereits bereitgestellt ist. 

  
  

• Umgebungen, in denen Erkennungs-Latenz wichtig ist: Eine Analyse aus dem Jahr 2024 von über 1.000 Datenpipelines durch Datachecks ergab, dass 72 % der Data-Quality-Probleme erst entdeckt werden, nachdem sie Geschäftsentscheidungen beeinflusst haben. Prüfungen in der Datenbank laufen gegen den aktuellsten Warehouse-Zustand, nicht gegen eine extrahierte Kopie, die Stunden alt sein kann. 

  
  

• Teams, die Qualitätsmonitoring ohne Pipeline-Änderungen benötigen: Qualitätsmonitoring in der Datenbank erfordert keine Änderungen daran, wie Daten geladen werden oder wie bestehende Pipelines strukturiert sind. Es wird als Beobachtungsschicht auf bestehende Tabellen aufgesetzt und eliminiert die Kopplung zwischen Qualitätsmonitoring und Pipeline-Entwicklungszyklen. 

Abschließender Gedanke: Die Architektur der Qualität sollte zur Architektur der Daten passen 

Der Branchenwechsel hin zu ELT war eine Anerkennung dafür, dass die Rechenleistung für Transformation bereits im Warehouse existiert und dass das Extrahieren von Daten, um sie anderswo zu transformieren, eine architektonische Gewohnheit war, die der modernen Cloud-Infrastruktur vorausging. Dieselbe Erkenntnis gilt für Datenqualität. Die für die Prüfung benötigte Rechenleistung existiert bereits in der Datenbank. Daten herauszubewegen, um sie extern zu prüfen, führt Kosten, Latenz und Risiken ein, die das Architekturmodell nicht erfordert. 

Eine von Acceldata zitierte Forrester-Studie ergab, dass 30 % der Führungskräfte angaben, aufgrund von Datenungenauigkeiten Kunden verloren zu haben. Die Organisationen, die Ungenauigkeiten am frühesten erkennen, sind jene mit Qualitätsmonitoring, das am nächsten an den Daten liegt. Die Ausführung in der Datenbank macht diese Nähe systematisch. 

Qualitätsprüfungen sollten dort ausgeführt werden, wo die Daten leben.

Sieh dir In-Database Data Quality in deiner eigenen Umgebung an. 

digna führt alle Qualitätsprüfungen, Anomalieerkennung, Schemaüberwachung und Validierung innerhalb deiner Datenbank-Engine aus. Keine Daten verlassen deine Umgebung. Keine externe Pipeline erforderlich. Fünf Module, die alle in der Datenbank über Snowflake, Databricks, Teradata, PostgreSQL und mehr ausgeführt werden. 

Persönliche Demo buchen Die Plattformarchitektur erkunden