Unity Catalog Lineage: Datenflüsse nachvollziehen und Coverage-Lücken erkennen
Die Kernaussagen auf einen Blick.
- Databricks Unity Catalog Lineage erfasst Datenflüsse zwischen Tabellen, Spalten, Notebooks, Jobs, Dashboards und MLflow-Modellen innerhalb von Databricks.
- Die Lineage ist nicht automatisch vollständig. Erfasst werden nur unterstützte Unity-Catalog-Tabellen, Compute-Konfigurationen und Verarbeitungspfade. Hive-Reste, externe Schreiber, bestimmte Streaming-Muster und direkter Storage-Zugriff können Lücken erzeugen.
- Für Audit, Impact-Analyse und AI-Governance reicht der sichtbare Lineage-Graph allein nicht aus. Entscheidend ist eine regelmäßige Coverage-Messung über system.access.table_lineage und system.access.column_lineage.
- Mein Vorschlag: Unity-Catalog-Lineage als zentrale Beobachtungsschicht für Databricks-interne Datenflüsse nutzen, Coverage pro Catalog messen, PII-Spalten gezielt bis zu ihren Konsumenten verfolgen und externe Lineage-Tools nur dort ergänzen, wo Datenflüsse über Databricks hinausgehen.
Inhaltsverzeichnis
Automatisch heißt nicht lückenlos
Drei Wochen vor dem Audit-Stichtag wird nach den Trainingsdaten eines produktiven Scoring-Modells gefragt. Es muss nachvollzogen werden, welche Trainingsdaten in ein Modell eingeflossen sind, das im vergangenen Quartal für Kreditentscheidungen genutzt wurde. Im Catalog Explorer ist der Lineage-Tab gefüllt, der Graph zeigt eine saubere Kette von der Silver-Tabelle bis zum Modell. An einer Stelle endet die nachvollziehbare Datenkette jedoch. Ein nachgelagerter Job läuft auf einem nicht für Unity Catalog konfigurierten Cluster, in Python mit einer externen Library, die direkt auf den Storage schreibt. Die nachfolgenden Verarbeitungsschritte werden deshalb nicht in der Lineage erfasst.
Eine ähnliche Situation zeigt sich in vielen gewachsenen Databricks-Plattformen. Lineage erscheint im UI, sobald Unity Catalog aktiv ist. Häufig wird jedoch nicht geprüft, welcher Anteil der tatsächlichen Verarbeitung erfasst wird. Vor der Umbenennung einer Spalte werden die bekannten Konsumenten geprüft, der Lineage-Graph zeigt drei Konsumenten. Später fällt ein BI-Bericht aus, der in der Lineage nicht als Konsument erkannt wurde. Eine personenbezogene Spalte wird in einem Trainingsdatensatz verwendet. Die ursprüngliche Quelle ist nachvollziehbar, einzelne Transformationsschritte bleiben jedoch unbekannt.
Unity-Catalog-Lineage folgt klaren Erfassungsregeln und bildet nur die unterstützten Verarbeitungspfade ab. Für einen verlässlichen Einsatz müssen Abdeckung, Einschränkungen und Verantwortlichkeiten regelmäßig geprüft werden.
Was ist Lineage in Unity Catalog?
Unity Catalog zeichnet während der Ausführung Abhängigkeiten zwischen Datenobjekten auf und verknüpft sie mit den Notebooks, Jobs und Dashboards, die den Fluss ausgelöst haben.
Dafür werden zusätzliche Metadaten wie Tags, Beschreibungen und fachliche Definitionen benötigt. Wie diese Klassifizierungs-Schicht über Tags angebunden ist, zeigen wir im Überblick zu Tags in Unity Catalog. Eine knappe technische Übersicht liefert die Databricks-Doku zu Data Lineage, die Lineage als runtime-erfasste Sicht beschreibt.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Table Lineage, Column-Level Lineage, Jobs, Dashboards und Modelle im Überblick
Unity Catalog unterscheidet sechs Arten von Abhängigkeiten, die jeweils unterschiedliche Analyse- und Auditfragen unterstützen:
| Lineage-Typ | Was erfasst wird | Typischer Use Case | Quelle |
|---|---|---|---|
| Table-Level | Quell- und Ziel-Tabellen pro Query | Impact-Analyse vor Schema-Änderungen | system.access.table_lineage |
| Column-Level | Herkunft einzelner Zielspalten bei Schreiboperationen | PII-Verfolgung, KI-Trainingsdaten-Nachweis | system.access.column_lineage |
| Notebook | Welches Notebook auf die Daten zugegriffen oder sie verändert hat | Forensik, Owner-Zuordnung | Catalog Explorer, Lineage-Tab |
| Job | Welcher Job/Workflow hat die Tabelle berührt | Pipeline-Refactoring, Job-Owner | Catalog Explorer, Lineage-Tab |
| Dashboard | Welches Dashboard nutzt die Tabelle als Quelle | BI-Konsequenzen einer Schema-Änderung | Catalog Explorer, Lineage-Tab |
| Modell (MLflow) | Welche Tabellen in einem Trainingslauf verwendet wurden | EU AI Act, DSGVO-Auskunft, Modell-Reproduzierbarkeit | MLflow Runs, Lineage-Tab |
Wie entsteht Lineage in Unity Catalog?
Lineage wird während der Ausführung von Abfragen und Pipelines erfasst. Dafür müssen vier Voraussetzungen erfüllt sein. Quell- und Zieltabellen müssen über Unity Catalog verwaltet werden. Tabellen im Hive Metastore werden nicht vollständig in der Unity-Catalog-Lineage abgebildet. Die Verarbeitung muss auf einem für Unity Catalog unterstützten Compute erfolgen: Shared Cluster, Single-User-Cluster (Assigned Access Mode), SQL Warehouses und Serverless Compute erfassen Lineage. Nicht entsprechend konfigurierte Cluster erzeugen keine Unity-Catalog-Lineage. Auch der verwendete Verarbeitungsweg muss unterstützt werden. SQL, Python über die Spark DataFrame API, R und Scala sind abgedeckt, wobei sich die Genauigkeit der Spalten-Lineage je nach Sprache und Transformation unterscheiden kann. Die Operation muss eine nachvollziehbare Lese- oder Schreibbeziehung zwischen Unity-Catalog-Objekten erzeugen.
Werden alle vier Bedingungen erfüllt, wird die Lineage automatisch durch die Plattform erfasst. Lineage erscheint im Lineage-Tab der jeweiligen Tabelle im Catalog Explorer und ist parallel über die System Tables abfragbar. Im UI bleibt die Sicht 90 Tage rückwirkend. Für längerfristige und automatisierte Auswertungen sollten die Lineage-Daten aus den System Tables verwendet werden.
Lineage wird damit ohne separate Instrumentierung aus den unterstützten Plattformoperationen erzeugt.
Was Unity-Catalog-Lineage nicht erfasst
Diese Einschränkungen sind insbesondere für Audit- und Impact-Analysen relevant. Einige Verarbeitungspfade erzeugen keine oder nur unvollständige Lineage, ohne dass dies in der Oberfläche ausdrücklich hervorgehoben wird. Dadurch kann eine unvollständige Lineage fälschlicherweise als vollständiger Nachweis verwendet werden.
Nicht unterstützte Schnittstellen
Direkte Schreibzugriffe aus Pandas oder anderen Bibliotheken auf Cloud-Speicher werden nicht automatisch erfasst. Auch externe Programme oder Konnektoren außerhalb der Databricks-Ausführung tauchen nicht auf.
Streaming-Sonderfälle
Spark Structured Streaming mit foreachBatch-Schreib-Hooks, mehrstufige Streaming-Strecken über Hive Metastore oder Custom-Konnektoren erscheinen nicht oder nur teilweise.
Hive-Metastore-Reste
Alles, was noch im Hive Metastore liegt, erzeugt keine UC-Lineage. Erst das erste über Unity Catalog verwaltete Objekt startet die Lineage-Kette.
Direkte Dateipfade
Direkter Pfad-Zugriff auf dbfs-Speicherpfade ohne External Location umgeht die zentrale Objekt- und Governance-Schicht und erscheint nicht im Lineage-Tab.
Externe BI-Konsumenten
Power BI- oder Tableau-Reports über JDBC/ODBC erscheinen nur, wenn sie über einen verbundenen Workspace-Connector laufen, je nach Treiber und Verbindungsweg eingeschränkt oder generisch dargestellt.
Reines Delta Live Tables auf UC bildet bei den Streaming-Sonderfällen die Ausnahme und wird vollständig erfasst.
Column-Level Lineage: PII-Spalten und KI-Trainingsdaten nachvollziehen
Spalten-Lineage (column-level lineage) ermöglicht deutlich präzisere Analysen als eine reine Betrachtung auf Tabellenebene. Sie ordnet Zielspalten den verwendeten Quellspalten zu. Damit lassen sich Fragen beantworten, die ein klassisches Lineage-Tool offen lässt: In welche Tabellen, Berichte oder Modelle ist die Spalte customer_email eingeflossen? Welche Modelle wurden mit Daten aus der Spalte birthdate trainiert?
Solche Abhängigkeiten lassen sich über die Lineage-Systemtabellen auswerten. Hier alle Konsumenten einer sensiblen Spalte:
Die Ergebnisse können DSGVO-Prüfungen, Datenminimierungsanalysen und Nachweise zu Trainingsdaten unterstützen. Die Abhängigkeiten werden aus der tatsächlichen Verarbeitung abgeleitet und müssen nicht vollständig manuell dokumentiert werden.
Spalten-Lineage funktioniert in SQL und über die Spark DataFrame API verlässlich. UDFs, dynamisch erzeugte SQL-Abfragen und komplexe Transformationen können die Herkunft einzelner Spalten nur eingeschränkt abbilden. Die Zielspalte kann sichtbar sein, obwohl nicht jede verwendete Quellspalte eindeutig nachvollzogen wird.
Eine kompakte Übersicht der Spalten-Lineage-Mechanik führt Databricks in der Doku zu Column-Level Lineage.
Databricks System Tables: Lineage per SQL auswerten
Die System Tables bilden die Grundlage für automatisierte Lineage- und Audit-Auswertungen. Dafür stehen insbesondere zwei Tabellen unter system.access zur Verfügung:
| Tabelle | Inhalt | Typischer Einsatz |
|---|---|---|
| system.access.table_lineage | Source/Target-Tabellen pro erfasster Operation, mit Event-Zeit, Notebook/Job-Referenz, User | Coverage-Reports, Impact-Analyse, Job-Auditierung |
| system.access.column_lineage | Source/Target-Spalten pro Schreib-Operation, mit Event-Zeit und Tabellen-Referenz | PII-Verfolgung, KI-Trainingsdaten-Nachweis, Schema-Refactoring |
Beide Tabellen stehen für produktive Auswertungen zur Verfügung und werden im Format von Databricks dokumentiert. Aufbau und Felder beschreibt die Doku zu Lineage System Tables. Wie ihr System Tables in eurer Plattform aktiviert, Berechtigungen vergebt und die Aufbewahrung steuert, klären wir im Überblick zu System Tables in Unity Catalog.
MLflow Lineage: Trainingsdaten und Modelle verbinden
Modell-Lineage verbindet Trainingsläufe und registrierte Modelle mit den verwendeten Datenquellen und ist eine mögliche Grundlage für Nachweise im Rahmen von KI-Governance und Datenschutz. Läuft ein MLflow-Trainings-Run auf einer UC-Tabelle und wird das Modell in der Unity-Catalog-Model-Registry registriert, verknüpft UC den Run mit den Trainingstabellen. Im Lineage-Tab des Modells erscheinen die Trainings-Quellen, im Lineage-Tab der Tabelle erscheinen die Modelle, die darauf trainiert wurden.
Damit lässt sich die Standardfrage einer EU-AI-Act-Auditierung beantworten: Welche Datenquellen wurden für das Training genutzt und wer war für diese Daten verantwortlich. Voraussetzung sind die Unity-Catalog-Model-Registry und unterstützte Trainingspfade auf Unity-Catalog-Daten.
Wie Modell-Lineage in ein vollständiges AI-Governance-Setup eingebettet wird, von Trainings-Pipeline über Evaluation bis zum Drift-Monitoring, klären wir im Überblick zu AI-Governance auf Databricks.
Wann ergänzen Purview, Atlan oder Collibra?
Unity-Catalog-Lineage bildet Datenflüsse außerhalb von Databricks nur eingeschränkt ab. Sobald Daten von einem Drittsystem (Fivetran, Kafka, Quellsystem) in UC einlaufen oder UC-Daten in BI- oder Reverse-ETL-Wege fließen, entsteht eine Lücke zwischen den beteiligten Systemen. Für eine systemübergreifende Sicht können externe Lineage- und Katalogwerkzeuge ergänzt werden.
OpenLineage ist der offene Standard, über den UC-Lineage in externe Werkzeuge fließt. Databricks unterstützt den OpenLineage-Spark-Connector und exportiert Lineage-Events an konfigurierte Endpunkte. Die typischen Konsumenten sind Microsoft Purview, Atlan, Collibra, Alation und Monte Carlo. Die Databricks-Doku zu OpenLineage zeigt die Konfiguration.
Drei Fragen helfen bei der Entscheidung, ob ein externes Werkzeug benötigt wird:
| Frage | UC-Lineage reicht | Externes Tool nötig |
|---|---|---|
| Spielt sich der Datenfluss komplett auf Databricks ab? | ja | nein |
| Sind Quellsysteme oder BI-Konsumenten außerhalb Databricks im Audit-Scope? | nein | ja (Cross-System-Sicht) |
| Wird ein Enterprise-Katalog (Purview, Atlan, Collibra) als Single-Source-of-Truth gefordert? | nein | ja (UC liefert dorthin per OpenLineage) |
Externe Werkzeuge sollten die Databricks-Lineage aufnehmen und um weitere Systeme ergänzen. Sie führen Lineage-Informationen aus Databricks, Quellen und Konsumenten in einer gemeinsamen Sicht zusammen. Werden beide Lineage-Sichten parallel ohne klaren Anschluss gepflegt, entstehen unterschiedliche und nur schwer abgleichbare Darstellungen des Datenflusses. Ein klares Zielbild verwendet Unity Catalog als Quelle für Databricks-interne Ereignisse und das externe Werkzeug als systemübergreifenden Aggregator.
Lineage beschreibt den Datenfluss, legt aber weder fachliche Bedeutung noch Verantwortung fest. Drei weitere Governance-Bausteine ergänzen diese Sicht:
Discovery hilft, eine Tabelle überhaupt zu finden. Ohne Discovery bleibt die Lineage nur für Nutzer hilfreich, die das Objekt bereits kennen.
Tags klassifizieren, was eine Spalte enthält. Eine Spalte muss zunächst als personenbezogen klassifiziert sein, bevor ihre Lineage gezielt ausgewertet werden kann.
Permissions regeln, wer was sehen darf. Ohne eindeutige Ownership bleibt unklar, wer auf festgestellte Abhängigkeiten oder Risiken reagieren muss.
Eine vollständige Datenproduktsicht verbindet Discovery, Klassifikation, Berechtigungen, Ownership und Lineage. Wie sie als Architektur zusammenwirken, zeigen wir im Überblick zu Unity Catalog.
Use Cases für Unity Catalog Lineage: Impact-Analyse, Audit, Refactoring und AI Act
Vier Anwendungsfälle sind für viele Plattformen besonders relevant:
Impact-Analyse
Vor Rename, Drop oder Typ-Wechsel einer Spalte zeigt Spalten-Lineage alle Konsumenten von Notebook bis Dashboard bis Modell, ohne ausschließlich auf Dokumentation und manuelle Rückfragen angewiesen zu sein.
Audit-Antworten
Auf eine Audit-Anfrage zu einer sensiblen Spalte liefert die Spalten-Lineage eine Liste der bekannten Konsumenten, sofern die relevanten Verarbeitungspfade erfasst sind. Nicht unterstützte Pfade sollten als Lücken dokumentiert werden.
Pipeline-Refactoring
Vor der Abschaltung eines Jobs zeigt die Job-Lineage in den System Tables, ob seine Ergebnistabellen noch aktive Konsumenten besitzen.
EU-AI-Act-Vorbereitung
Modell-Lineage zwischen MLflow-Run und UC-Tabelle kann die Herkunft der Trainingsdaten automatisiert erfassen, sofern die Trainings-Pipeline UC-konform aufgesetzt ist.
Grenzen von Unity Catalog Lineage
Unity Catalog Lineage hilft dabei, Datenflüsse sichtbar zu machen. Sie beantwortet aber nicht jede Lineage-Frage automatisch. Vor allem für Audits und regulierte Datenflüsse sollten einige Grenzen klar sein.
Abdeckung muss geprüft werden
Sichtbare Einträge bedeuten nicht automatisch, dass der gesamte Datenfluss erfasst ist. Eine regelmäßige Auswertung zeigt, welche Tabellen, Jobs und Pipelines Lineage erzeugen und wo Einträge fehlen.
Nicht jeder Pfad wird automatisch erfasst
Pandas-Pipelines, native JDBC-Schreiber, foreachBatch-Logik oder Custom-Konnektoren können außerhalb der automatischen UC-Lineage liegen und brauchen eine Anpassung der Umsetzung oder ergänzende Dokumentation.
Hive-Metastore unterbricht die Sicht
Solange Tabellen oder Jobs noch im Hive Metastore laufen, endet die Unity-Catalog-Lineage an dieser Grenze, bis die Workloads migriert oder anderweitig erfasst werden.
Spalten-Lineage bleibt unscharf
Bei UDFs, dynamischem SQL oder komplexen Joins kann die Herkunft einzelner Spalten unscharf werden. Kritische PII- oder Compliance-Pfade sollten stichprobenartig mit der Implementierung abgeglichen werden.
Begrenzter Zeitraum im UI
Die Lineage-Ansicht im UI reicht für schnelle Impact-Analysen. Für längere Auditzeiträume sollten Lineage-Daten aus System Tables regelmäßig gesichert und ausgewertet werden.
Kein Ersatz für Datenverträge
Lineage zeigt, was tatsächlich ausgeführt wurde, nicht, was ein Datenfluss leisten soll. Dafür braucht es weiterhin Data Contracts, Qualitätsregeln und klare Schema-Versionierung.
Fazit
Unity-Catalog-Lineage liefert erst dann einen belastbaren Audit-Nachweis, wenn Coverage regelmäßig gemessen, Lücken dokumentiert und kritische Datenflüsse stichprobenartig geprüft werden.
Unity-Catalog-Lineage ist eine wichtige Grundlage, um Datenabhängigkeiten sichtbar zu machen. Sie hilft bei Impact-Analysen, Audits, Pipeline-Refactorings und bei der Nachvollziehbarkeit von Trainingsdaten für KI-Modelle. Entscheidend ist aber nicht nur, dass Lineage vorhanden ist. Entscheidend ist, wie vollständig sie den tatsächlichen Datenfluss abbildet.
Die technische Erfassung ist in Unity Catalog weitgehend integriert. Der eigentliche Betriebspunkt liegt deshalb woanders: Lineage-Abdeckung regelmäßig messen, bekannte Lücken dokumentieren und kritische Datenflüsse gezielt prüfen. Eine Plattform, die ihre Lineage-Abdeckung pro Catalog kennt, PII-Spalten bis zu Konsumenten verfolgen kann und Audit-Auswertungen über System Tables vorbereitet hat, beantwortet Prüfungsfragen deutlich schneller.
Externe Lineage- oder Governance-Werkzeuge können ergänzen, wenn Datenflüsse über Databricks hinaus betrachtet werden müssen. Unity Catalog sollte dabei die führende Quelle für Databricks-interne Lineage bleiben. Externe Tools können diese Informationen übernehmen und mit Lineage aus anderen Systemen zusammenführen. Parallel gepflegte Lineage-Modelle führen dagegen schnell zu widersprüchlichen Aussagen.
Mein Vorschlag: Unity-Catalog-Lineage als zentrale Quelle für Databricks-interne Datenflüsse nutzen und mit einem Coverage-Dashboard auf System Tables absichern. PII-Spalten sollten konsistent klassifiziert werden, damit ihre Weiterverwendung gezielt geprüft werden kann. Trainingsläufe sollten auf Unity-Catalog-Daten und über die Unity-Catalog-Model-Registry standardisiert werden. Externe Kataloge ergänzen die Sicht für Systeme außerhalb von Databricks. Wichtig bleibt außerdem: Lineage-Auswertungen brauchen klare Owner. Ohne benannte Verantwortung ist zwar sichtbar, wo Daten fließen, aber nicht, wer erkannte Risiken bearbeitet.
FAQ
Lineage in Unity Catalog ist die runtime-erfasste Sicht auf den Datenfluss zwischen UC-Objekten. Sie verbindet Tabellen, Spalten, Notebooks, Jobs, Dashboards und MLflow-Modelle und macht Impact-Analyse, Audit-Antworten und Trainingsdaten-Nachweise möglich, ohne dass jemand manuelle Lineage pflegen muss.
