skip to content

What can a data lineage graph tell an analyst about where a dashboard number comes from, and what can it not tell them?

level: juniorimportance: should knowfreq 45%

answer

  1. path, not meaning
  2. sources and the steps between
  3. correct? ask quality checks
  4. defined how? ask the glossary

basics

~20 s

Lineage shows which sources and transformation steps feed the number, and in what order. It does not say whether the data is correct, what the metric is supposed to mean, or whether the logic matches the business definition.

solid answer

~40 s

A lineage graph answers **"where did this come from?"**: the dashboard reads a model, the model reads two staging tables, and those read a billing export and a CRM feed. With column-level detail it can name the exact source columns behind the figure. What it cannot tell you is whether any of those inputs are **correct** (that is what data-quality checks are for), what the metric is **supposed** to mean (a glossary or metric definition says that), or whether the transformation logic matches the business rule. Lineage is a map of the route, not a certificate that the route is right. So an analyst uses it to find **who to ask and what to inspect**, then checks definitions and quality separately.

go deeper

for a junior

Be ready to say lineage shows sources and steps, and to name two things it does not show, such as correctness and business meaning.

for a middle

Explain how you would combine lineage with the metric definition and quality checks to investigate a disputed figure.

for a senior

Show that you use lineage to route questions to owners and to decide which checks are missing along the path.

for a principal

Argue how lineage, glossary and quality signals should be presented together so that consumers stop mistaking a traced number for a trusted one.

## What a lineage graph is **Data lineage** is a record of how data moves: which **datasets** exist (tables, files, dashboards, extracts) and which **processes** (jobs, queries, transformations) read some datasets and write others. Drawn as a graph, datasets and processes are nodes and the read/write relationships are edges. Walking the edges from a dashboard back towards the systems that first captured the data is the question an analyst usually has: *where does this number come from?* ## What it tells an analyst - **The sources.** Which upstream systems feed the figure — for example an invoicing export and a customer-relationship feed. - **The path.** Every intermediate table and job between the source and the dashboard, in order. - **The columns, if the graph is column-level.** A column-level graph maps each output column to the input columns it was computed from, so it can say that `net_revenue` is derived from `invoice_amount` and `refund_amount`. - **Who owns each step**, when the lineage is joined to catalog metadata, which tells the analyst whom to ask. - **Freshness clues**, when runs are recorded: when each step last ran. ## What it cannot tell them | Question | Does lineage answer it? | Where the answer lives | |---|---|---| | Which tables feed this number? | Yes | the lineage graph | | Is the source data accurate and complete? | No | data-quality checks and tests | | What does "active customer" mean here? | No | a business glossary or metric definition | | Is the join or filter logic right for the business rule? | No | reading the transformation code, and the owner | | Is the analyst allowed to see the source rows? | No | access policy | Lineage records **that** a step transformed data, and sometimes **which columns** it touched; it does not judge **whether** the transformation is right. A perfectly traced number can still be wrong because a filter drops refunds, or because two teams mean different things by "revenue". ## How an analyst actually uses it 1. Open the dashboard's node and walk **upstream** to see the chain of models and sources. 2. Note the owner of each step and the last successful run times. 3. Compare the metric's documented definition with what the transformation actually computes. 4. Ask the owner of the step where the definitions diverge, or where a check is missing. ## Why interviewers ask it The question separates candidates who treat a lineage diagram as proof of correctness from those who treat it as a **map for investigation**. The good answer states both halves: lineage narrows *where* to look and *whom* to ask; quality checks and definitions decide whether the number is right.

  • If lineage cannot prove a number correct, why is it still worth maintaining?
    Because it turns an open-ended hunt into a bounded one. When a figure is questioned, the graph lists the handful of steps and owners that could be responsible, and when a source changes it lists who will be affected. Without it both questions are answered by asking around, which is slow and misses people.
  • What does column-level lineage add for this analyst compared with table-level?
    It narrows the trace from "these five tables feed the dashboard" to "these three source columns feed this particular figure". That means fewer steps to inspect and a precise list of the upstream fields whose meaning or quality matters for the number in question.

Lineage is a route map of a delivery. It shows every road and depot the parcel passed through, but not whether it was packed correctly at the start.

saying these in an interview costs you the question

  • Treating a complete lineage graph as proof that the number is correct
  • Assuming lineage explains what a metric is supposed to mean
  • Believing lineage replaces data-quality checks
  • Thinking lineage only matters to engineers, not to analysts