Was ist Data Lineage? Die Transformationen hinter einem Ergebnis

Ein Umsatzdashboard kann eine Zahl zeigen, obwohl sich der Pfad dahinter bereits verändert hat. Die Eingabe wurde aktualisiert. Ein Join-Schlüssel wurde neu zugeordnet. Ein Filter wanderte aus der Abfrage in eine manuell gepflegte Tabelle. Die Zahl trägt noch dasselbe Etikett, aber eine andere Person kann nicht erkennen, ob sie noch dasselbe Objekt ist wie im Vormonat.

Data Lineage ist die Spur von einer erklärten Ausgabe oder Entscheidung zurück durch die Versionen der Eingaben, Transformationen, Joins, Filter, Aggregationen und nachgelagerten Nutzungen, die sie erzeugt haben. Sie markiert eine Rekonstruktionsgrenze, kein Wahrheitsprädikat.

Der Beitrag zum Event-Schema für Umsatzanalysen besitzt die Gestaltung unveränderlicher kommerzieller Ereignisse. Der Beitrag zur Evidenzprüfung besitzt die Frage, welche Evidenz eine Entscheidung überstehen soll. Diese Seite besitzt den Pfad zwischen Datenobjekt und Ergebnis.

Was bedeutet Data Lineage?

Lineage kann einen Katalog von Tabellen, eine Liste vorgelagerter Systeme, eine Warehouse-Funktion oder ein Diagramm an der Wand meinen. Das kann nützlich sein. Eine reproduzierbare Spur entsteht erst, wenn Objekte, Versionen, Operationen und Nutzung identifiziert sind.

Das Modell PROV-DM des World Wide Web Consortium liefert eine allgemeine Sprache dafür. Es beschreibt Provenienz über Entitäten, Aktivitäten und Verantwortliche und umfasst Beziehungen wie Nutzung, Erzeugung, Ableitung, Zuordnung und Zuschreibung (World Wide Web Consortium, 2013). Der Standard beschreibt, wer und was an der Entstehung beteiligt war. Er bescheinigt nicht, dass eine Quelle oder Transformation korrekt ist.

Die praktische Unterscheidung lautet:

Provenienz ist der breitere Kontext. Lineage ist der angewandte Pfad. Datenqualität ist die Eignungsbeurteilung. Ereignishistorie ist der Beobachtungsdatensatz. Keines ersetzt die anderen.

Welche Felder machen eine Lineage-Spur reproduzierbar?

Beginnen Sie mit dem Ergebnis, nicht mit dem Diagramm. Schreiben Sie zuerst Einheit und Entscheidung auf und halten Sie dann die verbindenden Objekte fest:

1. Ausgabe: das Feld, die Tabelle, die Kennzahl oder das Entscheidungsobjekt.
2. Eingabe: jedes Quellobjekt mit Verantwortung sowie exakter Version oder Snapshot-Zeit.
3. Operation: Filter, Standardisierung, Join, Aggregation, Berechnung oder manuelle Änderung.
4. Schlüssel: Feld oder zusammengesetzter Schlüssel samt Eindeutigkeitsprüfung.
5. Zeit: Ereignis-, Erfassungs-, Verarbeitungszeit und Reporting-Stichtag.
6. Prüfung: Test für erwartete Zeilenanzahl, Datensatzebene oder Grenze.
7. Nutzung: Dashboard, Bericht, Modell oder Entscheidung, die die Ausgabe verwendet.
8. Ausnahme: verspätete Daten, fehlgeschlagener Test, geänderte Regel, manuelles Override oder offene Abweichung.

Auch die Ausgabe braucht eine Version. Eine aktuelle Tabelle ist nicht stabil, nur weil ihr Name gleich bleibt. Ein zeitgestempelter Snapshot ist mit einem anderen Snapshot vergleichbar. Ein Ereignisstrom beantwortet möglicherweise eine andere Frage über das, was dazwischen geschah.

Wie sieht ein Lineage-Graph aus?

Die folgenden sechs Zeilen sind synthetisch. Sie zeigen die Detailtiefe für die Rekonstruktion eines kleinen Ergebnisses. Sie sind keine Warehouse-, Kunden- oder Unternehmensdaten.

Die Tabelle behauptet nicht, dass die Ausgabe richtig ist. Sie macht die Aussage prüfbar. L-02 wird gehalten, weil die erwartete Schlüsselbeziehung noch nicht bestanden ist. L-05 zeichnet eine manuelle Operation auf, statt sie in einem Notizbuch zu verstecken. L-06 zeigt, dass eine verspätete Eingabe ein bereits ausgegebenes Ergebnis ungültig machen und die Entscheidung erneut öffnen kann.

Wo kann Data Lineage scheitern?

Die häufigen Brüche sind strukturell:

• Snapshot-Austausch: Eine aktuelle Tabelle wird ohne gemeinsamen Stichtag mit einer früheren Ereignismenge verglichen.
• Join-Vervielfachung: Ein Viele-zu-viele-Join erzeugt zusätzliche Zeilen, während der Nenner unverändert bleibt.
• Schlüssel-Drift: Umbenannte Konten, Produkte oder Gebiete brechen den Pfad zwischen Versionen.
• Verspätete Daten: Nachlieferung ändert ein historisches Ergebnis, ohne Ungültigkeit oder Neuausgabe zu vermerken.
• Verborgene manuelle Arbeit: Eine Tabellenkorrektur ändert die Ausgabe ohne Verantwortung, Regel oder Version.
• Unbezeichneter Filter: Abfrage oder Dashboard filtert, ohne dass die Kennzahldefinition es nennt.

Ein Lineage-Graph kann jeden Bruch sichtbar machen. Er kann keine schlechte Quelle reparieren, entscheiden, ob ein Proxy das Zielkonstrukt misst, oder ein beschreibendes Ergebnis in einen Kausaleffekt verwandeln.

Wie prüft ein Team ein gemeldetes Ergebnis?

Bitten Sie die verantwortliche Person, ein Ergebnis rückwärts abzuspielen:

1. Ausgabe, Einheit, Reporting-Stichtag und Entscheidung benennen.
2. Jede Eingabe auf eine gehaltene Version oder einen zeitgestempelten Snapshot zurückführen.
3. Jede Operation in Reihenfolge aufschreiben, einschließlich manueller Änderungen und Ausschlüsse.
4. Jeden Join-Schlüssel auf erwartete Ebene und Kardinalität prüfen.
5. Eingabe- und Ausgabeanzahlen, Summen und Grenzänderungen abstimmen.
6. Verspätete Daten, fehlgeschlagene Tests, ersetzte Versionen und offene Kanten markieren.
7. Ergebnis als reproduzierbar, gehalten, neu ausgegeben oder nicht rekonstruierbar einstufen.

Wenn der Pfad nicht abspielbar ist, begrenzen Sie das Ergebnis auf den rekonstruierbaren Teil. Wenn er abspielbar ist, halten Sie Quellenqualität, Messung, Kausalität und Transfer getrennt. Lineage beantwortet, wie ein Ergebnis erzeugt wurde. Sie beantwortet nicht, ob es wahr ist oder was es verursacht hat.