Lineage als Impact-Analysis-Produkt

Herausforderung

Lineage wird häufig als Graph-Demo eingeführt: Ein Team verbindet möglichst viele Systeme, öffnet eine bekannte Tabelle und zeigt beeindruckende Knoten und Kanten. Das sieht nach Transparenz aus, beantwortet aber noch keine belastbare Betriebsfrage. Wenn eine Warehouse-Spalte umbenannt wird, muss jemand wissen, welche dbt-Modelle, publizierten Tabellen, BI-Datasets, Reports und Geschäftsentscheidungen betroffen sind. Wenn ein KPI im Dashboard falsch ist, braucht das Incident-Team den Weg zurück zur Quelle, die letzte erfolgreiche Ausführung und erreichbare Owner. Ein schöner Graph allein liefert diese Sicherheit nicht.

Das Problem liegt selten nur in fehlenden Kanten. Unterschiedliche Systeme erzeugen Lineage mit unterschiedlicher Bedeutung und Granularität. Ein Warehouse kann Query-basierte Beziehungen beobachten. dbt deklariert Abhängigkeiten im Projektgraphen. Ein BI-Connector erkennt möglicherweise Dataset- und Dashboard-Beziehungen, aber keine einzelne Measure-Abhängigkeit. Manuelle Ergänzungen schließen fachliche Lücken, können jedoch veralten. Werden diese Kanten gleich behandelt, entsteht eine Scheingenauigkeit: Der Graph wirkt vollständig, obwohl seine Herkunft, Aktualität und Coverage unbekannt sind.

Auch die Consumer-Frage fehlt oft. Eine Plattformgruppe bewertet Erfolg anhand der Zahl ingestierter Entities oder Kanten. Change Owner und Incident Manager benötigen dagegen konkrete Antworten: Welche produktiven Outputs hängen von dieser Spalte ab? Welche kritischen Consumer nutzen sie? Welche Abhängigkeiten sind bestätigt, welche nur vermutet? Wo endet die automatisierte Sicht? Wer entscheidet bei einer Lücke? Ohne solche Fragen bleibt Lineage eine Navigationsfunktion und wird nicht zum Impact-Analysis-Produkt.

OpenMetadata kann Lineage aus Connectors, dbt-Artefakten, Pipelines und manueller Pflege zusammenführen. Das schafft eine gemeinsame Oberfläche, garantiert aber keine End-to-End-Vollständigkeit. Connectoren unterscheiden sich nach Version, System und unterstützten Facets. Berechtigungen, Query History, dynamisches SQL, gespeicherte Prozeduren, externe Exporte oder semantische BI-Logik können Lücken erzeugen. Reife Governance versteckt diese Lücken nicht, sondern macht sie als Teil der Evidenz sichtbar.

Ansatz

Lineage als betriebenes Impact-Analysis-Produkt für einen repräsentativen Pfad Warehouse → dbt → BI aufbauen. Der Pilotprojekt wird nicht an der Schönheit oder Größe des Graphen gemessen, sondern daran, ob benannte Change- und Incident-Fragen innerhalb einer vereinbarten Zeit mit nachvollziehbarer Evidenz beantwortet werden können.

Jede relevante Beziehung wird einer von drei Provenienzklassen zugeordnet:

1. Observed – beobachtet: Die Beziehung wurde aus Laufzeitverhalten abgeleitet, etwa aus Warehouse Query Logs oder Pipeline Runs.
2. Declared – deklariert: Die Beziehung stammt aus Code oder Konfiguration, etwa ref() in dbt, einem Orchestrator-DAG oder einer BI-Dataset-Definition.
3. Curated – kuratiert: Eine verantwortliche Person hat eine fachliche oder technisch nicht automatisch erfassbare Beziehung ergänzt und reviewed.

Keine Klasse ist pauschal überlegen. Beobachtete Lineage beweist Nutzung in einem bestimmten Zeitraum, kann aber selten ausgeführte Pfade übersehen. Deklarierte Lineage zeigt beabsichtigte Abhängigkeiten, auch wenn sie noch nicht gelaufen sind, kann aber toten Code enthalten. Kuratierte Lineage schließt wichtige fachliche Lücken, benötigt jedoch Owner, Begründung und Review-Datum. Für belastbare Impact Analysis müssen Nutzer Herkunft und Grenzen unterscheiden können.

Impact-Fragen definieren das Produkt

Der Pilotprojekt beginnt mit Fragen, nicht mit Connectoren. Gute Fragen haben einen Auslöser, einen Startpunkt, einen erwarteten Scope und eine handlungsorientierte Antwort. Beispiele für Change Management:

• Wenn warehouse.sales.order_amount Typ oder Semantik ändert, welche produktiven dbt-Modelle und BI-Assets müssen vor dem Release geprüft werden?
• Welche zertifizierten Data Products und Tier-1-Dashboards hängen direkt oder indirekt von einem Modell ab?
• Welche verantwortliche Person müssen eine geplante Breaking Change bestätigen?
• Gibt es Downstream-Abhängigkeiten außerhalb der automatisierten Coverage?
• Welche Tests und Trust Signals schützen den betroffenen Pfad?

Für Incident Management sind andere Fragen wichtig:

• Welche Dashboards und Nutzer können von einem fehlgeschlagenen Warehouse-Load betroffen sein?
• Wo im Pfad wurde zuletzt ein erfolgreicher Lauf oder Test beobachtet?
• Ist der fehlerhafte Wert bereits in ein BI-Extrakt oder einen Export gelangt?
• Welche alternative Quelle oder welcher Fallback steht bereit?
• Wer besitzt den Upstream-Fehler, wer die Transformation und wer die Nutzer-Kommunikation?

Das Team wählt für das Pilotprojekt zwei Change- und zwei Incident-Fragen. Für jede Frage wird eine Zielzeit festgelegt, beispielsweise zehn Minuten bis zu einer ersten belastbaren Impact-Liste. Dadurch wird messbar, ob die Lineage operativ hilft. „Der Graph ist vorhanden“ ist kein Abnahmekriterium.

Observed Lineage: tatsächliches Verhalten mit Zeitfenster

Observed Lineage entsteht aus ausgeführten Vorgängen. Warehouse Query Logs können zeigen, dass eine Zieltabelle aus bestimmten Quelltabellen gelesen wurde. Orchestrator-Runs zeigen, welche Tasks tatsächlich liefen. Manche Connectoren können aus Abfrageplänen oder Query History Tabellen- und teilweise Spaltenbeziehungen ableiten.

Diese Evidenz ist besonders nützlich für Incidents, weil sie tatsächliche Aktivität belegt. Sie benötigt jedoch ein Zeitfenster. Eine Beziehung, die in den letzten sieben Tagen nicht beobachtet wurde, kann trotzdem für einen Monatsabschluss kritisch sein. Umgekehrt kann eine einmalige Ad-hoc-Abfrage eine Kante erzeugen, die keine produktive Abhängigkeit darstellt. Deshalb sollte das Pilotprojekt mindestens zwischen Produktionsaktivität, Entwicklungsnutzung und explorativen Queries unterscheiden, soweit die Quelle dies erlaubt.

Observed Lineage hängt zudem von Retention und Berechtigungen ab. Wenn Query History nur sieben Tage verfügbar ist, kann ein monatlicher Pfad verschwinden. Wenn der Ingestion-Account System Views nicht lesen darf, bleibt der Graph unvollständig. Dynamisches SQL, temporäre Tabellen, Prozeduren und Cross-Account-Zugriffe können Parser oder Connector überfordern. Diese Einschränkungen gehören in das Coverage-Register, nicht in eine Fußnote.

Für jede beobachtete Kante sind Quelle, zuletzt beobachteter Zeitpunkt und Environment relevante Evidenz. Ohne diese Angaben wird aus „wurde genutzt“ schnell die falsche Aussage „ist eine aktuelle produktive Abhängigkeit“.

Declared Lineage: beabsichtigte Architektur aus Code

Declared Lineage kommt aus maschinenlesbaren Definitionen. dbt ist dafür besonders wertvoll: manifest.json enthält Nodes, Sources, Tests und Abhängigkeiten, die durch ref() und source() entstehen. Auch wenn ein Modell in einem Zeitraum nicht lief, bleibt seine beabsichtigte Position im Graph sichtbar. Orchestrator-DAGs und einige BI-Metadaten liefern weitere deklarierte Beziehungen.

Für Change Impact ist diese Sicht oft vollständiger als reine Query-Beobachtung. Eine geplante Änderung kann abhängige Modelle identifizieren, bevor der neue Code ausgeführt wurde. Gleichzeitig muss das Team zwischen Definition und Produktion unterscheiden. Ein deaktiviertes Modell, eine Entwicklungs-Branch oder ein nicht deploytes Manifest darf nicht denselben Status erhalten wie der aktive Produktionsgraph.

Versionierbarkeit ist deshalb zentral. Das Team sollte nachvollziehen können, welches dbt-Manifest, welcher Commit oder welches Deployment die sichtbare Abhängigkeit erzeugt hat. Bei einem Release-Vergleich ist nicht nur der aktuelle Graph relevant, sondern die Differenz: Welche Kanten sind neu, entfernt oder auf Spaltenebene verändert? OpenMetadata kann die Discovery-Oberfläche liefern; der CI/CD-Prozess bleibt der Ort, an dem Breaking Changes vor dem Deployment blockiert werden.

Declared Lineage ist nicht automatisch wahr. Makros, dynamische Relationsnamen oder externe Operationen können außerhalb des statisch erkennbaren Graphen liegen. Umgekehrt kann Code vorhanden sein, der in Produktion nie genutzt wird. Die Provenienzklasse sorgt dafür, dass Nutzer diese Evidenz richtig interpretieren.

Curated Lineage: bewusst geschlossene Lücken

Curated Lineage ist kein Versagen der Automatisierung. Sie ist notwendig, wenn fachliche Beziehungen oder technische Übergaben nicht maschinenlesbar vorliegen. Beispiele sind ein regulärer CSV-Export an einen Partner, eine manuelle Upload-Strecke, eine fachliche Ableitung zwischen KPIs, eine gespeicherte Prozedur ohne parsebare Lineage oder ein BI-Measure, dessen Abhängigkeit der Connector nicht extrahiert.

Eine kuratierte Kante braucht mehr als Start und Ziel. Dokumentiert werden sollten:

• Grund und fachliche Bedeutung der Beziehung,
• verantwortlicher verantwortliche Person,
• Quelle der Bestätigung, etwa Ticket, Code Review oder Prozessdokument,
• Gültigkeitsbereich und Environment,
• Erstellungs- und letztes Review-Datum,
• Trigger für Revalidierung oder Entfernung.

Ohne Review-Cadence wird manuelle Lineage schnell zur historischen Behauptung. Kuratierte Kanten sollten daher gezielt auf kritische Lücken beschränkt bleiben. Wenn viele ähnliche Kanten manuell gepflegt werden, ist das ein Signal, Connector-Konfiguration, Parsing oder Prozessintegration zu verbessern.

Den Pfad Warehouse → dbt → BI beweisen

Der Pilotprojekt wählt einen produktiven Consumer-Pfad, beispielsweise:

warehouse.raw_crm.opportunity → dbt.stg_crm__opportunity → dbt.fct_bookings → analytics.bookings_daily → BI Sales Dataset → Daily Bookings Dashboard.

Die Schreibweise ist weniger wichtig als die eindeutige Identität jeder Entity. Service, Datenbank, Schema, Environment und FQN müssen korrekt aufgelöst werden. Ein häufiger Fehler sind doppelte Entities, weil dbt und Warehouse dieselbe Relation mit unterschiedlichen Service-Namen oder Casing-Regeln ingestieren. Dann endet die dbt-Lineage an einem scheinbar anderen Objekt als die Warehouse-Lineage. Der Graph sieht fast richtig aus, ist für Impact Analysis aber unterbrochen.

Zuerst wird Warehouse-Ingestion stabilisiert: Tabellen, Views und – sofern unterstützt und erforderlich – Query-basierte Lineage. Danach wird dbt-Metadaten-Ingestion mit dem aktiven Produktionsmanifest und Run-Artefakten verbunden. Schließlich wird der BI-Service ingestiert. Bei jedem Übergang prüft das Team Identitätsauflösung, Richtung, Granularität und Zeitstempel.

Die Mindestabnahme ist ein lückenlos navigierbarer Pfad auf Entity-Ebene. Für mindestens eine kritische Spalte sollte zusätzlich Column-Level Lineage nachgewiesen oder die fehlende Coverage explizit dokumentiert werden. BI-Lineage endet je nach Connector möglicherweise am Dataset, Datenmodell, Workbook oder Dashboard. Wenn Measure- oder Visual-Level Lineage nicht verfügbar ist, darf der Graph diese Präzision nicht suggerieren.

Column-Level Lineage mit ehrlicher Granularität

Change-Fragen beginnen oft bei einer Spalte. Tabellen-Lineage kann alle nachgelagerten Assets als potenziell betroffen markieren, erzeugt aber eine breite Impact-Liste. Column-Level Lineage reduziert diese Liste, wenn Transformationen zuverlässig geparst oder aus dbt-Artefakten abgeleitet werden können.

Auch hier unterscheiden sich Beziehungen. Eine direkte Projektion ist relativ eindeutig. Ein berechnetes Feld kann mehrere Quellspalten kombinieren. Ein Filter beeinflusst Zeilen, ohne dass die gefilterte Spalte im Output erscheint. Aggregationen, Joins und Window Functions erzeugen semantische Abhängigkeiten, die ein einfacher Spaltenpfeil nur unvollständig beschreibt. BI-Measures können nochmals eine eigene Ausdruckssprache verwenden.

Das Produkt sollte daher nicht versprechen, jede semantische Auswirkung automatisch zu erkennen. Für kritische Changes gilt eine konservative Regel: Wenn Column-Level Coverage fehlt, wird Tabellen-Level Impact verwendet und die Liste als „potenziell betroffen“ gekennzeichnet. Kuratierte Ergänzungen können den kritischen Pfad präzisieren. Falsche Sicherheit durch eine zu enge Liste ist riskanter als eine transparent breitere Analyse.

Coverage als sichtbare Betriebsevidenz

„Lineage Coverage 80 Prozent“ ist ohne Nenner bedeutungslos. Coverage muss an den Pilotpfad und seine Fragen gebunden sein. Ein kleines Register kann pro Übergang festhalten:

• erwartete Beziehung und kritische Entities,
• vorhandene Provenienzklasse,
• verfügbare Granularität: Service, Tabelle, Spalte, Dataset oder Dashboard,
• letzte erfolgreiche Ingestion beziehungsweise Beobachtung,
• bekannte technische oder fachliche Lücke,
• Owner und geplanter Umgang mit der Lücke.

Lücken erhalten einen Status: akzeptiert, kuratiert überbrückt, in Behebung oder blockierend. Ein akzeptiertes Gap braucht eine Begründung und einen Fallback. Wenn beispielsweise der BI-Connector nur Dataset-Level Lineage liefert, kann der Dashboard-Owner bei kritischen Changes eine manuelle Impact-Prüfung durchführen. Diese Aktivität gehört in den Change-Prozess, bis bessere Metadaten verfügbar sind.

Die Coverage wird nach Connector-Upgrades, Berechtigungsänderungen, neuen Services und relevanten Schema-Changes erneut geprüft. Ein einmal vollständig getesteter Graph bleibt nicht automatisch vollständig.

Change Impact als wiederholbarer Ablauf

Bei einer geplanten Änderung startet der Ablauf an der betroffenen Entity oder Spalte. Das Team ermittelt Downstream-Assets, filtert nach produktivem Environment und priorisiert Data Products, Zertifizierungen, Tiers, Nutzung und benannte Consumer. Danach wird Provenienz geprüft: Ist die kritische Kante observed, declared oder curated? Gibt es unbekannte Übergänge oder veraltete Ingestion?

Die Impact-Liste wird nicht ungeprüft an alle Owner gesendet. Ein Change Owner klassifiziert direkte, potenzielle und ausgeschlossene Auswirkungen. Fachliche Owner bestätigen, ob Semantik oder Vertrag verletzt werden. Technical Custodians planen Anpassungen und Tests. Das Ergebnis fließt in Release-Freigabe und Kommunikation.

OpenMetadata unterstützt Discovery und Kontext. Das tatsächliche Gate – beispielsweise ein Contract Check in CI oder eine verpflichtende Freigabe – muss im Delivery-Prozess implementiert sein. Die Lineage liefert die Evidenz, auf deren Grundlage das Gate entscheidet.

Incident Impact braucht Run-Evidenz

Bei einem Incident reicht statische Lineage nicht. Das Team muss wissen, ob der fehlerhafte Pfad im relevanten Zeitfenster lief. Ein Warehouse-Load kann fehlgeschlagen sein, während ein Dashboard noch einen älteren, korrekten Extrakt zeigt. Umgekehrt kann eine fehlerhafte Transformation erfolgreich gelaufen und bereits publiziert worden sein.

Deshalb kombiniert Incident Analysis den Graphen mit Freshness, Pipeline-Status, dbt Run Results, Testresultaten und BI-Refresh-Informationen, soweit verfügbar. Die Antwort lautet dann nicht nur „Dashboard X hängt von Tabelle Y ab“, sondern beispielsweise: „Der fehlerhafte Lauf um 06:42 speiste fct_bookings; das Dataset refreshte um 07:05; Dashboard X ist seitdem potenziell betroffen.“

Wenn Run-Evidenz fehlt, wird die Auswirkung als unbekannt oder potenziell markiert. Das ist operativ wertvoller als ein unbegründetes Entwarnen. Die Lücke wird nach dem Incident als Verbesserungsmaßnahme aufgenommen.

Lineage-Gaps dokumentieren statt kaschieren

Jedas Pilotprojekt findet Lücken. Typische Ursachen sind nicht unterstützte Connector-Facets, fehlende Berechtigungen, kurze Query-History, dynamisches SQL, externe Dateien, manuelle Prozesse, unterschiedliche Entity-Identitäten oder nicht ingestierte BI-Semantik. Die richtige Reaktion ist nicht, den Graphen durch unbelegte Pfeile vollständig aussehen zu lassen.

Ein Gap Record enthält betroffenen Übergang, Ursache, Impact-Fragen, Risiko, aktuellen Fallback, Owner und Zieldatum. Bei einer manuellen Überbrückung wird die Kante als curated gekennzeichnet. Ist die Lücke blockierend, darf die zugehörige Impact-Frage im Pilotprojekt nicht als bestanden gelten.

Dieses Register ist zugleich Backlog und Vertrauensgrenze. Nutzer sehen, wo sie sich auf die Lineage verlassen können und wo zusätzliche Prüfung nötig bleibt.

Produktbetrieb und Erfolgskriterien

Lineage benötigt Owner für Connectoren, Entity-Auflösung, Coverage und Consumer-Fragen. Ingestion-Fehler müssen überwacht, Credentials erneuert und Änderungen an Services geprüft werden. Ein Graph ohne aktuelle Ingestion altert unsichtbar; deshalb gehören letzter erfolgreicher Lauf und erwartete Cadence zur Betriebsevidenz.

Geeignete Erfolgsmetriken sind die Zeit bis zur ersten Impact-Liste, Anteil der Pilotfragen mit belastbarer Antwort, Zahl unbekannter Übergänge, Aktualität kritischer Kanten und Anteil der Changes, bei denen Lineage vor dem Release genutzt wurde. Die absolute Zahl der Kanten ist nur eine technische Beobachtung und kein Business Outcome.

Nach mehreren Changes und mindestens einem simulierten oder realen Incident entscheidet das Team über Skalierung. Der nächste Pfad wird gewählt, weil er eine priorisierte Betriebsfrage unterstützt, nicht weil ein weiterer Connector leicht verfügbar ist.

Hilfe beim Umsetzen

Startet mit einem konkreten Change, etwa: „order_amount wechselt von Integer zu Decimal und erhält eine neue Netto-Semantik.“ Zeichnet den erwarteten Warehouse→dbt→BI-Pfad zunächst außerhalb des Tools und benennt für jeden Übergang die wahrscheinliche Evidenzquelle. Konfiguriert danach die Workflows mit dem OpenMetadata-Ingestions-Generator und prüft in den OpenMetadata Connector Docs, welche Lineage-Facets der konkrete Connector und seine Version tatsächlich unterstützen.

Führt zwei Smoke Tests durch. Beim Change-Test startet ihr an der Spalte und erzeugt eine priorisierte Downstream-Liste samt Ownern und Coverage-Hinweisen. Beim Incident-Test simuliert ihr einen fehlgeschlagenen oder fehlerhaften Lauf und kombiniert Lineage mit Run-, Test- und Freshness-Evidenz. Messt die Zeit bis zu einer handlungsfähigen Antwort.

Dokumentiert jeden fehlenden Übergang sofort im Coverage-Register. Ergänzt kritische Lücken nur mit belegter, als curated gekennzeichneter Lineage. Ein Pilotprojekt ist nicht schlechter, weil er Grenzen zeigt; er ist gefährlich, wenn er unbekannte Grenzen als Vollständigkeit verkauft.

Checkliste

Vor der Skalierung sollte folgende Evidenz vorliegen:

• Zwei konkrete Change- und zwei Incident-Fragen sind mit Zielzeiten dokumentiert.
• Ein repräsentativer Produktionspfad Warehouse→dbt→BI ist eindeutig abgegrenzt.
• Services, FQNs, Environments und Entity-Identitäten sind konsistent aufgelöst.
• Der Pfad ist mindestens auf Entity-Ebene lückenlos oder jede Lücke ist dokumentiert.
• Für eine kritische Spalte ist Column-Level Lineage nachgewiesen oder als Gap markiert.
• Kanten lassen sich als observed, declared oder curated interpretieren.
• Observed Lineage enthält Quelle, Environment und relevantes Beobachtungszeitfenster.
• Declared Lineage ist einem aktiven Produktionsmanifest oder Deployment zuordenbar.
• Curated Lineage hat Begründung, verantwortliche Person, Evidenz und Review-Termin.
• Connector-Fähigkeiten und erforderliche Berechtigungen wurden gegen die Dokumentation geprüft.
• Ingestion-Cadence, letzter erfolgreicher Lauf und Fehlerweg sind sichtbar.
• Query-History- und Retention-Grenzen sind dokumentiert.
• BI-Granularität wird korrekt dargestellt; fehlende Kennzahl- oder Visual-Lineage wird nicht suggeriert.
• Das Coverage-Register benennt Status, Risiko, Owner und Fallback jedes Gaps.
• Die Change-Impact-Liste priorisiert kritische Produkte, Tiers, Nutzung und verantwortliche Person.
• Die Incident-Analyse kombiniert Lineage mit Runs, Tests und Freshness.
• Betriebsprüfpunkte und Freigaben sind im Delivery-Prozess verankert, nicht nur im Katalog beschrieben.
• Ein Smoke Test hat innerhalb der Zielzeit eine handlungsfähige Antwort geliefert.

Artefakt

Das zentrale Artefakt ist ein Lineage Coverage & Impact Record für den Pilotpfad. Es enthält:

• die vier priorisierten Impact-Fragen und Zielzeiten,
• den erwarteten Warehouse→dbt→BI-Pfad,
• pro Übergang Provenienzklasse, Granularität und autoritative Quelle,
• letzte erfolgreiche Ingestion oder Beobachtung,
• bekannte Gaps mit Risiko, Fallback, Owner und Zieldatum,
• Links zu relevanten Entities, Connector-Konfigurationen und Run-Evidenz,
• Ergebnisse der Change- und Incident-Smoke-Tests,
• Review-Cadence und Trigger für erneute Validierung.

Dieses Artefakt ist gleichzeitig Servicebeschreibung, Coverage-Grenze und Verbesserungsbacklog. Es verhindert, dass Nutzer einen vollständigen Graphen annehmen, wo nur Teil-Evidenz existiert.

Tools

• OpenMetadata-Ingestions-Generator — Lineage-fähige Connector-Configs (Warehouse, dbt, BI, Pipeline).
• OpenMetadata Connectors — welche Connectoren welche Lineage-Facets liefern.

Ressourcen

• OpenMetadata-Dokumentation
• OpenMetadata Lineage
• OpenMetadata dbt Ingestion
• OpenMetadata Connectors