Lineage, die Veränderungen erklärt

Begriffe vor dem Lesen

• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Lineage, Qualität, Klassifikation und Nutzungskontext.
• Definition — Fachliche Bedeutung eines Feldes, Begriffs oder einer Kennzahl, inklusive Umfang und verantwortliche Person.
• fachliche Ebene / Körnung — Die Einheit einer Aussage, zum Beispiel eine Bestellung, eine Position, ein Kunde oder ein Snapshot.
• Lineage — Nachvollziehbare Herkunft und Weitergabe von Daten über Quellen, Transformationen und Nutzung hinweg.
• Nachweis — Nachweis, welche Definition, Version, Quelle oder Regel eine Aussage trägt.

Ausgangslage

Der Graph zeigt CRM → sales_otc.fct_orders → Dashboard — eine Grain-Änderung an order_line bricht den Umsatz, und niemand sieht warum. Pfeile ohne Transformationssemantik erklären Konnektivität, nicht Konsequenzen.

Leitentscheidung

Modelliert Lineage als typisierte, versionierte Evidenz über den vollständigen Consumption Path. Jede relevante Edge benennt Source, Target, Process, Transformationsart, Environment, Version, Evidence Type und Gültigkeit. Impact Analysis traversiert diesen Graph rückwärts bzw. downstream und ergänzt technische Abhängigkeit um Business Criticality, Owner, Contract, Tests und Freigabestatus.

Lineage wird erst wertvoll, wenn sie Konsequenzen erklärt

Viele Metadatenplattformen können Pfeile zwischen Assets zeichnen.

Eine Source Table speist eine Transformation. Die Transformation erzeugt ein governed Dataset. Ein Semantic Model konsumiert dieses Dataset. Ein Dashboard und ein AI Feature hängen vom Semantic Model ab.

Der Graph kann vollständig aussehen und trotzdem nicht die Fragen beantworten, die bei Änderungen, Incidents oder Governance-Entscheidungen relevant sind:

• Welche konkreten Columns haben zum Target beigetragen?
• Wurde die Beziehung zur Laufzeit beobachtet, im Code deklariert oder manuell ergänzt?
• Hat eine Transformation den Wert erhalten, umbenannt, aggregiert, maskiert oder fachlich neu interpretiert?
• Dürfen Sensitivität, Verantwortung, Retention, Quality Rules oder Beschreibungen vererbt werden?
• Welche nachgelagerten Objekte sind technisch abhängig?
• Welche davon sind fachlich kritisch?
• Wo enthält die Lineage Lücken, unsichere Mappings oder ungelöste Konflikte?
• Welcher verantwortliche Person muss eine Änderung vor dem Deployment freigeben?

Eine schwache Implementierung behandelt jeden Pfeil gleich. Sie nimmt an, dass Konnektivität allein ausreicht, um Kontext zu vererben und Auswirkungen zu bewerten.

Diese Annahme ist unsicher.

Eine direkte Projektion von customer.email nach customer_email erhält wesentlich mehr Bedeutung als eine Aggregation wie COUNT(DISTINCT customer_id). Ein maskierter Wert kann weiterhin sensitiv sein, obwohl die ursprünglichen Zeichen nicht mehr sichtbar sind. Ein Hash kann Matching ermöglichen und gleichzeitig für Kommunikation ungeeignet sein. Ein Join kann mehrere Owner, Retention-Verpflichtungen und Quality Expectations zusammenführen. Ein semantischer KPI kann Filter und Ausschlüsse einführen, die in der physischen Source nicht existieren.

Lineage erklärt, wie Assets verbunden sind. Metadatenvererbung nutzt diese Verbindungen zusammen mit Transformationssemantik, Autorität und expliziten Regeln, um zu bestimmen, welcher Kontext übernommen werden darf.

Diese Trennung macht aus Lineage ein operatives Steuerungssystem statt eines Diagramms.

Lineage über den vollständigen Consumption Path modellieren

Lineage sollte nicht an der Warehouse Table enden.

Ein entscheidungsrelevantes Lineage-Modell verbindet den Weg vom operativen System bis zum finalen Consumer:

Unterschiedliche Fragen benötigen unterschiedliche Drill Levels.

System Lineage

System Lineage verbindet Plattformen und große Betriebsgrenzen:

Sie ist für Architektur, Verantwortung und den groben Incident Scope nützlich. Für Änderungen auf Feldebene ist sie nicht präzise genug.

Dataset- und Table-Lineage

Dataset Lineage identifiziert, welche gespeicherten oder logischen Datenbestände voneinander abhängen:

Diese Ebene unterstützt Deprecation Planning, Pipeline Troubleshooting und Data-Product-Verantwortung.

Column Lineage

Column Lineage identifiziert Input Columns, Expressions und Target Columns einer Ableitung:

Diese Ebene ist für Classification Propagation, die Bewertung von Quality Rules, Schema Change Analysis und AI Feature Traceability notwendig.

Process Lineage

Process Lineage repräsentiert den ausführbaren Schritt, der Daten erzeugt oder bewegt hat:

Der Process Node sollte Referenzen auf Code, Deployment, Betrieb Evidence und das verantwortliche Team behalten. Ohne Process Lineage kann der Graph zeigen, dass zwei Datasets verbunden sind, aber verbergen, wie die Verbindung implementiert wurde.

KPI- und Semantic-Lineage

Ein KPI ist nicht nur eine weitere Column.

Ein Measure kann verbinden:

• mehrere Source Measures;
• Dimensions und Relationships;
• Filter Context;
• Time Windows;
• Currency Conversion;
• Exclusions;
• Aggregation Behaviour;
• Restatement Rules.

Lineage sollte den KPI deshalb sowohl mit seinen physischen Inputs als auch mit seiner semantischen Definition verbinden.

Report- und API-Lineage

Reports, Dashboards, Extracts und APIs sind operative Consumer. Sie sollten als First-Class Assets modelliert werden, weil sie reale Abhängigkeiten, Service Commitments und User Impact erzeugen.

Ein Feld, das im Warehouse technisch ungenutzt wirkt, kann weiterhin in einem Export, API Contract oder einer Workbook Calculation enthalten sein.

AI Lineage

AI Lineage sollte verbinden:

Für AI-Nutzung muss Lineage zusätzlich Purpose, Time Window, Feature Derivation, Training Snapshot, Approval State und Permitted Use erhalten. Zu wissen, dass ein Model ein Dataset konsumiert hat, reicht weder für Reproducibility noch für Governance.

Beobachtete, deklarierte und kuratierte Lineage trennen

Lineage besitzt mehrere Evidenztypen. Sie sollten verbunden, aber nie stillschweigend zusammengezogen werden.

Observed Query Lineage

Observed Lineage wird aus ausgeführten Operationen abgeleitet:

• SQL Query History;
• Betrieb Events;
• Pipeline Runs;
• Read- und Write-Operationen;
• API Calls;
• Stream Producer- und Nutzer-Aktivität.

Ihre Stärke ist operative Evidenz. Sie beweist, dass eine Beziehung in einem bestimmten Environment und Time Window tatsächlich aufgetreten ist.

Ihre Grenzen sind:

• fehlende Historie nach Ablauf der Retention;
• unvollständiges Parsing von Dynamic SQL;
• versteckte Bewegung außerhalb überwachter Systeme;
• temporäre Queries, die nicht zur dauerhaften Architektur werden sollten;
• Betrieb Paths, die sich zwischen erfolgreichen und fehlgeschlagenen Ausführungen unterscheiden.

Observed Lineage sollte erhalten:

Declared Code Lineage

Declared Lineage wird aus implementierten Definitionen abgeleitet:

• Transformation Code;
• Model Manifests;
• Pipeline Specifications;
• Notebook Dependencies;
• semantisches Modell-Model Expressions;
• Infrastructure Configuration;
• Data Vereinbarungen.

Ihre Stärke ist Design Intent und Expression-Level-Kontext.

Ihre Grenzen sind:

• Code, der nie deployed wurde;
• Branches, die von Production abweichen;
• generierte Logik, die schwer zu parsen ist;
• Macros oder Stored Procedures, die Dependencies verbergen;
• Configuration, die nicht mehr dem Betrieb Behaviour entspricht.

Declared Lineage sollte eine Code Revision, Environment und Deployment State enthalten.

Manually Curated Lineage

Curated Lineage wird von einer Person ergänzt, wenn automatisierte Evidenz fehlt oder nicht ausreicht.

Sie kann repräsentieren:

• einen externen File Transfer;
• einen manuellen Spreadsheet-Prozess;
• ein fachliches Mapping;
• ein Legacy Interface;
• eine semantische Beziehung, die nicht parsebar ist;
• eine freigegebene Ausnahme;
• eine temporäre Migrationsbrücke.

Curated Lineage ist in vielen Enterprises notwendig. Sie wird gefährlich, wenn sie nicht von beobachteter Evidenz unterscheidbar ist.

Jede kuratierte Edge sollte enthalten:

Eine manuell behauptete Beziehung ohne Review sollte nicht dieselbe Confidence erhalten wie ein wiederholt beobachteter Production Path.

Lineage als typisierte, versionierte Evidenz behandeln

Eine Lineage Edge sollte mehr sein als:

Eine nutzbare Edge kann so repräsentiert werden:

Das konkrete Schema kann abweichen. Die benötigten Konzepte sollten es nicht.

Wichtige Attribute sind:

• Source- und Target-Identity;
• Relationship Type;
• Process oder Transformation;
• Expression oder Rule Reference;
• Nachweis Type;
• Environment;
• Validity Period;
• Observation Time;
• Confidence;
• Coverage Level;
• Review- und Approval State.

Versionierung ist wichtig, weil Impact Analysis zeitabhängig ist.

Ein Report kann letzten Monat von customer_status abhängig gewesen sein und heute customer_lifecycle_state verwenden. Eine Incident Investigation muss den Graph rekonstruieren, der zum Fehlerzeitpunkt existierte, nicht nur den aktuellen Graph.

Propagation benötigt Transformationssemantik

Lineage zeigt, dass ein Output von einem Input abhängt. Sie bestimmt nicht, welche Metadatenattribute nach der Transformation weiterhin gültig sind.

Eine Propagation Engine sollte mindestens die folgenden Transformation Types unterscheiden.

Direct Projection

Eine direkte Projektion erhält normalerweise:

• Description;
• Sensitivity;
• personenbezogene Daten Category;
• Unit;
• Allowed Usage;
• wertbezogene Quality Expectations.

Verantwortung und Retention können sich trotzdem ändern, wenn das Target zu einem anderen Data Product oder rechtlichen Processing Context gehört.

Rename

Ein Rename erhält normalerweise die Bedeutung des Wertes. Die Target Description sollte den neuen Namen berücksichtigen und kann kontextbezogene Formulierung benötigen. Classification und Value Semantics propagieren in der Regel.

Cast

Ein Cast erhält Identität nur, wenn die Konvertierung verlustfrei ist und die Interpretation nicht verändert.

Beispiele mit Review-Bedarf:

• Timestamp zu Date;
• Decimal zu Integer;
• Local Time zu UTC ohne Timezone Nachweis;
• Numeric Code zu formatiertem Text;
• Free Text, das in eine strukturierte Kategorie geparst wird.

Der Data Type verändert sich und Quality Rules müssen möglicherweise neu berechnet werden.

Concatenation

Der Output übernimmt Sensitivity aus beiden Inputs, aber die Description muss transformiert werden. Quality Rules der einzelnen Felder gelten nicht automatisch für den zusammengesetzten String.

Concatenation kann neue Sensitivität erzeugen. Die Kombination aus Postal Code, Birth Date und Gender kann das Re-Identification Risk erhöhen, obwohl jedes Attribut einzeln niedriger klassifiziert war.

Join

Ein Join kombiniert Row Populations und Business Contexts.

Propagation muss berücksichtigen:

• Join Keys;
• Cardinality;
• Unmatched Rows;
• Duplicate Creation;
• Target fachliche Ebene;
• Source Verantwortung;
• kombinierten Richtlinie Umfang.

Descriptions sollten nicht ungeprüft aus einer Input Table kopiert werden. Dataset-Level-Verantwortung gehört normalerweise zum Target Data Product, während Source Provenance sichtbar bleibt.

Union

Eine Union kombiniert Records mit nominell kompatiblen Strukturen.

Vor der Vererbung sollten geprüft werden:

• äquivalente Bedeutung;
• kompatible Units;
• kompatible Code Lists;
• abgestimmte Classifications;
• gemeinsame Retention Obligations;
• Definition der Target Grundgesamtheit.

Ein Feld status kann in zwei Systemen inkompatible Lifecycle Semantics enthalten. Dieselbe Column Position beweist nicht dieselbe Bedeutung.

Aggregation

Aggregation benötigt normalerweise:

• eine neue Description;
• neu berechnete Unit und fachliche Ebene;
• neue Quality Expectations;
• Target Verantwortung;
• Review von Sensitivity und Disclosure Risk.

Eine Raw-PII-Classification sollte nicht blind auf einen Count propagieren. Kleine Gruppen oder seltene Kategorien können trotzdem Confidentiality Risk erzeugen. Das Ergebnis kann eine andere Classification benötigen statt gar keiner.

Masking

Masking verändert Sichtbarkeit, nicht zwingend Sensitivität.

Der maskierte Wert kann weiterhin Personal Data sein. Er kann weiterhin Identification, Correlation oder Contact-Domain-Inference ermöglichen.

Propagation sollte unterscheiden:

• reversible Masking;
• partial Masking;
• Tokenization;
• irreversible Redaction;
• dynamic Presentation Masking.

Allowed Usage muss explizit bewertet werden.

Hashing

Hashing kann direkte Lesbarkeit reduzieren und Linkability erhalten.

Ein deterministischer Hash kann weiterhin Personal Data sein, wenn er über Records abgeglichen oder aus einem begrenzten Input Space neu berechnet werden kann.

Die Target Description muss erklären:

• Algorithm Class;
• Salt- oder Key-Handling;
• Determinism;
• Collision Expectations;
• vorgesehenen Matching Use;
• verbotene Reversal- oder Lookup-Nutzung.

Sensitivity darf nicht automatisch auf public oder anonymous herabgestuft werden.

Custom Calculation und Derivation

Eine Custom Expression kann ein vollständig neues Konzept erzeugen:

Output Description, Owner, Quality Rules und Allowed Use müssen für das abgeleitete Konzept definiert werden. Source Metadata ist unterstützende Provenance, aber keine vollständige Target Definition.

Transformationssemantik bestimmt die Auswirkung

Eine direkte Projektion oder verlustfreie Umbenennung bedroht primär Contracts, Referenzen und Consumer-Code. Ein Cast kann Werte abschneiden oder Zeitzonen verlieren. Ein Join kann Cardinality und Grain verändern. Eine Aggregation entfernt Detail, erzeugt aber neue Additivitäts- und Disclosure-Regeln. Ein Mapping kann denselben Datentyp behalten und trotzdem die fachliche Bedeutung brechen.

Deshalb benötigt jede Edge mindestens eine grobe Transformationsklasse: projects, renames, casts, filters, joins, unions, aggregates, maps, masks, imputes oder derives. Nicht parsebare dynamische Logik bleibt unresolved; sie wird nicht als sichere direkte Abhängigkeit dargestellt. Ein Link auf Expression, Code Revision oder Contract liefert die prüfbare Detailtiefe.

Lineage für Impact Analysis nutzen

Impact Analysis ist Reverse Graph Traversal, ergänzt um Business Context.

Ausgangspunkt ist eine Proposed Change:

Danach werden Downstream Dependencies traversiert.

Ein praktikabler Workflow ist:

Detect Change

Changes können entstehen durch:

• Schema Comparison;
• Code Pull Request;
• Vereinbarung Update;
• semantisches Modell-Model Revision;
• Richtlinie Change;
• Source-System Release;
• Deprecation Request.

Das Change Object sollte beschreiben, was sich wo, wann und warum verändert.

Traverse Dependents

Der Lineage Graph wird traversiert über:

• Transformation Models;
• Tests;
• Data Products;
• semantisches Modell Measures;
• Dashboards;
• Exports;
• APIs;
• KI Features;
• Richtlinien;
• Documentation;
• Quality Rules.

Traversal sollte Environment und Version berücksichtigen. Development-only Dependencies dürfen nicht mit Production Impact vermischt werden.

Technical Impact klassifizieren

Technical Impact umfasst:

• Compilation Failure;
• Missing Field;
• Changed Data Type;
• Changed fachliche Ebene;
• Broken Join;
• Failed Quality Test;
• API Vereinbarung Violation;
• Model Feature Mismatch;
• Richtlinie-Binding Failure.

Business Criticality klassifizieren

Business Criticality umfasst:

• Regulatory Reporting;
• Executive KPI;
• Customer-Facing Service;
• Financial Close;
• Operational Decision;
• Automated Action;
• Model Risk;
• Contractual Export;
• Internal Convenience.

Eine technisch direkte Dependency kann geringe Criticality besitzen. Eine indirekte semantische Dependency kann hochkritisch sein.

Owner benachrichtigen

Notifications sollten an die Owner der betroffenen Assets geroutet werden, nicht an eine generische Distribution List.

Jede Notification sollte enthalten:

• Proposed Change;
• affected Object;
• Relationship Path;
• Impact Classification;
• Required Action;
• Deadline;
• Nachweis Link;
• Approval- oder Block-Status.

Testen und entscheiden

Tests können umfassen:

• Compile- und Deployment Validation;
• Schema Compatibility;
• Data-Quality Regression;
• semantisches Modell Kennzahl Comparison;
• Report Rendering;
• API Vereinbarung Tests;
• KI Feature- und Evaluation Checks;
• Richtlinie Durchsetzung Checks.

Die Entscheidung sollte lauten:

Evidenz und Approver sollten erhalten bleiben.

Lineage bei Incidents verwenden

Lineage ist nach einem Fehler ebenso wertvoll.

Angenommen, ein Source-System Release ändert customer_status von:

zu:

Die Pipeline lädt weiterhin, weil der Field Type Text bleibt. Der technische Job ist erfolgreich, aber das semantische Mapping erkennt die neuen Werte nicht.

Ein Lineage-fähiger Incident Workflow kann:

1. das erste veränderte Asset und den Zeitpunkt lokalisieren;
2. die Transformation identifizieren, die die alten Codes erwartet;
3. Downstream Data Products und Semantic Measures finden;
4. Dashboards, Exports und AI Features identifizieren, die betroffene Daten konsumiert haben;
5. das betroffene Time Window schätzen;
6. accountable Owner benachrichtigen;
7. betroffene Outputs pausieren oder kennzeichnen;
8. korrigierte Transformations erneut ausführen;
9. Recovery Evidence dokumentieren.

Ohne Lineage untersucht jedes Team sein eigenes System und rekonstruiert den Path manuell. Das verlängert Recovery Time und lässt den Scope unsicher.

Incident Lineage sollte zeitbezogen sein. Der aktuelle Graph kann sich von dem Graph unterscheiden, der den fehlerhaften Output erzeugt hat.

Hilfe bei der Entscheidung

Table-Level-Lineage reicht für grobe Deprecation und Betriebswege. Column- und Expression-Level-Lineage ist erforderlich, sobald Field Removal, Klassifikation, Unit, Grain, KPI-Logik oder AI Features betroffen sind. Consumer-Level-Lineage wird Pflicht, wenn Reports, APIs, Exporte oder Modelle reale Commitments erzeugen.

Priorisiert nicht nach Anzahl der Edges, sondern nach Konsequenz. Ein selten genutzter regulatorischer Export kann kritischer sein als hundert explorative Queries. Wenn Coverage oder Confidence fehlen, zeigt die Analyse eine Lücke mit Owner und Review-Bedarf statt eine scheinbar vollständige Antwort.

Checkliste

• Reicht der Graph vom Source System bis zum tatsächlichen Nutzer?
• Sind Dataset-, Column-, Process-, semantisches Modell-, Report-, API- und KI-Assets unterscheidbar?
• Trägt jede kritische Edge Transformationsart, Environment und Version?
• Sind observed, declared und curated Nachweis getrennt?
• Werden Parser-Lücken und Dynamic SQL sichtbar markiert?
• Trennt Impact Analysis technische Bruchart und Business Criticality?
• Werden indirekte semantische Abhängigkeiten erfasst?
• Erreichen Notifications die accountable verantwortliche Person der betroffenen Assets?
• Existieren passende Vereinbarung-, DQ-, semantisches Modell- und Nutzer-Tests?
• Bleiben Entscheidung, Approver und verwendeter Graph-Snapshot erhalten?

Artefakt

Das zentrale Artefakt ist ein Change Impact Record. Er enthält Change-ID, Source Asset und Version, Änderungsart, erwartetes Effective Date, traversierte Pfade, betroffene Target-Versionen, Transformationssemantik, Coverage, Confidence, technische Bruchart, Business Criticality, Owner, erforderliche Tests, Migrationsplan, Entscheidung und Evidence Links.

Ein kompakter Record ist wertvoller als ein Screenshot des Graphen. Er friert die für die Entscheidung verwendete Evidenz ein und kann später erklären, warum eine Änderung freigegeben, blockiert oder mit Migration akzeptiert wurde.

Tools

• Schema YML Editor — Model-, Column-, Vereinbarung- und meta-Referenzen nahe am Code pflegen.
• Metadata Export Generator — Impact Umfang und Handoff portabel exportieren.
• OpenMetadata-Ingestions-Generator — technische und dbt-Lineage entlang des Pfads konfigurieren.
• dbt DQ Rules Generator — Regression Rules für betroffene Inputs und Outputs definieren.