Data Lineage: Tracing a Number Back to Its Sources
📑 On this page
- A concrete example: tracing net revenue
- Source lineage
- Transformation lineage
- Dataset lineage
- Column-level lineage
- Runtime versus design lineage
- Automatic collection
- Manual lineage
- Impact analysis
- Debugging
- Compliance
- Access-aware lineage
- Root-cause and blast-radius views
- Sensitive data propagation
- Machine learning lineage
- Versioning
- OpenLineage-style events
- Lineage graph
- Cycles
- Ownership
- Freshness and status
- Limitations
- Validation
- Knowledge check
- The one idea to remember
A dashboard number is rarely read directly from one source column.
It may pass through extraction, joins, filters, currency conversion, aggregation, and caching.
Data lineage records where data came from, how it changed, and which downstream outputs depend on it.
Lineage makes analytical systems explainable and changeable.
A concrete example: tracing net revenue
An analyst clicks a dashboard field.
Lineage shows:
- dashboard tile reads
monthly_revenue, - model subtracts refunds and fees,
- transformation joins orders, payment ledger, and currency rates,
- jobs load those from three source systems,
- exact source columns and owners are identified.
A missing refund feed can be located quickly.
Source lineage
Source lineage records:
- system,
- database,
- table,
- field,
- API,
- event topic,
- or file.
It should distinguish authoritative source from convenient copy.
Transformation lineage
Transformation lineage connects inputs to outputs through:
- SQL model,
- code job,
- spreadsheet formula,
- machine-learning feature,
- or manual rule.
Preserve code version and run context.
Dataset lineage
Dataset-level lineage shows:
orders -> cleaned_orders -> revenue_model -> dashboardIt is easier to collect and useful for broad impact analysis.
Column-level lineage
Column lineage shows how one output field derives from specific input fields.
This helps with:
- sensitive-data tracing,
- metric explanation,
- and schema changes.
Dynamic SQL and procedural code make extraction harder.
Runtime versus design lineage
Design lineage comes from declared code and schemas.
Runtime lineage records what actually ran:
- which partitions,
- which files,
- which job version,
- which parameters.
Both matter. Code may define a path that a failed run never completed.
Automatic collection
Tools can parse:
- SQL,
- orchestration metadata,
- query logs,
- catalog events,
- and pipeline APIs.
Automation scales but may miss custom scripts, manual exports, and opaque SaaS transformations.
Manual lineage
Important business processes sometimes need documented manual edges:
- spreadsheet upload,
- regulatory adjustment,
- human classification.
Manual lineage should include owner and evidence, not an undocumented arrow.
Impact analysis
Before changing a source column, lineage answers:
- Which models consume it?
- Which dashboards display it?
- Which exports and models depend on it?
- Which teams own them?
This turns a risky search across repositories into a known dependency graph.
Debugging
When a number is wrong, work backward:
- output,
- transformation,
- intermediate data,
- source,
- source event.
Lineage narrows where the value changed or disappeared.
Quality status at each node helps distinguish source and pipeline defects.
Compliance
Lineage can show:
- where personal data flows,
- which reports use it,
- where it is copied,
- and whether deletion or retention reaches derivatives.
It supports evidence but does not automatically enforce policy.
Access-aware lineage
Lineage metadata can reveal sensitive table names, customer domains, or security architecture.
Users should discover enough to understand permitted datasets without receiving access to every source or query. Apply role-based views and audit sensitive lineage exploration.
Root-cause and blast-radius views
The same graph supports two directions:
- upstream: why is this dashboard wrong?
- downstream: what breaks if this source changes?
Interfaces should make both traversals easy and show freshness, owner, and quality at each node so a graph becomes an operational tool rather than static decoration.
Sensitive data propagation
If an input column contains sensitive information, transformations may:
- preserve,
- mask,
- aggregate,
- tokenize,
- or derive another sensitive attribute.
Classification should propagate according to transformation semantics.
Aggregation does not always guarantee anonymity.
Machine learning lineage
Models depend on:
- training datasets,
- feature code,
- labels,
- parameters,
- and evaluation.
Lineage connects a prediction or model version to those inputs.
This supports reproducibility and impact analysis after data correction.
Versioning
Lineage changes over time.
Record:
- source schema version,
- transformation commit,
- job run,
- model version,
- dashboard version.
A current graph cannot fully explain last month's report.
OpenLineage-style events
Runtime systems can emit standardized events for:
- job start,
- completion,
- input datasets,
- output datasets,
- schema,
- and run identity.
Standards improve interoperability among orchestrators, catalogs, and observability tools.
Lineage graph
Represent lineage as a directed graph:
- nodes are datasets, fields, jobs, or reports,
- edges are reads, writes, and transformations.
Large graphs need filtering by time, domain, and level.
Cycles
Feedback systems can create cycles:
- model scores influence behavior,
- behavior becomes new training data.
Cycles are important for bias and causality analysis. A simple acyclic pipeline picture may hide them.
Ownership
Every important node should connect to:
- owner,
- documentation,
- quality objective,
- and contact.
Lineage without ownership shows where a failure travels but not who can fix it.
Freshness and status
Overlay runtime health:
- last successful update,
- freshness,
- quality result,
- and incident.
Consumers can see whether a downstream report depends on stale input.
Limitations
Lineage can be incomplete because of:
- dynamic code,
- manual files,
- external tools,
- runtime-generated queries,
- and missing instrumentation.
Show confidence and gaps rather than presenting an automatically generated graph as perfect.
Validation
Test lineage by selecting important reports and tracing them to source, then compare the graph with runtime query and job evidence.
Missing or stale edges should be treated as metadata defects with owners. High-value regulated and financial paths deserve stronger completeness objectives than temporary exploratory work.
Knowledge check
- How do dataset and column lineage differ?
- Why are design and runtime lineage both needed?
- How does lineage support schema change?
- What special lineage does machine learning need?
- Why should a lineage graph show confidence or gaps?
The one idea to remember
Data lineage connects source fields, datasets, transformations, runs, and outputs across time. It supports debugging, change impact, quality, compliance, and reproducibility when automated evidence is combined with ownership and honest treatment of missing edges.