Was ist Datenherkunft? Definition, Beispiele und Funktionsweise

Was ist Datenherkunft?? Datenherkunft Es handelt sich um den dokumentierten Pfad, den Daten von ihren ursprünglichen Quellen zu ihren endgültigen Zielen zurücklegen, einschließlich jeder Tabelle, Ansicht, jedes Jobs und jeder Transformation, die sie auf diesem Weg durchlaufen. Er beantwortet zwei Fragen, die sich jedes Datenteam stellt: „Woher stammt dieser Wert?“ (Herkunft) und „Was hängt nachfolgend davon ab?“ (Auswirkungsanalyse). In SQL-basierten Systemen wird die Datenherkunft üblicherweise automatisch durch Parsen des SQL-Codes extrahiert, der die Daten verschiebt und umformt.

Diese Seite bietet Anwendern eine praktische Definition: Was die Datenherkunft tatsächlich erfasst, der Unterschied zwischen Tabellen- und Spaltenebene, direkte versus indirekte Beziehungen, die drei Methoden zum Aufbau der Datenherkunft und wer sie wirklich benötigt. Die Beispiele verwenden SQL, da die Transformationslogik in den meisten Data Warehouses in SQL implementiert ist.

Die beiden Fragen, die die Abstammung beantwortet: Herkunfts- und Wirkungsanalyse

Die Datenherkunftsgrafik ist ein Diagramm, das in zwei Richtungen gelesen werden kann. Lesen Sie es. stromaufwärts So erhalten Sie die Herkunftsnachweise: Ausgehend von einer Zahl in einem Bericht verfolgen Sie rückwärts alle Ansichten, Verknüpfungen und Berechnungen bis zu den ursprünglichen Quellspalten. Genau diese Richtung ist für Prüfer, Aufsichtsbehörden und alle, die einen fehlerhaften Wert finden, von Bedeutung.

Lies es stromabwärts Und so erhalten Sie eine Auswirkungsanalyse: Ausgehend von einer Spalte, die Sie umbenennen, umschreiben oder löschen möchten, werden alle Tabellen, Sichten, Prozeduren und Berichte aufgelistet, die betroffen wären. Genau diese Vorgehensweise ist für Entwickler vor einer Schemaänderung oder Migration entscheidend, denn die Alternative wäre, Tausende von Skripten zu durchsuchen und auf das Richtige zu hoffen.

Die Begriffe werden manchmal etwas ungenau verwendet. Streng genommen… Herkunft ist die Rückwärtsverfolgung, Wirkungsanalyse ist die Vorwärtsverfolgung, und Datenherkunft ist der zugrunde liegende Abhängigkeitsgraph, der beide Traversierungen ermöglicht.

Ein konkretes Beispiel

Betrachten wir eine routinemäßige Lagerabrechnung:

INSERT INTO monthly_revenue (month, total) SELECT DATE_TRUNC('month', o.order_date) AS month, SUM(o.amount) AS total FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.region = 'EMEA' GROUP BY DATE_TRUNC('month', o.order_date);

Die aus dieser einen Aussage abgeleitete Abstammungslinie weist bereits zwei unterschiedliche Arten von Beziehungen auf:

• Direkte Abstammung — Daten fließen tatsächlich in die Ausgabe: orders.order_date Futter monatlicher_Umsatz.Monat durch DATE_TRUNC, Und Bestellungen.Betrag Futter monatlicher Gesamtumsatz durch SUMME.
• Indirekte Abstammung — Spalten, die nie in der Ausgabe landen, sie aber prägen: Kundenregion filtert die Zeilen und orders.customer_id verbunden mit Kunden-ID entscheidet, welche Zeilen überhaupt übereinstimmen. Ändern Sie, wie Region ist bevölkert und jede Zahl in monatlicher Umsatz Veränderungen, auch wenn Region Erscheint nirgends im Ergebnis.

Eine reale Pipeline besteht aus Tausenden solcher Anweisungen, die über Views, gespeicherte Prozeduren und DBT-Modelle verschachtelt sind. Lineage-Tools existieren, weil kein Mensch diesen Graphen im Kopf behalten kann. Weitere Anwendungsbeispiele, einschließlich der Lineage von Multi-Hop-Pipelines und gespeicherten Prozeduren, finden Sie in unserer [Link zu den Anwendungsbeispielen]. Beispiele für Datenherkunft Schritt-für-Schritt-Anleitung.

Herkunft auf Tabellen- vs. Spaltenebene

Die Daten zur Abstammung gibt es in zwei Granularitäten, und der Unterschied bestimmt, was man damit tatsächlich anfangen kann.

	Abstammung auf Tabellenebene	Spaltenebene Herkunft
Was es aufzeichnet	monatlicher Umsatz wird gebaut aus Bestellungen Und Kunden	monatlicher Gesamtumsatz = SUMME(orders.amount)gefiltert nach Kundenregion, beigetreten am Kunden-ID = ID
Wirkungsanalyse	Ungefähr: Markiert alle Benutzer der Tabelle, einschließlich derjenigen, die von der geänderten Spalte nie berührt werden.	Präzise: Markiert nur die Konsumenten, die tatsächlich von der Spalte beliefert werden.
Antworten der Prüfstelle	„Dieser Bericht verwendet diese Tabellen.“	„Diese Zahl wird genau aus diesen Quellfeldern mittels dieser Transformationen berechnet.“
Typische Quelle	Metadaten des Job-Orchestrators, Abfrageprotokolle	Das Parsen des SQL-Codes selbst

Die Erfassung der Datenherkunft auf Tabellenebene ist kostengünstig und für eine erste Darstellung einer Datenpipeline nützlich. Die meisten eigentlichen Fragen betreffen jedoch die Spalten: Welche Berichte verwenden die Datenherkunft? E-MailDie Quellfelder, die diese regulierte Kennzahl speisen, sind alle nachgelagerten Operationen, die die zu entfernende Spalte lesen. Dies erfordert die Auflösung jeder Ausgabespalte mithilfe von Joins, Unterabfragen, CTEs, Sichten und … WÄHLEN * Erweiterung: Parserarbeit, nicht Log-Scraping. Die Mechanismen werden in unserem Leitfaden ausführlich beschrieben. Datenherkunft auf Spaltenebene.

Wozu dient die Datenherkunftsanalyse?

In der Praxis werden nahezu alle Abstammungsübernahmen auf vier Anwendungsfälle zurückgeführt:

• Einhaltung gesetzlicher Bestimmungen. BCBS 239 erwartet von Banken, dass sie darlegen, wie Risikokennzahlen aus Quelldaten aggregiert werden; die DSGVO-Datenmapping-Pflichten erfordern, dass bekannt ist, in welche Systeme und abgeleiteten Tabellen personenbezogene Daten fließen. Die Herkunftsnachweise auf Spaltenebene erfüllen beide Anforderungen: „Diese exakten Quellfelder, durch diese Transformationen“.
• Daten-Governance. Kataloge und Glossare veralten, wenn die Herkunftsinformationen manuell gepflegt werden. Automatisch extrahierte Herkunftsinformationen halten die Abhängigkeitsübersicht bei Codeänderungen aktuell und können direkt in Katalogplattformen eingespeist werden; SQLFlow beispielsweise liefert Exportadapter für DataHub, Microsoft Purview und OpenMetadata.
• Fehlersuche und Ursachenanalyse. Wenn ein Dashboard eine falsche Zahl anzeigt, wandelt die Ablaufverfolgung „Durchsuchen Sie jedes Skript, das diese Tabelle erwähnt“ in „Gehen Sie von dieser einen Spalte aus rückwärts“ um. Stunden statt Tage.
• Migration und Modernisierung. Bevor Sie von Oracle oder Teradata zu Snowflake, BigQuery oder Databricks wechseln, zeigt Ihnen der Abhängigkeitsgraph, was zusammen und in welcher Reihenfolge migriert werden muss und welche Objekte nicht mehr gelesen werden und daher gelöscht statt migriert werden können.

Eine nützliche Faustregel: Wenn Ihr Team jemals eine Schemaänderung verzögert hat, weil niemand sicher war, was dadurch kaputtgehen würde, benötigen Sie bereits eine Datenherkunftsanalyse – Sie berechnen sie nur manuell, langsam und mit Fehlern.

Häufig gestellte Fragen

Was versteht man unter Datenherkunft in einfachen Worten?

Es ist die Landkarte, die den Ursprung und den Weg Ihrer Daten aufzeigt: welche Quellen die einzelnen Tabellen oder Berichte speisen und welche Transformationen dazwischen stattfinden. Man kann es sich als Abhängigkeitsdiagramm für Daten vorstellen, das sowohl rückwärts (Herkunft) als auch vorwärts (Auswirkungsanalyse) durchsucht werden kann.

Worin besteht der Unterschied zwischen Datenherkunft und Datenprovenienz?

Provenienz bezeichnet die Rückverfolgung von einem Ergebnis zu seinem Ursprung. Lineage hingegen ist der gesamte Abhängigkeitsgraph, der Provenienz in der einen Richtung und Wirkungsanalyse in der anderen Richtung ermöglicht. Im allgemeinen Sprachgebrauch überschneiden sich die Begriffe, die Unterscheidung zwischen Graph und Traversierung ist jedoch präzise.

Was versteht man unter indirekter Datenherkunft?

Indirekte Abstammung umfasst Spalten, die ein Ergebnis beeinflussen, ohne darin aufzutreten – Spalten, die verwendet werden in WO Filter, VERBINDEN Bedingungen und GRUPPE NACH Klauseln. Sie verändern jeden Ausgabewert, daher ist eine Wirkungsanalyse, die sie ignoriert, unvollständig. SQLFlow modelliert die indirekte Herkunft als separaten, umschaltbaren Beziehungstyp; die meisten Herkunftsanalyse-Tools treffen diese Unterscheidung nicht.

Ist die Datenherkunft für die Einhaltung der DSGVO oder des BCBS 239 erforderlich?

Keines der beiden Rahmenwerke nennt „Datenherkunft“ als obligatorische Technologie, doch beide setzen voraus, was Datenherkunft liefert: BCBS 239 verlangt von Banken, nachzuweisen, wie Risikodaten aus ihren Quellen aggregiert werden, und die DSGVO-Datenzuordnung erfordert die Kenntnis der Datenflüsse personenbezogener Daten. Die Datenherkunft auf Spaltenebene ist der Standard, um diese Nachweise in großem Umfang zu erbringen.

Wie erstellt man automatisch Datenherkunft?

Übergeben Sie Ihren SQL-Code an ein Tool zur statischen Datenherkunftsanalyse. Mit SQLFlow können Sie SQL-Code einfügen, Dateien hochladen, eine Datenbankverbindung über JDBC herstellen, ein dbt-Manifest importieren oder Snowflake-Abfrageverlauf bzw. Redshift-Abfrageprotokolle einlesen. Das Tool analysiert den Code und erstellt interaktive Diagramme auf Spaltenebene sowie JSON/CSV-Exporte und eine REST-API. In Unternehmensumgebungen werden Datenbanken mit über 100 Datenbanken und mehr als einer Million Spalten im Batch-Verfahren analysiert.

Benötigt die Erstellung der Datenherkunft Zugriff auf meine tatsächlichen Daten?

Nicht mit statischer Analyse. Das Parsen von SQL erfordert den Code und optional Schema-Metadaten (Tabellen- und Spaltendefinitionen) – niemals die Zeilen Ihrer Tabellen. Die On-Premise-Edition von SQLFlow speichert den SQL-Text zudem innerhalb Ihres Netzwerks, weshalb sie sich für Banken und andere regulierte Umgebungen eignet.