Was ist Lineage auf Spaltenebene?
Lineage auf Spaltenebene verfolgt genau, wie einzelne Datenfelder, also bestimmte Spalten in bestimmten Tabellen, entstehen, umgeformt und genutzt werden, während sie durch Pipelines, Warehouses und analytische Systeme fließen. Wo die Data Lineage auf Tabellenebene Ihnen sagt, dass Tabelle B aus Tabelle A entstanden ist, sagt Ihnen die Lineage auf Spaltenebene, dass die Spalte net_revenue im Finanzbericht aus gross_amount minus discount_amount in der Tabelle der Bestellungen berechnet wurde, nach einer Währungsumrechnung mit dem Feld fx_rate aus der Kurstabelle.
Diese Genauigkeit wird zunehmend von Organisationen erwartet, die in regulierten Branchen arbeiten, KI-Modelle auf Unternehmensdaten bauen oder schnell einschätzen müssen, was eine Schemaänderung in einer verzweigten Datenlandschaft anrichtet.
Lineage auf Spaltenebene verfolgt genau, wie jedes Feld durch die Pipelines fließt und sich dabei verändert, nicht nur, welche Tabellen verbunden sind. Sie stützt die Rückverfolgbarkeit von Risikodaten nach BCBS 239, das Verzeichnis von Verarbeitungstätigkeiten nach DSGVO und die Herkunft von KI-Trainingsdaten. Sie erlaubt eine genaue Wirkungsanalyse, wenn sich ein vorgelagertes Schema ändert. Die Interactive Data Lineage von Dawiso zeigt Datenflüsse auf Spaltenebene, wo die Quelle sie liefert, etwa aus Databricks Unity Catalog oder aus dem Parsen von SQL-Skripten.
Lineage auf Spaltenebene, definiert
Die Lineage auf Spaltenebene beantwortet für jedes Feld in jeder Tabelle eine bestimmte Frage: Woher kam dieser Wert, und wie wurde er umgeformt, bis er hier ankam? Die Antwort ist ein gerichteter Graph: Quellspalten führen zu Transformationsausdrücken, diese führen zu Zielspalten, über jeden Schritt der Pipeline hinweg.
Ein vollständiger Eintrag auf Spaltenebene für eine Kennzahl wie customer_lifetime_value kann sich erstrecken über:
- Quellsysteme: Rohereignisse aus einem CRM, Transaktionssätze aus einem ERP, Vertragsdaten aus einem Dokumentenmanagement
- Transformationen: Aggregationslogik in einem dbt-Modell, Währungsnormalisierung in einem Spark-Job, Ausreißerfilter in einem Python-Notebook
- Zwischentabellen: Staging-Tabellen, Feature-Tabellen, Aggregattabellen
- Ausgaben: Spalten in BI-Dashboards, Merkmale für das Training von Modellen, Felder in regulatorischen Berichten
Jeder Knoten in diesem Graphen ist eine bestimmte Spalte in einer bestimmten Tabelle zu einem bestimmten Zeitpunkt. Die Kanten sind Transformationsausdrücke, also der SQL-, Python- oder Spark-Code, der jede Ausgabe aus ihren Eingaben erzeugt hat. Diese Detailtiefe erreichen Sie, indem Sie den Transformationscode parsen oder zur Laufzeit aufzeichnen, welche Spalten gelesen und geschrieben werden, und nicht bloß beobachten, zwischen welchen Tabellen sich Daten bewegen.
Spaltenebene gegenüber Tabellenebene
Die Lineage auf Tabellenebene (auch Lineage auf Datensatzebene genannt) bildet ab, welche Tabellen zur Erzeugung welcher anderen Tabellen gedient haben. Sie ist der Ausgangspunkt für Governance und deutlich leichter automatisch zu erfassen: Viele Orchestrierungswerkzeuge und Transformationsrahmen protokollieren Abhängigkeiten auf Tabellenebene. Sie hat aber entscheidende Grenzen:
Die Lineage auf Tabellenebene sagt einer prüfenden Person, dass Kundendaten in einen regulatorischen Bericht fließen. Die Lineage auf Spaltenebene sagt ihr, welche Felder das sind, und beantwortet damit, ob die Spalte email (PII nach DSGVO) tatsächlich zur Ausgabe beiträgt oder nur ein abgeleitetes customer_segment. Diese Unterscheidung zählt für das Verzeichnis von Verarbeitungstätigkeiten nach DSGVO und für die Datenminimierung. Auf Tabellenebene lässt sich das nicht entscheiden.
Regulatorische Anwendungsfälle
Keine Vorschrift nennt die Lineage auf Spaltenebene ausdrücklich, aber mehrere stellen Erwartungen an die Rückverfolgbarkeit, die sich ohne sie kaum erfüllen lassen:
- BCBS 239: Die Grundsätze des Basler Ausschusses für die effektive Aggregation von Risikodaten und die Risikoberichterstattung wurden für global systemrelevante Banken geschrieben. Grundsatz 3 erwartet genaue, verlässliche Risikodaten, die weitgehend automatisiert aggregiert werden, und der Leitfaden der EZB zur Risikodatenaggregation von 2024 verlangt von Banken eine vollständige und aktuelle Data Lineage auf Ebene der Datenattribute, von der Datenerfassung über Extraktion und Transformation bis zum Laden. Die Lineage auf Spaltenebene ist der praktikable Weg, das in großem Maßstab zu leisten.
- Art. 30 DSGVO: Das Verzeichnis von Verarbeitungstätigkeiten muss unter anderem die Zwecke der Verarbeitung, die Kategorien personenbezogener Daten und die Empfänger enthalten. Die Lineage auf Spaltenebene bildet ab, welche PII-Felder durch welche Pipelines in welche Ausgaben fließen, und hilft so, dieses Verzeichnis vollständig und aktuell zu halten.
- SOX Section 404: Die Unternehmensleitung muss die internen Kontrollen über die Finanzberichterstattung beurteilen. Die Lineage auf Spaltenebene dokumentiert die Transformationslogik hinter berichteten Zahlen, einen Audit-Trail, der sich von Hand kaum aktuell halten lässt.
- DORA: Artikel 8 verlangt von Finanzunternehmen, ihre Informationsassets zu identifizieren und zu dokumentieren und die Verbindungen und Abhängigkeiten zwischen ihnen abzubilden. Data Lineage ist ein Baustein dieser Abbildung.
Wirkungsanalyse
Einer der praktisch wertvollsten Einsätze der Lineage auf Spaltenebene ist die Wirkungsanalyse: zu bestimmen, was bricht, wenn sich ein vorgelagertes Schema ändert. Ohne sie verlangt die Antwort auf „Was ist betroffen, wenn wir diese Spalte umbenennen?“ die händische Prüfung jeder nachgelagerten Pipeline und jedes Berichts, eine Arbeit, die in verzweigten Umgebungen Tage kostet und fehleranfällig ist.
Mit der Lineage auf Spaltenebene liegt die Wirkungsanalyse sofort vor: Der Graph zeigt, welche erfassten nachgelagerten Transformationen die umbenannte Spalte verwenden, welche Berichte diese Transformationen konsumieren und welche KI-Modelle auf diesen Merkmalen trainiert sind. Eine Änderung, für die sonst beispielsweise 200 Bestände zu sichten wären, lässt sich auf die 7 eingrenzen, welche die geänderte Spalte tatsächlich verwenden.
In großem Maßstab, also bei Tausenden Pipelines und Hunderten Berichten, ist es die Lineage auf Spaltenebene, mit der ein Team eine Schemaänderung vor der Freigabe prüfen kann, statt erst von Nutzern zu erfahren, dass etwas gebrochen ist. Das ist der Unterschied zwischen sicheren Schemaänderungen und Störungen in der Produktion, die Nutzer entdecken.
Wie die Lineage auf Spaltenebene funktioniert
Um die Lineage auf Spaltenebene zu erfassen, wird die Logik in SQL, Python, Spark oder dbt aufgelöst, die jede Ausgabe erzeugt, entweder durch Parsen oder indem aufgezeichnet wird, was die Engine zur Laufzeit liest und schreibt. Das ist technisch schwerer als auf Tabellenebene, die sich allein aus Orchestrierungsprotokollen erfassen lässt.
Drei Wege gibt es, häufig in Kombination:
- Statische SQL-Analyse: Den SQL-Code statisch auswerten, um Spaltenverweise und Ableitungsausdrücke zu gewinnen. Das funktioniert gut für geradliniges SQL, verlangt aber einen Parser, der mit komplexen Ausdrücken, CTEs, Fensterfunktionen und Dialekten umgeht (SQL in BigQuery ≠ SQL in Snowflake ≠ SQL in PostgreSQL).
- Protokollierung zur Laufzeit: Die Ausführung von Abfragen und Transformationen so instrumentieren, dass tatsächliche Lese- und Schreibzugriffe auf Spaltenebene erfasst werden. Das erwischt dynamisches SQL und generierte Transformationen, die eine statische Analyse übersieht, und kostet mehr Infrastruktur. Der Standard OpenLineage definiert dafür ein Facet für Lineage auf Spaltenebene, das seine Spark-Integration ausgeben kann.
- Metadaten aus der Plattform: Einige Plattformen stellen Lineage auf Spaltenebene direkt bereit: Unity Catalog in der Systemtabelle
system.access.column_lineage, Snowflake in der View ACCESS_HISTORY (Enterprise Edition) und dbt in seinem Catalog in den Enterprise-Tarifen. Diese Quellen auszulesen ist der Weg mit dem geringsten Aufwand für Organisationen, die ohnehin mit ihnen arbeiten. In Dawiso liest zum Beispiel der Databricks-Konnektorsystem.access.column_lineage, während der Snowflake-Konnektor keine native Lineage von Spalte zu Spalte hat und die Lineage auf Spaltenebene aus dem Parsen von SQL-Skripten bezieht.
KI und die Lineage auf Spaltenebene
Der Aufstieg von maschinellem Lernen und KI in der Unternehmensanalyse stellt neue Anforderungen an die Lineage auf Spaltenebene. Ein Modell, das auf Unternehmensdaten trainiert wurde, ist nur so vertrauenswürdig wie die Herkunft seiner Trainingsmerkmale. Die KI-Verordnung (EU AI Act) stuft KI-Systeme für die Kreditwürdigkeitsprüfung und Bonitätsbewertung natürlicher Personen als Hochrisiko-KI-Systeme ein (Anhang III) und verlangt, dass die Data Governance für die Trainingsdaten eines solchen Systems die Herkunft der Daten, die Datenaufbereitung und eine Untersuchung auf mögliche Verzerrungen abdeckt (Art. 10 Abs. 2). Die Lineage auf Spaltenebene ist ein Weg zu zeigen, welche Rohdatenfelder zu welchem Merkmal im Trainingsbestand beigetragen haben.
Ebenso sollten KI-Agenten, die Unternehmensdaten abfragen, über MCP-angebundene Werkzeuge oder unmittelbar über eine API, auf Spalten arbeiten, deren Lineage und Qualitätssignale bekannt sind. Ein KI-Assistent, der „Wie hoch war unser Nettoumsatz im letzten Quartal?“ beantwortet, sollte belegen können, dass die abgerufene Spalte net_revenue eine dokumentierte Transformationslogik und eine bestandene Qualitätsbewertung hat, und nicht bloß, dass die Tabelle existiert. Die Lineage auf Spaltenebene, sichtbar gemacht über einen Datenkatalog, liefert diesen Kontext.
Fazit
Die Lineage auf Spaltenebene ist die feinste Form der Rückverfolgbarkeit von Daten, die moderne Data Governance kennt. Die Bankenaufsicht erwartet Lineage in dieser Detailtiefe zunehmend, sie stützt Nachweise im Datenschutz, sie ist die Technik, die eine genaue Wirkungsanalyse überhaupt ermöglicht, und sie wird für KI-Systeme, die ihre Ausgaben auf Feldebene rechtfertigen müssen, zunehmend unverzichtbar. Organisationen, die in sie investieren, über statische SQL-Analyse, über Metadaten aus der Plattform oder über beides, gewinnen eine Genauigkeit in der Steuerung ihrer Datenlandschaft, die allein auf Tabellenebene nicht zu haben ist.
Quellen
- Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting (BCBS 239), Januar 2013 (Grundsatz 3).
- Europäische Zentralbank, Guide on effective risk data aggregation and risk reporting, Mai 2024 (Abschnitt 3.4, Data Lineage auf Ebene der Datenattribute).
- DSGVO Article 30, Records of processing activities.
- 15 U.S.C. 7262, Management assessment of internal controls (SOX Section 404).
- Publications Office of the EU (EUR-Lex), Regulation (EU) 2022/2554 (DORA) (Artikel 8, Identifizierung).
- Publications Office of the EU (EUR-Lex), Regulation (EU) 2024/1689, Artificial Intelligence Act (Art. 10 Abs. 2 und Anhang III Nummer 5 Buchstabe b).
- OpenLineage, Column Level Lineage Dataset Facet.
- Databricks, Lineage in Unity Catalog.
- Snowflake, Access History (Lineage auf Spaltenebene, Enterprise Edition).
- dbt Labs, Column-level lineage.
- Dawiso Help, Sources of data lineage.
- Dawiso Help, Databricks connector.
- Dawiso Help, Snowflake connector.
In Aktion erleben
Interactive Data Lineage
Sichtbar machen, wie Daten sich bewegen, sich transformieren und über Systeme, Anwendungen und Berichte hinweg zusammenhängen.