Data Lineage mit dbt: der vollständige Leitfaden

Data Lineage ist die dokumentierte Aufzeichnung darüber, wie Daten sich bewegen, sich wandeln und von ihrem Ursprung bis zu ihrem Ziel fließen: welche Quellen welche Modelle speisen, welche Modelle welche Dashboards speisen und welche Spalten sich aus welchen vorgelagerten Feldern ableiten. Eine gute Lineage beantwortet die Fragen, auf die es ankommt, wenn etwas schiefgeht: „Woher kommt diese Zahl?“ und „Wenn ich dieses Modell ändere, was geht dann kaputt?“

Was ist Data Lineage?

Data Lineage arbeitet auf mehreren Ebenen der Granularität, und jede beantwortet andere Fragen:

• Lineage auf Tabellenebene (Ebene des Datensatzes): „Welche Tabellen werden genutzt, um fct_revenue zu bauen?“ Das ist es, was der DAG von dbt von Haus aus zeigt.
• Lineage auf Spaltenebene: „Die Spalte revenue in fct_revenue, aus welchen Quellspalten speist sie sich?“ Das verlangt, die Ausdrücke im SQL zu parsen.
• Lineage auf Ebene der Jobs: „Welcher Lauf der Pipeline hat diese Tabelle erzeugt, und wann?“ Das erfassen Werkzeuge für Orchestrierung und Überwachung.
• Lineage auf fachlicher Ebene: „Welche Kennzahl in welchem Dashboard hängt von welchem Datenbestand ab?“ Das verbindet die technische Lineage mit der Wirkung im Geschäft.

dbt deckt die Lineage auf Tabellenebene von Haus aus ab und liefert das Fundament an Metadaten für die übrigen Ebenen. Welche Ebene Sie brauchen, entscheidet darüber, wie weit Sie über die eingebauten Fähigkeiten von dbt hinausgehen müssen.

Wie dbt die Lineage automatisch erzeugt

Die Lineage von dbt wird nicht von Hand gepflegt, sie wird aus dem Code berechnet. Wenn Sie {{ ref('stg_orders') }} in eine Modelldatei schreiben, tun Sie zweierlei zugleich:

1. Sie sagen dbt, dass es diesen Ausdruck zur Laufzeit durch den korrekten, schemaqualifizierten Tabellennamen ersetzen soll.
2. Sie erklären eine Abhängigkeit: Das aktuelle Modell kann nicht gebaut werden, bevor stg_orders gebaut ist.

dbt sammelt all diese erklärten Abhängigkeiten über jede Modelldatei hinweg und übersetzt sie in den DAG. Der DAG wird in dem Artefakt manifest.json serialisiert, das dbt compile und jedes dbt run erzeugen. Damit ist die Lineage immer im Gleichstand mit dem Code: Sie können kein Modell haben, das eine Tabelle nutzt, ohne dass diese Abhängigkeit im DAG auftaucht.

ref() erzeugt Kanten von Modell zu Modell

-- models/marts/fct_orders.sql
-- This single file declares two upstream dependencies
select
    o.order_id,
    o.amount,
    c.country
from {{ ref('stg_orders') }}      as o   -- edge: fct_orders → stg_orders
join {{ ref('stg_customers') }}   as c   -- edge: fct_orders → stg_customers
  using (customer_id)

source() erzeugt Kanten von der Quelle zum Modell

-- models/staging/stg_orders.sql
-- Declares the lineage edge from the raw source table
select
    order_id,
    customer_id,
    status,
    amount_cents / 100.0 as amount
from {{ source('raw', 'orders') }}  -- edge: stg_orders → raw.orders

Zusammengenommen erzeugen diese Erklärungen eine Kette der Lineage: raw.orders → stg_orders → fct_orders. dbt verfolgt diese Kette automatisch über alle Modelle des Projekts hinweg.

Der dbt DAG

Der DAG (gerichteter azyklischer Graph) ist die zentrale Datenstruktur, die dbt aus allen Erklärungen von ref() und source() berechnet. Er ist „gerichtet“, weil Abhängigkeiten eine Richtung haben (Eltern → Kind, vorgelagert → nachgelagert), und „azyklisch“, weil zirkuläre Abhängigkeiten nicht erlaubt sind; bei einem Zyklus bricht dbt mit einem Fehler ab.

Der DAG treibt nicht nur die Darstellung der Lineage, sondern auch die Reihenfolge der Ausführung (topologische Sortierung), das gezielte Neubauen (dbt run --select +fct_orders baut das Modell und alle seine Vorfahren) und die Analyse der Auswirkungen (welche nachgelagerten Modelle eine Änderung an einem vorgelagerten Modell trifft).

raw.orders ──────► stg_orders ─────────────────────► fct_orders ──► rpt_monthly_revenue
                                                           ▲
raw.customers ──► stg_customers ──► int_customers_ltv ──┤
                                                           │
raw.products ───► stg_products ──────────────────────────┘

Die Docs-Site von dbt: die Lineage interaktiv dargestellt

Der Befehl dbt docs generate erzeugt eine statische Website mit der Dokumentation, die für jeden Knoten des Projekts einen interaktiven Graphen der Lineage enthält. dbt docs serve startet einen lokalen Server, auf dem Sie:

• jedes Modell, jede Quelle und jede Spalte nach Namen suchen können,
• die Beschreibung, die Definitionen der Spalten und die Konfiguration der Tests je Modell lesen können,
• in den Graphen der Lineage klicken können, um den DAG rund um einen ausgewählten Knoten darzustellen, mit den vorgelagerten Quellen ebenso wie mit den nachgelagerten Abhängigen,
• die Sicht auf die Lineage filtern können, auf den ausgewählten Knoten allein, auf alle Vorfahren, auf alle Nachfahren oder auf den ganzen Graphen.

Die Docs-Site lässt sich als statische Website ausrollen (Netlify, S3, GitHub Pages) und mit der ganzen Organisation teilen. Damit bekommen Data Consumer einen Zugang zu Lineage und Dokumentation in Selbstbedienung, ohne selbst Zugriff auf das dbt-Projekt zu brauchen.

Lineage auf Spaltenebene in dbt

Die eingebaute Lineage von dbt liegt auf der Ebene der Tabellen und Modelle. Sie sagt Ihnen, dass fct_revenue von stg_orders abhängt, aber nicht, welche Spalten von fct_revenue sich aus welchen Spalten von stg_orders ableiten. Eine Lineage auf Spaltenebene verlangt, die Ausdrücke im SQL SELECT zu parsen.

Lineage auf Spaltenebene nativ in dbt Cloud

dbt Cloud, der verwaltete Dienst, hat in seiner Oberfläche Explorer eine eingebaute Lineage auf Spaltenebene eingeführt. Sie nutzt die statische Analyse des SQL, um die SELECT-Ausdrücke zu parsen und zu verfolgen, wie einzelne Spalten zwischen Modellen fließen, ohne dass zusätzliche Pakete nötig wären. Stand 2025 bis 2026 steht sie für die Adapter von Snowflake, BigQuery, Databricks und Redshift zur Verfügung.

Der Weg über das Parsen von SQL

Werkzeuge, die eine Lineage auf Spaltenebene umsetzen, parsen das kompilierte SQL und erkennen, woraus sich eine Spalte ableitet:

• Direkte Referenzen: select order_id from stg_orders → fct.order_id leitet sich aus stg_orders.order_id ab.
• Umbenannte Spalten: select order_id as id from stg_orders → fct.id leitet sich aus stg_orders.order_id ab.
• Ausdrücke: select amount_cents / 100.0 as amount → stg.amount leitet sich aus raw.amount_cents ab.
• Aggregationen: select sum(amount) as revenue → fct.revenue leitet sich aus allen Zeilen der Quellspalte amount ab.

Eine Lineage auf Spaltenebene ist für die Analyse der Auswirkungen deutlich wertvoller (welche Data Consumer trifft es, wenn sich eine Quellspalte ändert?) und für die regulatorische Compliance (woher genau kommt dieses personenbezogene Datenfeld?).

Die Anbindung von OpenLineage an dbt

OpenLineage ist ein offener Standard für Metadaten der Lineage: eine herstellerneutrale Spezifikation dafür, wie die Jobs einer Pipeline Events zur Lineage aussenden (Job gestartet, Datensatz gelesen, Datensatz geschrieben, Job beendet). Damit lässt sich die Lineage aus vielen verschiedenen Werkzeugen (Spark, Airflow, dbt, Flink) in einem einzigen, einheitlichen Graphen sammeln.

Der Adapter dbt-openlineage

Das Paket dbt-openlineage sendet während der Läufe von dbt run und dbt test Events im Format von OpenLineage. Für jeden Lauf eines Modells sendet es ein START-Event (der Job beginnt, die eingehenden Datensätze stehen fest), ein COMPLETE-Event (der Job endet, der ausgehende Datensatz steht fest, dazu die Facette mit der Zeilenzahl und die Facette mit dem Schema) und ein FAIL-Event, wenn das Modell mit einem Fehler abbricht.

# Install
pip install openlineage-dbt

# Run dbt with OpenLineage enabled
OPENLINEAGE_URL=http://marquez:5000 dbt run

Die Events gehen an ein Backend, das OpenLineage versteht: an Marquez (die quelloffene Referenzumsetzung), an Apache Atlas oder an Plattformen für Unternehmen, die den Standard unterstützen, darunter Dawiso. Das ermöglicht eine Lineage über Werkzeuggrenzen hinweg: Derselbe Graph, der die Abhängigkeiten der dbt-Modelle zeigt, lässt sich so erweitern, dass er auch zeigt, dass raw.orders von einem Sync-Job in Airbyte geschrieben wurde, der von einem DAG in Airflow angestoßen wurde und nachgelagert von einer Arbeitsmappe in Tableau genutzt wird, alles in einer einzigen Sicht.

Die Facetten von OpenLineage

Die Events von OpenLineage tragen typisierte „Facetten“ an Metadaten, die die Lineage über eine bloße Liste von Kanten hinaus anreichern:

• Facette Schema: Namen und Typen der Spalten des Datensatzes zum Zeitpunkt des Laufs.
• Facette DataQualityMetrics: Zeilenzahl, Zahl der NULL-Werte, Ergebnisse der Zusicherungen.
• Facette ColumnLineage: die Kanten der Ableitung von Spalte zu Spalte, sofern der Sender sie unterstützt.
• Facette SourceCode: das kompilierte SQL des dbt-Modells.

Exposures: die nachgelagerten Data Consumer dokumentieren

Die Exposures von dbt erweitern den Graphen der Lineage über die Schicht der Transformation hinaus auf die Werkzeuge und Prozesse, die dbt-Modelle nutzen. Ein Exposure ist eine Erklärung in YAML über ein nachgelagertes Artefakt, etwa ein BI-Dashboard, ein Notebook aus der Data Science, eine operative Anwendung oder einen Job für Reverse ETL, samt seiner Abhängigkeiten von bestimmten dbt-Modellen.

# models/exposures.yml
version: 2

exposures:
  - name: finance_monthly_dashboard
    label: "Finance Monthly Dashboard"
    type: dashboard
    maturity: high
    url: https://company.tableau.com/views/FinanceMonthly
    description: >
      Primary finance dashboard showing monthly P&L, revenue by region,
      and order metrics. Used in board-level reporting.
    owner:
      name: Finance Analytics Team
      email: finance-analytics@company.com
    depends_on:
      - ref('fct_revenue')
      - ref('dim_customers')

  - name: churn_prediction_model
    label: "Customer Churn ML Model"
    type: ml
    maturity: medium
    description: "Scikit-learn churn model trained on mart layer features."
    owner:
      name: Data Science Team
      email: ds@company.com
    depends_on:
      - ref('dim_customers')
      - ref('fct_orders')

Einmal erklärt, tauchen Exposures im Graphen der Lineage in den dbt Docs als Blattknoten auf. Sie sehen damit genau, welche Dashboards und Anwendungen es trifft, wenn sich ein vorgelagertes Modell ändert. Das ist vor Migrationen des Schemas oder vor dem Umbenennen von Modellen entscheidend.

Die dbt-Lineage an einen Enterprise-Datenkatalog anbinden

Die von dbt erzeugte manifest.json ist das Artefakt mit der höchsten Informationsdichte im Ökosystem von dbt. Sie enthält den vollständigen DAG, das kompilierte SQL jedes Modells, die Definitionen der Spalten, die Konfiguration der Tests, Beschreibungen, Tags und Metadaten, alles in einer einzigen maschinenlesbaren Datei in JSON. Das macht sie zum wichtigsten Punkt der Anbindung zwischen dbt und den Plattformen für Data Governance im Unternehmen.

Ein typischer Ablauf der Anbindung:

1. Die CI/CD-Pipeline von dbt fährt dbt compile oder dbt run und erzeugt dabei manifest.json und run_results.json.
2. Die Artefakte werden in einen Objektspeicher (S3, GCS, Azure Blob) oder in einen eigenen Speicher für Artefakte geladen.
3. Die Plattform für die Governance fragt nach neuen Artefakten oder bekommt eine Benachrichtigung per Webhook.
4. Die Plattform liest das Manifest und holt daraus die Knoten der Modelle, der Quellen und der Exposures, die Kanten (die Lineage), die Definitionen der Spalten, die Konfiguration der Tests und die Beschreibungen.
5. Diese werden in den Datenkatalog der Plattform eingefügt; die Einträge des Katalogs entstehen dabei neu oder werden mit frischer Lineage, Dokumentation und Metadaten zur Qualität aktualisiert.

Bewährte Praxis für die Governance der Lineage:

• Immer ref() und source() nutzen, nie Tabellennamen fest verdrahten. Fest verdrahtete Namen sind für den DAG unsichtbar und reißen Lücken in die Lineage.
• Alle Quellen ausdrücklich erklären. Jede Rohtabelle, die ein Modell im Staging nutzt, sollte in einer Datei _sources.yml stehen.
• Exposures für die nachgelagerten Data Consumer nutzen. Dashboards, ML-Modelle und operative Anwendungen gehören in den DAG.
• Die manifest.json nach jedem Lauf aufbewahren. Legen Sie sie in einem versionierten Speicher für Artefakte ab, für den Vergleich (zustandsbewusste CI) und für die Anbindung der Governance.
• Modelle und Spalten mit Beschreibungen versehen. Eine Lineage ohne Kontext ist ein Graph aus Namen. Beschreibungen machen daraus dokumentierte Data Contracts.

Dawiso und die dbt-Lineage

Dawiso liest die Manifeste von dbt ein und liefert damit eine durchgehende Sicht auf die Data Lineage über den gesamten Datenstapel hinweg, von den Quellsystemen über die Transformationen in dbt bis zu den nachgelagerten BI-Werkzeugen und Data Products. Das geht deutlich über das hinaus, was die Docs-Site von dbt allein zeigen kann.

Die wesentlichen Fähigkeiten, die Dawiso über die rohe dbt-Lineage hinaus beisteuert:

• Lineage über Systemgrenzen hinweg zusammenfügen: dbt-Modelle verbinden sich mit der vorgelagerten Beladung (Fivetran, Airbyte, eigene Pipelines) und mit den nachgelagerten Data Consumern (Power BI, Tableau, Looker, eigene Anwendungen) zu einem einzigen, einheitlichen Graphen der Lineage. Die Schicht von dbt ist eine Schicht in einer längeren Kette, keine Insel für sich.
• Anreicherung um den fachlichen Kontext: Der Datenkatalog von Dawiso verknüpft dbt-Modelle mit Begriffen aus dem Business Glossary, mit Data Ownern, mit Datendomänen und mit Einstufungen für die Compliance. Eine Spalte, die im Katalog als PII gekennzeichnet ist, trägt diese Einstufung durch den Graphen der Lineage zu allen nachgelagerten Data Consumern weiter.
• Lineage auf Spaltenebene über Systemgrenzen hinweg: Wo dbt eine Lineage auf Tabellenebene und optional eine auf Spaltenebene innerhalb der Schicht der Transformation liefert, verfolgt Dawiso Spalten bis in die Felder der Quellsysteme und in die Felder der nachgelagerten Berichte im BI hinein und trägt damit eine Analyse der Auswirkungen auf Spaltenebene über die gesamte Reise der Daten.
• Kontext zu Qualität und Aktualität: Die Ergebnisse der dbt-Tests und die Prüfungen der Aktualität der Quellen aus run_results.json erscheinen in Dawiso neben dem Katalogeintrag des jeweiligen Modells und geben den Data Consumern Sicherheit über die Aktualität und die Gültigkeit dessen, was sie nutzen.
• Abläufe der Governance: Die Lineage in Dawiso trägt die Benachrichtigungen über die Auswirkungen von Änderungen (die nachgelagerten Owner werden gewarnt, wenn sich das Schema eines vorgelagerten Modells ändert), die Governance des Datenzugriffs (wer welche Pfade der Lineage sehen darf) und die regulatorische Berichterstattung (die Dokumentation der Lineage für die DSGVO, für BCBS 239 oder für interne Prüfungen der Data Governance).

Praktisch heißt das: Datenteams können vollständig in dbt weiterarbeiten, also Modelle schreiben, Beschreibungen in schema.yml ergänzen und Tests fahren, während Dawiso die für die Governance wichtigen Metadaten, die dabei als Nebenprodukt entstehen, automatisch einsammelt und den Katalog des Unternehmens aktuell hält, ohne dass jemand von Hand Data Stewardship betreiben müsste. Siehe dazu auch, wie Dawiso das Management aktiver Metadaten unterstützt, um die Lineage fortlaufend aktuell zu halten.