Die digna Engine: Wählen Sie, wo Ihre Daten profiliert werden
|
4
min. Lesezeit
Von Anfang an hat digna Daten dort profiliert, wo sie liegen: Die Prüfungen laufen in Ihrer eigenen Datenbank, und digna arbeitet mit den Ergebnissen statt mit Kopien Ihrer Tabellen. Für die meisten Verbindungen ist das nach wie vor die richtige Lösung, und deshalb bleibt es die Standardeinstellung.
Nicht jedes Quellsystem ist jedoch ein guter Ort für diese Arbeit, und nicht jede Frage lässt sich innerhalb einer einzigen Datenbank beantworten. Release 2026.11 adressiert beides: mit der digna Engine, einem zweiten Ort, an dem das Profiling laufen kann, und mit einer Prüfung der referenziellen Integrität über zwei Verbindungen hinweg, selbst wenn diese auf zwei unterschiedliche Datenbanktechnologien zeigen. Das einminütige Video zeigt beides.
Eine Einstellung pro Datenbankverbindung
Jede Datenbankverbindung in digna hat jetzt einen Profiling-Ort mit zwei Werten. Source Database ist der Standard und verhält sich wie bisher: Das Profiling läuft in der Datenbank, auf die die Verbindung zeigt. digna Engine verlagert diese Arbeit in die Engine, sodass das Quellsystem die Daten liefert und die Engine das Profiling übernimmt. Die Einstellung ist für jede von digna unterstützte Quelltechnologie verfügbar, und da sie zur Verbindung gehört, entscheiden Sie einmal pro System statt Tabelle für Tabelle.
Wann das Profiling in der Quelldatenbank bleiben sollte
Laufen die Prüfungen in der Quelle, bleiben die Daten in dem System, dem sie gehören. Das hält das Setup einfach und passt zu Richtlinien, die genau das verlangen. Analytische Data Warehouses sind zudem für diese Art von Arbeit gebaut und aggregieren große Tabellen nah an ihrem Speicherort. Auf einer Plattform mit Reserven ist das Profiling vor Ort daher oft die naheliegendste Wahl: die gesamte Arbeit in einem System und ein Ort, an dem Sie nachsehen, was wann gelaufen ist.
Wann das Profiling in der digna Engine laufen sollte
Anders sieht es aus, wenn die Quelle stark ausgelastet ist. Eine operative Datenbank, die den ganzen Tag Anwendungen bedient, ein Warehouse, das im nächtlichen Batch-Fenster nahe an seinen Grenzen läuft, oder eine Plattform, auf der jede Abfrage mit geschäftlichen Workloads konkurriert: In all diesen Systemen möchte ein Team, dass das Monitoring so wenig Last wie möglich erzeugt. Wird eine solche Verbindung auf die digna Engine umgestellt, bleibt die Profiling-Arbeit von der Quelle fern.
Welche Option schonender ist, hängt von Tabellengrößen, Netzwerk und der Auslastung der jeweiligen Quelle ab. Deshalb gilt die Einstellung pro Verbindung: Sie können im selben digna Projekt auf dem Warehouse mit freien Kapazitäten vor Ort profilieren und für das Produktivsystem ohne Reserven die Engine nutzen.
Referenzielle Integrität über Verbindungen und Technologien hinweg
In digna Data Validation bestätigt eine Prüfung der referenziellen Integrität, dass jeder Schlüssel in einem Dataset einen passenden Datensatz in dem Dataset hat, auf das er verweist. Innerhalb einer Datenbank ist das ein einfacher Vergleich, doch Datenlandschaften liegen heute selten in einer einzigen Datenbank. Ein Kundenstamm liegt vielleicht in Oracle, während die darauf verweisenden Bestellungen in PostgreSQL landen, oder ein Warehouse zieht Fachbereich für Fachbereich von Teradata zu Snowflake um, sodass Eltern- und Kindtabellen auf verschiedenen Plattformen liegen.
Mit Release 2026.11 lassen sich diese Beziehungen direkt prüfen, zwischen Datenquellen auf unterschiedlichen Verbindungen und Technologien: Teradata und Snowflake, Oracle und PostgreSQL, Databricks und SQL Server oder zwei beliebige andere von digna unterstützte Technologien. Die Prüfung funktioniert mit beiden Profiling-Orten, und wenn eine Verbindung in der Quelldatenbank profiliert, werden für den Vergleich nur die Schlüsselspalten an die Engine exportiert. Im Dashboard sehen Sie, wenn eine Prüfung über zwei Verbindungen läuft, sodass jeder, der das Ergebnis liest, weiß, dass es zwei Systeme umfasst.
Ihre Infrastruktur, egal welchen Ort Sie wählen
Beide Profiling-Orte laufen auf Ihrer eigenen Infrastruktur, on-premises oder in Ihrer Private Cloud, und die digna Engine läuft dort neben dem Rest von digna. Mit dieser Wahl ändern Sie, wo das Profiling innerhalb Ihrer Umgebung stattfindet, nicht, ob Ihre Daten sie verlassen.
Die Profiling-Dokumentation erklärt den Profiling-Ort im Detail, und die Data-Validation-Dokumentation behandelt Prüfungen der referenziellen Integrität und die übrigen Regeltypen.
Die digna Engine ist Teil von Release 2026.11, mit dem auch digna Agentic und das Modul digna Data Reconciliation eingeführt wurden; der Release-Überblick stellt alle drei vor.
Buchen Sie eine Demo, um beide Profiling-Orte und eine technologieübergreifende Prüfung der referenziellen Integrität auf Ihren eigenen Verbindungen zu sehen.
Häufig gestellte Fragen
Was ist der Profiling-Ort einer Datenbankverbindung?
Eine Einstellung an jeder Datenbankverbindung, die festlegt, wo das Profiling läuft: Source Database, der Standard, führt die Prüfungen in der Datenbank selbst aus, und digna Engine führt das Profiling in der digna Engine aus. Sie ist für jede von digna unterstützte Quelltechnologie verfügbar.
Welchen Profiling-Ort sollten wir wählen?
Das hängt von der Quelle ab. Profiling in der Quelldatenbank hält die gesamte Arbeit an einem Ort, was zu Plattformen mit freien Kapazitäten passt, während die digna Engine eine stark ausgelastete Quelle entlastet. Da die Einstellung pro Verbindung gilt, können Sie für jedes System anders entscheiden.
Kann digna die referenzielle Integrität zwischen Teradata und Snowflake prüfen?
Ja. digna Data Validation prüft die referenzielle Integrität zwischen Datenquellen auf unterschiedlichen Verbindungen und Technologien, etwa Teradata und Snowflake, Oracle und PostgreSQL oder Databricks und SQL Server, mit beiden Profiling-Orten.
Verlassen unsere Daten unsere Infrastruktur, wenn wir die digna Engine nutzen?
Nein. Die digna Engine läuft wie der Rest von digna auf Ihrer eigenen Infrastruktur, on-premises oder in Ihrer Private Cloud.
