Data Lineage ist die dokumentierte Herkunft von Daten: Sie zeigt den Weg jedes Werts von der Quelle (dem System, in dem er entsteht, z. B. ein CRM oder eine Kasse) über die Verarbeitungsschritte (Berechnungen, Zusammenführungen, Filter) bis zu seiner Nutzung in einem Report, einem KI-Modell oder einem Datenprodukt (einem gepflegten Datensatz, den andere Teams einbinden). Sie beantwortet zwei Grundfragen: Woher stammt der Wert in einem konkreten Feld, und was passiert weiter unten in der Kette, wenn sich eine Quelle ändert?
Was ist Data Lineage?
Data Lineage macht die Beziehungen zwischen Datenobjekten sichtbar, also zwischen Tabellen, Spalten und den Auswertungen darauf. Für jede Auswertung lässt sich zurückverfolgen, aus welchen Ursprungs-Tabellen und -Spalten sie entsteht, welche Verarbeitungsschritte dazwischenliegen und in welchen Reports, KI-Merkmalen (den Eingangsdaten von ML-Modellen) oder Programm-Schnittstellen (API-Endpunkten) sie weiterverwendet wird. Der Begriff hat seine Wurzeln in den Metadaten-Werkzeugen der frühen 2000er Jahre (Metadaten sind Daten über Daten, z. B. Herkunft, Format, Owner) und wurde durch die Datenschutz-Grundverordnung (DSGVO) ab 2018 und den EU AI Act als Governance-Baustein regulatorisch verankert.
Die Erfassung geschieht auf drei Granularitäts-Ebenen. Table-Level Lineage zeigt, welche Tabellen welche anderen speisen (die einfachste Sicht, ausreichend für grobe Impact-Analyse). Column-Level Lineage folgt der einzelnen Spalte durch Transformationen hindurch und beantwortet Fragen wie „Woher kommt der Wert in revenue_eur in diesem Dashboard?"; das ist der Governance- und DSGVO-Standard. Job-Level Lineage bindet die ausführenden Artefakte an: Notebooks, Pipelines, SQL-Statements, dbt-Modelle, ML-Trainings-Runs. Erst mit Job-Lineage wird die Kette betreibbar, weil Datenflüsse an konkreten Code und konkrete Zeitpunkte gebunden sind.
Zwei Richtungen der Auswertung ergänzen sich. Upstream Lineage beantwortet die Herkunftsfrage („Was speist dieses Asset?") und dient Trust, Audit und Root-Cause-Analyse. Downstream Lineage beantwortet die Wirkungsfrage („Was hängt an diesem Asset?") und dient Impact-Analyse vor Änderungen sowie DSGVO-Löschketten. Beide Richtungen leben von denselben Metadaten, adressieren aber unterschiedliche Betriebsfragen.
Technisch entsteht Lineage durch Query-Log-Parsing (SQL-Statements, Spark-Ausführungspläne, dbt-Manifests), durch Job-Metadata-Extraktion aus Orchestratoren wie Airflow oder Databricks Workflows und durch manuelle Anreicherung im Katalog für Schritte, die sich nicht automatisch erfassen lassen. Als offener Standard hat sich [OpenLineage](https://openlineage.io/) etabliert; die meisten katalog-nativen Plattformen (Unity Catalog, Microsoft Purview, SAP Datasphere) bringen eigene Lineage-Engines mit und sprechen zusätzlich OpenLineage. Der Marktrend geht klar weg vom nachträglichen Add-on-Werkzeug hin zur katalog-nativen Lineage-Funktion, die direkt am Datenobjekt lebt.
Abgrenzung zu Data Catalog, Data Provenance und Data Observability
Data Lineage wird häufig mit benachbarten Begriffen vermischt, die entweder einen anderen Umfang haben oder eine andere Betriebsfrage adressieren.
| Begriff | Achse | Kernunterschied |
|---|---|---|
| Data Catalog | Umfang | Ein Data Catalog inventarisiert Datenassets mit Beschreibung, Ownership, Klassifikation und Suche. Lineage ist eine Metadaten-Dimension des Katalogs, die Beziehungs-Sicht zwischen den Assets. Ohne Katalog-Basis gibt es keine Objekte, an denen Lineage hängen kann. |
| Data Provenance | Reichweite | Provenance ist der breitere Begriff aus der wissenschaftlich-archivarischen Tradition (W3C PROV-Modell): die vollständige Entstehungs- und Bearbeitungshistorie inklusive Akteuren, Zeitstempeln und Kontext. Data Lineage ist die operative Ausprägung im Datenplattform-Kontext, enger gefasst auf Datenflüsse und Transformationen. |
| Data Observability | Fragestellung | Observability überwacht den laufenden Zustand von Pipelines und Assets (Freshness, Volumen, Schema-Drift, Distributions-Anomalien). Lineage liefert die Struktur der Abhängigkeiten, Observability die Signale darauf. Root-Cause-Analyse braucht beide: Observability meldet das Symptom, Lineage zeigt die Kette bis zur Ursache. |
| Impact Analysis | Verhältnis | Impact Analysis ist eine Anwendung von Downstream Lineage, keine eigene Disziplin. Lineage ist das Substrat, Impact Analysis der Use Case vor Schema-Änderungen, Migrationen oder Deprecations. |
Die zentrale Trennlinie verläuft zwischen Catalog und Lineage einerseits, Observability andererseits: Katalog und Lineage beschreiben die Struktur der Datenlandschaft (statische Sicht), Observability beschreibt das Verhalten der Datenflüsse in der Zeit (dynamische Sicht). Beide Sichten ergänzen sich, sind aber inhaltlich getrennt.
Beispiel: Impact-Analyse vor einer Schema-Änderung
Ein Fach-Team plant, in der Bronze-Tabelle sales_raw das Feld customer_id von STRING auf BIGINT umzustellen, um Join-Performance und Speicherfootprint zu verbessern. Ohne Lineage bleibt die Frage offen, wer stromabwärts an diesem Feld hängt. Die Antwort liegt oft in Kopf und Chat-Verläufen einzelner Team-Mitglieder, mit entsprechender Bruchgefahr in Produktion.
Mit Column-Level-Lineage im Katalog wird die Kette prüfbar sichtbar: Vierzehn Silber-Tabellen leiten Werte aus customer_id ab, sechs Gold-Marts aggregieren darauf, drei Power-BI-Datasets binden sie ein, zwei ML-Feature-Tables nutzen sie als Join-Key. Job-Level-Lineage zeigt zusätzlich, welche Notebooks, dbt-Modelle und Databricks-Workflows für die jeweiligen Transformationen zuständig sind, inklusive Owner. Das Fach-Team koordiniert die Änderung mit den vier betroffenen Domain-Verantwortlichen, plant ein Roll-Out-Fenster und definiert einen Rückfall-Pfad. Alternativ verwirft es die Änderung, wenn der Aufwand den Nutzen übersteigt.
Der zweite typische Einsatzfall ist die DSGVO-Löschanfrage: Ein Kunde fordert die Löschung seiner personenbezogenen Daten. Die Downstream-Lineage vom Quell-Datensatz aus zeigt, in welchen abgeleiteten Tabellen, Aggregaten, ML-Modellen und Sicherungen der Datensatz auftaucht. Ohne diese Kette bleibt die Nachweispflicht Guesswork; mit Lineage wird sie eine dokumentierte Prozess-Schleife.
Data Lineage im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
katalog-native Umsetzung mit Column-Level-Lineage, System Tables und OpenLineage-Anschluss
Unity CatalogKatalog-Layer, in dem die Lineage-Metadaten leben
Data CatalogMetadaten- und Discovery-Layer, an dem Lineage als Dimension hängt
Data GovernanceRahmen, in dem Lineage die Nachweispflicht für Herkunft und Nutzung erfüllt
Data ArchitectureGesamt-Bauplan der Datenlandschaft, in dem Lineage als Governance-Objekt verortet ist
Change Data Capturetypische Quelle für Streaming-Lineage entlang der Bronze-Schicht