Column-level lineage: the concepts and the event standard

At a glance

Learning objectives

• Explain why column-level lineage beats table-level for change impact
• Read an OpenLineage event and name its Airflow, Spark and dbt integrations
• Compute a downstream impact set from a lineage store

What you need

• [object Object]
• A lineage store (DataHub or any OpenLineage-compatible backend)

Steps

1. Start from the standard — an open specification for lineage events with integrations for Airflow, Spark and dbt; not a tool or a service, a standard for emitting lineage events. (from ref-openlineage-docs )
2. See why the standard matters — an open specification for lineage events is what makes cross-tool lineage possible. (from ref-openlineage-docs )
3. Define column-level lineage — traces from an asset to its upstream sources and downstream consumers, reporting the impact set for a proposed change. (from skill-lineage-explainer )
4. Hold the two graphs — technical lineage (tables and jobs) versus business lineage (metrics and reports); a breaking change needs both. (from skill-lineage-explainer )
5. Practice the walk — read lineages from a lineage store, compute the downstream impact set, distinguish technical from business lineage. (from skill-lineage-explainer )
6. Know where events land — the open metadata model for ownership and lineage, plus the ingestion framework that keeps emitted events queryable. (from ref-datahub-docs )
7. Keep the driving question in view — "what breaks if I change this column?", answered with evidence. (from skill-lineage-explainer )

Check yourself

• A table-level edge hides the fact that only one column changed — column-level lineage localizes the blast radius.
• An Airflow task, a Spark job and a dbt model produce lineage into one graph because they emit the same event standard.

Worked example

job:      dbt://analytics/stg_orders
inputs:   [postgres://prod/orders]
outputs:  [warehouse://analytics/stg_orders]
# emitted per run by the integration; column facets carry the
# column-level edges that make the graph worth querying

changed: stg_orders.customer_email (type widened)
  └─▶ downstream: dim_customers.email ──▶ mart_revenue (published — stop)
report: owner, criticality, earliest SLA that breaks

Sourced from

• OpenLineage Documentation
• Lineage Explainer
• DataHub Documentation

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Lineage without a standard is a per-tool island — the open spec is what stitches Airflow, Spark and dbt into one graph.
• Column-level lineage is a commitment — parsers must keep up with SQL dialects or the graph lies quietly.
• The impact set is a walk, not a lookup — stop at published marts, where owners and SLAs live.

Production considerations

• Emit events from every job that moves data — partial graphs are worse than none because they look complete.
• Version the lineage store like code — schema of the graph changes with the platform.

Diagram

column-level lineage
   |
   |- postgres.orders ──(job)──▶ stg_orders ──▶ dim_customers ──▶ mart_revenue
   |         │                      │                │
   |         └── column edges ──────┴────────────────┘
   |
   |- change: stg_orders.customer_email
   |
   |- walk downstream ──▶ stop at published marts
   |
    --> impact set: owner + criticality + earliest SLA that breaks

Registry stats