Data Lineage: Wie Datenwege und Transformationen nachvollziehbar bleiben

Data Lineage verfolgt dokumentierte Datenabhängigkeiten

Dafür braucht es mehr als ähnliche Dateinamen: Die verwendeten Datenstände und Verarbeitungsläufe müssen zugeordnet sein. Wie weit eine Auskunft reicht, hängt von der erfassten Granularität und Abdeckung ab.

Wie der Bericht zum Mittelwert 20,0 °C kommt

Ein fiktiver Chargenbericht B-01 enthält den Mittelwert 20,0 °C. Der zugehörige Berechnungslauf R-01 hat drei Messwerte verwendet: 19,8 °C, 20,0 °C und 20,2 °C. Die für dieses Beispiel festgelegte Regel bildet das arithmetische Mittel und rundet die Anzeige auf eine Nachkommastelle.

Vom Bericht aus muss sich der verwendete Lauf und von dort der damalige Stand der drei Eingaben finden lassen. Die Nachrechnung ergibt (19,8 + 20,0 + 20,2) / 3 = 20,0. Eine Verbindung zur heutigen Messtabelle allein genügt nicht, wenn deren Werte inzwischen korrigiert wurden.

Die Datenlinie erklärt hier eine Berechnung. Ob ein Mittelwert dieser drei Beobachtungen für eine konkrete Qualitätsentscheidung überhaupt geeignet ist, bleibt eine davon unabhängige fachliche Frage.

Was eine Korrektur für bekannte Ausgaben bedeutet

Im selben Beispiel wird 20,2 °C kontrolliert auf 20,3 °C korrigiert. Eine Vorwärtsabfrage identifiziert R-01 und B-01 als Verwendungen des früheren Werts. Für eine Neuberechnung mit der korrigierten Eingabe ergibt sich 60,1 / 3 = 20,033… °C; auf eine Nachkommastelle bleibt die Anzeige 20,0 °C.

Die Abhängigkeit ist also betroffen, obwohl die gerundete Zahl gleich bleibt. Ob der Bericht ergänzt, ersetzt oder erneut geprüft werden muss, lässt sich aus der unveränderten Anzeige nicht ableiten. Diese Entscheidung richtet sich nach dem Verwendungszweck und den dafür geltenden Vorgaben.

B-01 behält den Bezug zu seinen ursprünglichen Eingaben. Eine neue Rechnung erhält einen eigenen Lauf und gegebenenfalls eine neue Berichtsfassung. So bleiben historische Darstellung und heutige Bewertung auseinanderzuhalten. Nicht erfasste Exporte oder manuelle Kopien tauchen in der Abfrage dagegen nicht automatisch auf.

System-, Datensatz- und Feld-Lineage

Die Granularität bestimmt, wie präzise eine Lineage-Auskunft ausfällt und wie aufwendig sie zu erzeugen und zu pflegen ist. Auf der obersten Ebene zeigt System-Lineage, dass Daten beispielsweise vom Produktionssystem in eine Analyseplattform und anschließend in einen Bericht gelangen. Diese Sicht eignet sich für Architekturübersichten, beantwortet aber noch nicht, welcher Wert tatsächlich übernommen wurde.

Datensatz-Lineage meint hier die Ebene eines Datenbestands (Dataset), etwa einer Tabelle, Datei oder eines Ereignisbestands, nicht eine einzelne Tabellenzeile. Sie verbindet solche Bestände beziehungsweise identifizierbare Dokumentversionen. Sie kann zeigen, dass ein Chargenbericht aus einem bestimmten Aufgabenbestand und einer bestimmten Spezifikationsversion erzeugt wurde.

Feld-Lineage beschreibt die Abhängigkeit einzelner Attribute. Sie wird wichtig, wenn ein Zielfeld aus mehreren Quellen berechnet, umbenannt oder in ein anderes Format überführt wird. Noch feiner wäre eine Lineage einzelner Tabellenzeilen (Records) oder Werte. Diese kann bei kritischen Entscheidungen sinnvoll sein, ist aber nicht für jede Information wirtschaftlich oder fachlich erforderlich.

Eine gute Architektur erlaubt deshalb unterschiedliche Sichten auf dieselbe Kette. Die Übersicht bleibt verständlich, während bei Bedarf auf die relevante Detailstufe navigiert werden kann.

Welche Bedeutung die Kanten des Graphen haben

Ein gerichteter Lineage-Graph kann Datenbestände, Felder, Verarbeitungsläufe und Ausgaben als Knoten enthalten. Seine Kanten müssen benennen, welche Beziehung gemeint ist: Eingabe eines Laufs, daraus erzeugte Ausgabe oder Übernahme in ein Berichtsfeld.

Eine Kante zwischen zwei Tabellen kann eine mögliche Abhängigkeit ihres Schemas beschreiben. Sie belegt noch nicht, welche Zeilen ein bestimmter Lauf tatsächlich gelesen hat. Für den Mittelwertfall muss deshalb die gewählte Detailstufe bis zu den verwendeten Eingaben reichen.

Ebenso ist der Transport eines unveränderten Werts von seiner Umrechnung oder Aggregation zu unterscheiden. Beide können im gleichen Graphen erscheinen, führen aber zu unterschiedlichen Fragen an die Nachvollziehbarkeit.

Die Transformation erklärt den Übergang zum Ergebnis

Zwischen Eingabe und Ausgabe kann Kopieren, Filtern, Umrechnen oder Zusammenführen liegen. Bei einer Berechnung sind insbesondere die verwendete Regel, Parameter und Rundung zu dokumentieren. Ein Pfeil mit der Aufschrift „verarbeitet“ erklärt den Mittelwert noch nicht.

W3C PROV unterscheidet Nutzung, Erzeugung und Ableitung.^[1] Diese Beziehungen helfen, eine Verarbeitung zu beschreiben: Ein Lauf verwendet Eingaben und erzeugt eine Ausgabe. Dass zwei Bestände im selben System vorkommen, genügt dafür nicht.

Die Data Provenance umfasst zusätzlich die Entstehungs- und Beteiligungsbeziehungen: Wer hat Daten erzeugt, durch welche Tätigkeit und aus welcher Quelle? Data Lineage konzentriert sich auf die dokumentierte Verarbeitung, die zwei konkrete Datenstände verbindet.

Eindeutige Identitäten und Versionen halten die Kette zusammen

Eine Datenlinie bricht, wenn verschiedene Objekte denselben Namen tragen oder ein Objekt im Zeitverlauf seine Bedeutung ändert. Tabellenname, Dateiname oder Berichtstitel allein sind daher selten stabile Identifikatoren. Zusätzlich werden System, Namensraum, Objektart, Version und gegebenenfalls Gültigkeitszeitraum benötigt.

Das gilt ebenso für Verarbeitungsschritte. Eine Berechnung mit dem Namen „Ausbeute“ kann nach einer Regeländerung eine andere Logik besitzen. Werden alter und neuer Lauf nur mit demselben Namen verknüpft, entsteht eine scheinbar durchgängige Linie, obwohl sich ihre Semantik verändert hat.

W3C PROV behandelt Revisionen und Spezialisierungen als Beziehungen zwischen unterscheidbaren Entitäten.^[1] Für betriebliche Systeme folgt daraus ein praktisches Prinzip: Veränderte Datenstände und Regeln sollten identifizierbar bleiben, statt frühere Bedeutungen unsichtbar zu überschreiben.

Lineage kann technisch und fachlich erfasst werden

Lineage-Metadaten können auf unterschiedliche Weise entstehen. Datenpipelines können ihre Ein- und Ausgaben beim Lauf automatisch melden. Datenbanken und Abfragewerkzeuge können Beziehungen aus SQL, Schemas oder Ausführungsplänen ableiten. Schnittstellen können Quelle, Ziel und Übertragungsstatus protokollieren. Fachanwendungen können die Verbindung direkt beim Ausführen einer Aufgabe erzeugen.

OpenLineage strukturiert Laufzeitmetadaten um Ereignisse sowie die Kernelemente Job, Run und Dataset. Zusätzliche Facets können weitere Eigenschaften von Ein- und Ausgaben, Verarbeitungsläufen und Datenbeständen ausdrücken.^[2] Apache Atlas stellt Lineage als Beziehungen zwischen typisierten Metadatenobjekten dar und ermöglicht Abfragen über Eingaben, Ausgaben und Prozesse.^[3]

Automatische Erfassung reduziert manuelle Pflege, ist aber nicht automatisch vollständig. Eine technisch erkannte Tabellenabhängigkeit kennt möglicherweise nicht den fachlichen Zweck einer Berechnung. Manuell dokumentierte Linien können diesen Zweck erklären, veralten jedoch leichter. In der Praxis ist eine Kombination sinnvoll: technische Beziehungen werden automatisiert erzeugt und durch fachliche Bezeichnungen, Kritikalität und Geltungsregeln ergänzt.

Vollständigkeit und Aktualität der Lineage müssen selbst geprüft werden

Eine Lineage-Ansicht kann professionell aussehen und dennoch Lücken enthalten. Nicht erkannte Skripte, Tabellenkalkulationen, manuelle Exporte, umbenannte Felder oder externe Systeme unterbrechen die Kette. Deshalb müssen auch Lineage-Metadaten festgelegte Qualitätsanforderungen erfüllen.

Zu prüfende Merkmale sind unter anderem:

• Abdeckung: Sind alle für den Zweck relevanten Quellen und Ziele erfasst?
• Richtigkeit: Entsprechen die dargestellten Abhängigkeiten der tatsächlichen Verarbeitung?
• Aktualität: Wurde eine Änderung an Schema, Schnittstelle oder Regel übernommen?
• Granularität: Reicht die gewählte Ebene für die konkrete Frage aus?
• Verständlichkeit: Können Fachanwender die Transformation und ihre Bedeutung beurteilen?
• Belegbarkeit: Ist erkennbar, wodurch eine Beziehung erfasst oder abgeleitet wurde?

Lineage sollte daher nicht als einmalige Dokumentationsaufgabe behandelt werden. Sie ist ein laufendes Metadatenprodukt, das zusammen mit den zugrunde liegenden Systemen und Datenmodellen weitergeführt wird.

Welche Fragen eine Datenlinie beantworten muss

Eine Datenlinie beginnt nicht mit einer möglichst großen Grafik, sondern mit einer konkreten Fragestellung. Je nach Zweck kann sie auf System-, Datensatz-, Feld- oder Einzelwertebene benötigt werden. Typische Fragen lauten:

• Ursprung: Aus welcher Quelle stammt die betrachtete Information?
• Weg: Welche Anwendungen, Schnittstellen, Tabellen oder Dokumente hat sie durchlaufen?
• Transformation: Wurde sie kopiert, umgerechnet, gefiltert, zusammengeführt, aggregiert oder manuell ergänzt?
• Version: Welche Version einer Regel, eines Schemas oder einer Berechnung wurde angewendet?
• Zeit: Wann entstand die jeweilige Station, und auf welchen fachlichen Gültigkeitszeitraum bezog sie sich?
• Abhängigkeit: Welche nachgelagerten Datenprodukte und Entscheidungen verwenden das Ergebnis?
• Verantwortung: Welcher technische oder fachliche Vorgang löste die Verarbeitung aus?

Nicht jede Anwendung benötigt alle Ebenen. Für eine technische Auswirkungsanalyse kann die Beziehung zwischen Tabellen genügen. Für einen kritischen berechneten Qualitätswert muss möglicherweise bis auf Eingabefelder, Berechnungsparameter und verwendete Rohdaten zurückgegangen werden.

Nutzen in regulierten Produkt- und Chargenprozessen

In regulierten Prozessen ist nicht jede Datenbewegung gleich kritisch. Eine risikobasierte Lineage konzentriert sich auf Daten, die Produktqualität, Patientensicherheit, Freigabe, Nachweisführung oder wesentliche betriebliche Entscheidungen beeinflussen.

Bei einer Abweichungsuntersuchung kann sie zeigen, welche Ergebnisse von einem fehlerhaften Eingangswert oder einer nicht korrekt angewendeten Regel abhängen. Bei einer Systemänderung unterstützt sie die Bewertung, welche Schnittstellen und Berichte getestet werden müssen. Bei einer Prüfung erleichtert sie die Erklärung, wie eine ausgewiesene Kennzahl aus ihren Quellen hervorging.

Der Nutzen entsteht nicht allein durch Transparenz. Erst die Verbindung mit Verantwortlichkeiten, Prüfregeln und kontrollierten Korrekturen ermöglicht eine angemessene Reaktion. Lineage liefert die Abhängigkeitskarte; die fachliche Bewertung entscheidet über Maßnahmen.

Data Lineage, Provenance, Audit Trail und Event Sourcing

Die Begriffe überlappen, beantworten aber unterschiedliche Leitfragen. Data Provenance beschreibt umfassend, durch welche Entitäten, Aktivitäten und verantwortlichen Akteure eine Information entstand oder beeinflusst wurde. Data Lineage konzentriert sich enger auf ihren Weg, ihre Transformationen und ihre Abhängigkeiten über Datenbestände und Systeme hinweg.

Ein Audit Trail hält relevante Eingaben, Änderungen und Löschungen mit Identität, Zeitpunkt und gegebenenfalls Grund fest. Er kann eine wichtige Quelle für Lineage sein, bildet aber nicht automatisch alle Datenflüsse und Ableitungen ab.

Event Sourcing ist ein Architekturprinzip, bei dem Anwendungszustände aus einer gespeicherten Folge fachlicher Ereignisse gebildet werden. Diese Ereignisse können eine sehr gute Grundlage für Ableitungsbeziehungen liefern. Trotzdem muss zusätzlich modelliert werden, welche Datenobjekte aus welchen Ereignissen und Transformationen hervorgegangen sind.

Datenintegrität bezeichnet die Vollständigkeit, Konsistenz und Genauigkeit von Daten über ihren Lebenszyklus. Lineage unterstützt ihre Beurteilung, indem Quellen und Verarbeitung nachvollziehbar werden. Eine dokumentierte Linie beweist jedoch nicht, dass der ursprüngliche Wert richtig oder jeder Verarbeitungsschritt fachlich angemessen war.

Was sich aus der Datenlinie nicht ableiten lässt

Die Validierung von Schnittstellen und Kontrollen bleibt eine eigene Aufgabe.

Ob die Linie auch beteiligte Personen, Entscheidungsgründe oder weitere Entstehungsbedingungen enthält, hängt vom tatsächlich erfassten Modell ab. Eine pauschale Grenze gegenüber Provenance würde diese unterschiedlichen Ausgestaltungen verdecken.

Schutz gegen Veränderungen und die fachliche Entscheidung über Korrekturen entstehen nicht allein dadurch, dass vorhandene Beziehungen angezeigt werden.

Eine Datenlinie endet dort, wo die Zuordnung fehlt

Im Mittelwertbeispiel lässt sich B-01 erklären, weil Eingaben, Rechnung und Ausgabe zusammengehören. Ob eine weitere Datei denselben Wert enthält, ist ohne dokumentierten Übertragungsbezug noch keine gesicherte Abhängigkeit.

Für die Praxis zählt deshalb beides: bekannte Datenwege abfragen und unbekannte Übergänge benennen. Die Datenlinie grenzt den Untersuchungsraum ein; sie entscheidet nicht selbst, welche fachliche Maßnahme eine Korrektur verlangt.