Data Lineage Tracking: Warum es zählt und wie du es implementierst

Ein KPI-Dashboard zeigt -18 % Umsatz im letzten Quartal. Finance ist alarmiert. Du musst wissen: Ist das echt oder ist eine Pipeline kaputt? Ohne Data Lineage trace-st du manuell SQL durch vier Transformations-Layer, drei Quellsysteme und ein dbt-Projekt mit 200 Models. Mit Lineage: zwei Klicks, kaputten Upstream-Join gefunden.

TL;DR

• Lineage beantwortet drei Fragen: Woher kommt es? Was wurde transformiert? Wer konsumiert es?
• Table-Level ist relativ einfach, Column-Level ist die echte Herausforderung.
• OpenLineage ist der entstehende Standard, Marquez die Open-Source-Referenz.
• Unity Catalog gibt dir Lineage automatisch — wenn du auf Databricks bist.
• DSGVO Auskunftsrechte sind ohne Lineage ein manueller Albtraum.

Was Lineage wirklich ist

Lineage beantwortet drei Fragen:

1. Ursprung: Woher kommen die Daten? Welches Quellsystem, welche Tabelle, welches Feld?
2. Transformation: Was ist passiert? Welche Pipelines, Queries, Models haben das angefasst?
3. Impact: Wer konsumiert? Welche Dashboards, Models, Downstream-Pipelines hängen dran?

Column-Level ist deutlich härter — Table-Level machen die meisten Tools gut, Column-Level inkonsistent.

Warum Lineage wichtig ist

Incident-Response

Metric bricht? Lineage traced upstream zur Wurzel. Ohne: grep durch SQL-Files und Slack.

Impact-Analyse

Bevor du eine deprecated Spalte droppst, musst du wissen, wer dran hängt.

Regulatorisch

DSGVO, CCPA, HIPAA, SOX haben alle Varianten von "beweise, dass du weißt, wo personenbezogene Daten leben und fließen". Lineage ist Audit-Evidence.

Data-Quality-Debugging

Schlechte Qualität entsteht drei Layer upstream. Lineage traced zur Quelle.

OpenLineage als Standard

OpenLineage ist offener Standard (CNCF) für Lineage-Events. Statt dass jedes Tool eigene Lineage-API spricht, definiert OpenLineage ein gemeinsames JSON-Schema.

{
  "eventType": "COMPLETE",
  "eventTime": "2024-03-15T14:30:00Z",
  "job": { "namespace": "my_airflow", "name": "orders_pipeline.transform_orders" },
  "inputs": [{
    "namespace": "postgres://prod-db",
    "name": "public.orders_raw",
    "facets": { "schema": { "fields": [
      {"name": "order_id", "type": "VARCHAR"},
      {"name": "amount",   "type": "NUMERIC"}
    ]}}
  }],
  "outputs": [{
    "namespace": "s3://datalake",
    "name": "orders/cleaned",
    "facets": { "schema": { "fields": [
      {"name": "order_id",   "type": "VARCHAR"},
      {"name": "net_amount", "type": "DOUBLE"}
    ]}}
  }]
}

OpenLineage-Events werden von Integrations emittiert — Bibliotheken, die in deine Tools (Airflow, Spark, dbt, Flink) einhaken und automatisch Events feuern.

from openlineage.client import OpenLineageClient
from openlineage.client.run import RunEvent, RunState, Run, Job
from openlineage.client.facet import SchemaDatasetFacet, SchemaField
from openlineage.client.dataset import Dataset
import datetime, uuid

client = OpenLineageClient.from_environment()
run_id = str(uuid.uuid4())

event = RunEvent(
    eventType=RunState.COMPLETE,
    eventTime=datetime.datetime.utcnow().isoformat() + "Z",
    run=Run(runId=run_id),
    job=Job(namespace="custom_pipeline", name="enrich_customers"),
    inputs=[Dataset(namespace="postgres://prod", name="public.customers",
        facets={"schema": SchemaDatasetFacet(fields=[
            SchemaField("customer_id", "VARCHAR"),
            SchemaField("email", "VARCHAR"),
        ])})],
    outputs=[Dataset(namespace="s3://datalake", name="customers/enriched",
        facets={"schema": SchemaDatasetFacet(fields=[
            SchemaField("customer_id", "VARCHAR"),
            SchemaField("email", "VARCHAR"),
            SchemaField("geo_country", "VARCHAR"),
        ])})],
    producer="custom_pipeline/v1.0"
)
client.emit(event)

Tools verglichen

Marquez

Open-Source-Referenz für OpenLineage-Consuming. Metadata-Server mit UI, der den Lineage-Graph visualisiert.

• Open Source, self-hosted, OpenLineage nativ, REST-API

• UI funktional, nicht poliert. Keine Enterprise-Features (RBAC, SSO) out-of-the-box.

Unity Catalog (Databricks)

System Tables fangen automatisch Lineage für Databricks-Workloads. Jede Query gegen UC-managed Tables wird getrackt — keine Instrumentierung nötig.

SELECT source_table_full_name, target_table_full_name, created_by, event_time
FROM system.access.table_lineage
WHERE target_table_full_name = 'main.analytics.fact_orders'
ORDER BY event_time DESC LIMIT 20;

• Zero-Instrumentation, Column-Level (neuere Releases), integriert mit Access-Control

• Databricks-only, kostet, Vendor-Lockin

dbt Lineage

DAG aus ref() und source() Calls. dbt docs generate baut den Graph.

Vergleich

Implementierung in der Praxis

Schritt 1: Backend wählen

• Databricks-Nutzer:innen: UC aktivieren — Lineage frei für Spark/SQL.
• Multi-Plattform-Teams: OpenLineage + Marquez (oder DataHub als reifere Alternative).
• dbt-heavy: Start mit dbt docs, OpenLineage für Cross-System dazu.

Schritt 2: Pipelines instrumentieren

# Airflow — openlineage-airflow Provider
# OPENLINEAGE_URL=http://marquez:5000
# OPENLINEAGE_NAMESPACE=production_airflow

# PySpark
spark = SparkSession.builder \
    .appName("my_pipeline") \
    .config("spark.extraListeners", "io.openlineage.spark.agent.OpenLineageSparkListener") \
    .config("spark.openlineage.transport.type", "http") \
    .config("spark.openlineage.transport.url", "http://marquez:5000") \
    .config("spark.openlineage.namespace", "production") \
    .getOrCreate()

Schritt 3: Lineage programmatisch abfragen

import requests

def get_upstream_datasets(namespace: str, dataset_name: str):
    url = f"http://marquez:5000/api/v1/lineage?nodeId=dataset:{namespace}:{dataset_name}"
    response = requests.get(url)
    response.raise_for_status()
    graph = response.json()
    return [
        edge["origin"]["id"]
        for edge in graph.get("graph", [])
        if edge["type"] == "EDGE" and edge["destination"]["id"] == f"dataset:{namespace}:{dataset_name}"
    ]

upstream = get_upstream_datasets("s3://datalake", "fact_orders")

Häufige Fallen

1. Lineage als Afterthought. Am günstigsten beim Bau, am teuersten retrofittet. 200-Model-dbt-Projekt nachträglich = Wochen.
2. Table ohne Column. Du brauchst Column für DSGVO Data-Subject-Requests und Quality-Debugging.
3. Lineage nur als ETL-Problem. BI-Tools (Tableau, Looker), Notebooks, ML-Pipelines auch. Ein kaputtes Dashboard ohne Lineage zur Quelle ist genauso blind wie eine kaputte Pipeline.
4. Keine Ad-hoc-Query-Lineage. Die meisten tracken Scheduled-Pipelines, ignorieren Analyst:innen-Queries. UC und DataHub fangen auch Ad-hoc SQL ein.

FAQ

Wo fange ich an, wenn ich noch nichts habe? dbt docs (kostet nichts) für die Transformations-Schicht. Wenn auf Databricks: UC. Sonst: Marquez + OpenLineage.

Wie DSGVO-konform speichern? Lineage-Metadaten enthalten meist keine personenbezogenen Inhalte, nur Strukturinformationen. Trotzdem im EU-Hosting (eu-central-1) ablegen.

Lohnt sich Column-Lineage für ein 10-Personen-Team? Selten am Anfang. Table-Lineage gibt dir 80 % der Incident-Response-Beschleunigung.

Wie performant ist Marquez? Funktioniert für Millionen Events. Bei >10 Mio. wirst du Postgres-Tuning brauchen.

Stand: 14. Mai 2026.