Lineage

What You'll Be Able to Do After This Module

Read a DataHub lineage graph: identify upstream sources and downstream consumers
Switch between table-level and column-level lineage views
Use downstream lineage to understand the impact of changing a table
Use upstream lineage to trace a broken metric back to its source
Complete the lab: trace a broken dashboard metric to the most likely point of failure

Lineage: A Map of How Data Flows

A directed graph: nodes are entities, edges are dependencies
Upstream (left): where did this data come from?
Downstream (right): what uses this data?
Nodes: tables, dbt models, Airflow DAGs, dashboards -- any DataHub entity
Edges: "table B was produced from table A" -- the direction of data flow

Four Reasons Lineage Is Not Optional

Impact analysis: before changing table A, see every downstream dashboard and table that depends on it
Root cause: a dashboard is broken -- trace upstream to find which source table introduced the error
Trust: understand the full transformation chain between raw data and a business metric
Compliance: trace PII from its origin through every system that touches it

Walk through each row with a one-sentence concrete example. Impact analysis: "You are renaming a column in fct_orders. Lineage shows 14 downstream dashboards. You now know who to notify before you make the change." Root cause: "The weekly revenue summary shows the wrong number. Lineage shows the chain: dashboard comes from rpt_revenue_weekly, which comes from fct_revenue_daily, which comes from stg_orders. The break is in one of those three hops." Trust: "An analyst wants to use rpt_revenue_weekly for a board presentation. Before they do, they want to know whether it went through any aggregation or filtering that could affect the number." Compliance: "Legal asks whether SSN data flows into any dashboard. Lineage gives the definitive answer." Ask the group which use case they encounter most often -- it is usually root cause or impact analysis, and knowing that helps you calibrate how much time to spend on each.

Finding the Lineage View in the UI

Navigate to any dataset or dashboard entity page
Click the Lineage tab (next to Summary, Columns, etc.)
Default view: table-level lineage graph
Center node = the entity you opened
Left side = upstream (ancestors)
Right side = downstream (consumers)
Click Expand on any node to reveal its upstream/downstream connections

Brief: Screenshot of a dataset entity page in the DataHub sandbox with the Lineage tab selected, showing the tab bar (Summary, Columns, Lineage, ...) and the default table-level lineage graph with the opened entity as the center node.

Anatomy of the Lineage Graph

Nodes show the entity type via an icon in the top-left corner of each card (Snowflake logo = Snowflake dataset, dbt logo = dbt model, etc.)
Arrows show direction of data flow -- follow the arrow to go downstream
Expand button on any node reveals the next hop in either direction
Double-click any node to navigate to that entity's own lineage view (opens a new center)
Scroll and zoom to navigate large graphs

Brief: Screenshot of a populated lineage graph in the DataHub sandbox showing at least one Snowflake dataset node, one dbt model node, and one pipeline (Airflow) node connected by directional arrows, with the Expand button visible on one node.

Point out the color coding on the live graph. It matters because in a complex lineage graph you can immediately see the types of entities involved -- whether the lineage passes through an Airflow DAG, a dbt transformation, or goes directly from table to table. Ask participants: "What does it mean when you see an orange pipeline node between two blue dataset nodes?" Answer: data flows from the upstream dataset through a pipeline (an Airflow DAG, for example) into the downstream dataset. That pipeline is where the transformation logic lives -- which means if something is wrong, that is a place to investigate. The double-click-to-navigate behavior is powerful but disorienting at first: double-clicking a node changes the center of the graph. Tell the group to use the browser back button to return to where they started.

Two Levels of Lineage Detail

Table-level (default): stg_orders → fct_orders → rpt_revenue_weekly → Revenue Dashboard -- tells you which tables and entities are in the chain
Column-level: stg_orders.amount → fct_orders.gross_revenue → rpt_revenue_weekly.total_revenue → Revenue Dashboard.Total Revenue -- tells you exactly which columns carry data through each hop
Toggle: use the "Column Lineage" toggle on the Lineage tab

Brief: Screenshot, before/after comparison of the Lineage tab for the same chain -- table-level graph on one side, column-level graph with column names shown on each node on the other -- with the "Column Lineage" toggle visible.

Demo the toggle in the sandbox. First show table-level -- the clean, simple graph. Then toggle to column-level. The graph gets more detailed: you can see individual columns and how they map from one table to the next. This is the view you want when debugging a specific metric. If the "Total Revenue" column in a dashboard is wrong, column-level lineage shows exactly which upstream column fed it at every hop -- which is where you look for the transformation that introduced the error. Make the caveat explicit: column-level lineage is not magic -- it only appears when the ingestion source emitted that data. dbt tends to produce the most reliable column-level lineage because its manifest gives DataHub's SQL parser clean, already-compiled SQL to work from. Raw SQL query log parsing (Snowflake, BigQuery) can also provide it, but with gaps. If the group asks "why is column lineage missing for some tables," the answer is that those tables were ingested from a source that does not emit column-level information. PRO TIP -- Column-level lineage accuracy: DataHub uses SQL parsing with 97-99% accuracy to auto-generate column-level lineage from Snowflake, BigQuery, dbt, Looker, and PowerBI queries. For pipelines that use these tools, column lineage works out of the box with no configuration beyond enabling it in the ingestion recipe. BEST PRACTICE -- Column-level lineage: when to check it: Check column-level lineage when (1) you are using a derived or calculated field and want to understand the calculation chain; (2) a data quality issue appears in a downstream metric; (3) you are validating that an upstream schema change affected the right downstream fields. On the Lineage tab, click the "Column Lineage" toggle, then select the column from the dropdown that appears.

Understand the Transformation Chain Before You Use a Dataset

Open the Lineage tab
Read the upstream chain -- what raw sources did this come from?
Check whether any hops go through aggregations, filters, or joins
If the chain includes a pipeline or dbt model, open it to see the transformation logic
Look for gaps in lineage -- they mean that part of the chain was not captured

Brief: Screenshot of the Lineage tab for a dataset showing an upstream chain that passes through a dbt model node, with that node clicked/highlighted to illustrate "open it to see the transformation logic."

This is the "trust but verify" principle applied to data. Even a Verified dataset can have upstream dependencies that affect its meaning. A common example: an analyst uses a table called fct_revenue_monthly assuming it captures all revenue, but lineage reveals it is actually filtered to US markets only -- that filter is in an upstream dbt model. Without checking lineage, they would not know. Tell the group that checking lineage does not take long -- 30 seconds to scan the chain. And it turns out that the times when you skip it are exactly the times you need it most. Pair this with the root-cause pattern on the next slide: checking lineage proactively prevents the scenario where you are debugging after the fact. BEST PRACTICE -- Verify lineage before using data in production analysis: Before basing an executive report on a dataset you haven't used before, check the lineage to confirm upstream sources are production systems (not test/sandbox), check for any data quality assertion failures on upstream tables, and verify that downstream consumers include dashboards from teams who trust this data. Other teams using it is strong validation.

Debugging a Broken Metric: Work Backwards Through Lineage

Start at the broken entity (dashboard or report)
Open Lineage → navigate upstream (left)
At each hop, ask: "Could the error have been introduced here?"
Check for: recent ingestion failures, schema changes, upstream source issues
The break is almost always in one specific hop -- find it

Walk through this pattern explicitly with a story: "The 'Weekly Revenue Summary' dashboard is showing wrong numbers. You open it in DataHub and click the Lineage tab. Upstream, you see rpt_revenue_weekly. You click into that table's lineage. Upstream from there is fct_revenue_daily. One more hop: stg_orders. And one more: the raw Snowflake source table. Now you have the full chain -- four hops from raw to dashboard. The question is: which hop introduced the error? You check whether the raw table had a recent load failure. You check whether stg_orders had a schema change. You check whether fct_revenue_daily was modified recently. This structured approach beats randomly poking at tables." Then say: "This is exactly the scenario in today's lab." Tell them the lab gives them this scenario but not the solution -- they have to trace the lineage themselves to identify the most likely failure point. BEST PRACTICE -- Lineage-first troubleshooting workflow: When a dashboard shows unexpected numbers or missing data: (1) open the asset in DataHub; (2) click the Lineage tab; (3) check each upstream node for data quality warning indicators; (4) identify the failing node; (5) contact that node's Technical Owner. This process replaces hours of Slack threads with a 5-minute investigation.

A Lineage Gap Means "Not Tracked," Not "No Upstream"

Lineage in DataHub reflects what was captured by ingestion
A gap (no upstream nodes visible) means that transformation was not tracked by an integrated source
It does NOT mean the table has no upstream -- it means the upstream was not ingested
Common causes: manual SQL, a tool not yet integrated with DataHub, a pipeline run before DataHub was deployed
Never assume "no lineage = raw source"

Brief: Screenshot of a dataset's Lineage tab with an empty upstream (left) side and a populated downstream (right) side, showing what a lineage gap looks like in the UI.

This is the most important watch-out in the module because it leads to a dangerous false conclusion. If a participant sees an empty upstream graph, they might assume they have found the source of truth -- when actually the table has upstream dependencies that just were not captured. This is especially common in organizations that are early in their DataHub rollout. Tell the group: "If you see a lineage gap and it matters -- for compliance, for debugging, for impact analysis -- treat it as an open question, not a confirmation. Ask the data team: 'Do you know what this table is derived from?' They may have the answer even if DataHub does not." Also worth noting: gaps get filled over time as more sources are integrated. The catalog is a living record, and lineage coverage improves as the data platform team integrates more tools. WATCH OUT -- Lineage gaps are expected -- know their causes: DataHub builds lineage from what source systems emit. Common gaps: (a) SQL executed outside dbt/Airflow (ad-hoc queries don't generate lineage); (b) custom Python transformations that don't integrate with DataHub's lineage API; (c) tables ingested from sources that don't support lineage extraction. A gap doesn't mean the data has no lineage -- it means the lineage isn't captured yet.

Use Downstream Lineage Before Deprecating or Changing a Table

Open the entity page and click the Lineage tab
Navigate right (downstream) -- see everything that depends on this table
Note all downstream dashboards, reports, and other tables
Notify the owners of those assets before making the change
For a deprecation: add a description pointing to the replacement first

Brief: Screenshot of a table's Lineage tab with the downstream (right) side expanded, showing multiple dashboard and dataset nodes depending on the opened table.

This is the impact analysis pattern. Make it concrete: "You want to deprecate fct_orders_v1 because fct_orders_v2 now exists. Before you add the Deprecated tag, you click the Lineage tab and navigate downstream. You see 8 datasets and 4 dashboards that depend on fct_orders_v1. Those 12 downstream consumers will break if you deprecate the table without warning. DataHub gives you the list of owners for all 12 -- you can reach out to each one." Then contrast the alternative: "Without lineage, you deprecate the table, two dashboards break over the weekend, and two data engineers spend Monday morning debugging what happened." This slide is also the answer to a common question: "Why does DataHub even store lineage? Why does it matter?" Because without it, impact analysis is guesswork. PRO TIP -- Use Impact Analysis before any schema change: Before modifying a column or table structure, click Impact Analysis on the Lineage tab. This shows all downstream dashboards, reports, and models that depend on this asset, filtered by platform, type, or domain. Discovering that a "minor" column rename would break 12 dashboards before making the change is far better than after.

Trace a Broken Dashboard Metric

Scenario: the "Weekly Revenue Summary" dashboard is showing wrong numbers this week. The metric comes from the fct_revenue_daily table.
Open fct_revenue_daily in the DataHub sandbox
Use the Lineage tab to trace upstream dependencies
Navigate as far upstream as the lineage allows
Identify the most likely point of failure (the specific table or pipeline hop)

Brief: Screenshot of the fct_revenue_daily dataset page in the DataHub sandbox with the Lineage tab open, as the starting screen participants land on for the lab.

No step-by-step instructions. Read the scenario aloud, then hand it over. Circulate and observe -- do not answer "is this the right table?" questions. The point is for them to develop the habit of reading the lineage graph and reasoning about what they see. After 10 minutes, debrief as a group: ask three people to share their answer and their reasoning. For the most likely failure point, accept any reasoned answer that identifies a specific hop and explains why they suspect it. There is no single correct answer -- the goal is to show that they can navigate the graph, read the chain, and form a hypothesis. If the column-level lineage is not populated in the sandbox, acknowledge it and explain why (ingestion source did not emit column lineage) -- this is itself a teaching moment about lineage gaps.

Check for Understanding

You open the Lineage tab on a dataset and the upstream side is completely empty. What does that tell you?
You are about to rename a column in a heavily used table. What should you do in DataHub before making the change?
A dashboard is showing the wrong number. You have traced upstream from the dashboard and found: Dashboard ← rpt_revenue_weekly ← fct_revenue_daily. The fct_revenue_daily table was last updated 3 days ago but the pipeline normally runs daily. What do you suspect?

Cold-call three different people. Expected answers: (1) An empty upstream does not mean the table is a raw source -- it means that part of the lineage was not captured by ingestion. Treat it as an unknown, not a confirmation. (2) Open the Lineage tab, navigate downstream to see every table and dashboard that depends on this column, then notify the owners of those downstream assets before making the change. (3) The most likely point of failure is the pipeline that populates fct_revenue_daily -- it appears to have not run in 3 days when it should have run daily, which would cause stale or incorrect data to flow into rpt_revenue_weekly and then into the dashboard. Push participants on question 3 if they give a shallow answer: "How would you confirm your hypothesis?" The answer involves checking the pipeline logs or looking at the last modified timestamp on fct_revenue_daily in DataHub.

Summary: Lineage

DataHub tracks end-to-end lineage across datasets, dashboards, jobs, and pipelines
Column-level lineage maps which upstream columns feed each downstream field
Lineage is captured automatically during ingestion -- no manual tracking required
Impact Analysis: before changing any asset, check downstream dependents on the Lineage tab
Lineage reflects the last ingestion run, not real-time data movement
Next: Metadata in Practice