Lineage

Lineage bezeichnet die Sicht auf die Herkunft und den Verarbeitungsweg von Daten: welche Quelltabelle in welche Zieltabelle floss, welcher Job die Transformation ausgeführt hat, welche Spalte woher kommt (Column-Lineage) und welche Berichte auf welchen Tabellen aufsetzen. Der Begriff ist die im Datenplattform-Alltag übliche Kurzform von Data Lineage.

Was ist Lineage?

Lineage macht die Beziehungen zwischen Datenobjekten sichtbar. Für einen konkreten Wert in einem Bericht lässt sich rückwärts folgen, aus welchen Quelltabellen und -spalten er entsteht, welche Verarbeitungsschritte dazwischenliegen und welcher Job (also welches Notebook, welche Pipeline oder welche SQL-Abfrage) den jeweiligen Schritt ausgeführt hat. Der umgekehrte Weg ist ebenso wichtig: von einer Quelle vorwärts prüfen, welche abgeleiteten Tabellen, Dashboards und Modelle daran hängen.

Drei Sichten sind im Alltag üblich. Table-Lineage zeigt, welche Tabellen welche anderen speisen, und reicht für grobe Impact-Analyse. Column-Lineage folgt der einzelnen Spalte durch Transformationen hindurch und beantwortet Fragen wie „Woher kommt der Wert in revenue_eur in diesem Bericht?"; sie ist die Grundlage für DSGVO-Nachweise und schrittweise Fehlersuche. Job-Lineage bindet die ausführenden Artefakte an: Notebooks, Pipelines, dbt-Modelle, Databricks-Workflows, inklusive Owner und Ausführungszeit. Erst mit Job-Lineage ist die Kette an konkreten Code und konkrete Zeitpunkte gebunden.

Technisch entsteht Lineage durch Query-Log-Parsing (SQL-Statements, Spark-Ausführungspläne, dbt-Manifests), durch Job-Metadata-Extraktion aus Orchestratoren 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. In Databricks erfasst [Unity Catalog](/insights/databricks/unity-catalog/) Table- und Column-Lineage automatisch aus SQL- und PySpark-Läufen und stellt sie im Katalog-UI sowie in den [System Tables](/insights/glossar/system-tables/) system.access.table_lineage und system.access.column_lineage bereit.

Abgrenzung zu Provenance, Catalog, Impact Analysis und Audit Log

Der Begriff wird häufig mit benachbarten Konzepten vermischt. Die folgende Übersicht klärt die Grenzen.

Die zentrale Trennlinie: Ein Catalog listet auf, was es gibt. Lineage zeigt, wie die Objekte zusammenhängen. Provenance dokumentiert die vollständige Historie inklusive Akteuren und rechtlicher Verwertbarkeit. Audit-Log dokumentiert Zugriffe und Aktionen. Vier Ebenen, vier Fragen, ein gemeinsamer Speicherort im Katalog.

Beispiel Fehlersuche im Dashboard

Ein Analyst öffnet ein Power-BI-Dashboard und sieht in der KPI-Kachel Umsatz Q3 einen offensichtlich falschen Wert. Ohne Lineage bleibt die Suche eine Rekonstruktion aus SQL-Skripten, Team-Chats und Erinnerung einzelner Personen, mit entsprechendem Zeitaufwand und Bruchgefahr.

Mit Column-Lineage im Katalog lässt sich vom Dashboard-Feld rückwärts durch alle Zwischen-Tabellen bis zur Bronze-Quelle folgen: das Feld stammt aus einer Silber-Tabelle, die aus einer Fivetran-Bronze-Tabelle abgeleitet wird, die ein Databricks-Workflow in der Nacht neu geladen hat. Job-Lineage zeigt zusätzlich den ausführenden Workflow und dessen Owner, so dass die Fehler-Ursache innerhalb von Minuten identifiziert und dem zuständigen Team gemeldet ist. Der zweite typische Einsatz ist die Impact-Analyse in die andere Richtung: Vor einer Schema-Änderung an einer Bronze-Spalte zeigt Downstream-Lineage sämtliche abgeleiteten Tabellen, Marts, Dashboards und ML-Feature-Tables, die daran hängen. Die Änderung wird koordiniert oder verworfen, bevor sie in Produktion Reports leerlaufen lässt.