How to trace data lineage with Yantra Studio
Trace a data element back through the systems that produced it, and forward to everything that consumes it.
When this is useful
- A reported figure is disputed and the argument is really about its source.
- A regulator or auditor asks how a data item is derived.
- A source system is being replaced and you need to know what depends on its output.
Before you start
- Models for the systems involved and the mappings between them. Lineage follows what has been recorded.
Step 1: Make sure the path is modelled
Lineage traverses recorded relationships and mappings. Where a hop between two systems exists only in an ETL job nobody modelled, record it first — a source-to-target map is the usual way.
Data ▸ Source→Target Map
Step 2: Run Lineage from the element
Select the data element and open Lineage to follow it through the model.
Data ▸ Lineage
Step 3: Confirm the definitions agree
Check the Business Glossary and Data Dictionary along the path. A lineage that is structurally correct but crosses a definition change is the usual explanation for two systems reporting different numbers from the same data.
Data ▸ Business GlossaryData ▸ Data DictionaryData ▸ Metadata Repository
What happens next
The traced path supports an impact assessment in the other direction: what you have just followed forwards is what a change at the source would affect.
Example
A monthly revenue figure traced back four hops to a source field whose definition had changed a quarter earlier — the reconciliation gap had a date attached to it within an hour.
Tips
- Trace both directions. Upstream answers "where did this come from"; downstream answers "who will notice if I change it".
- Record each hop as you discover it. Lineage work is mostly the recording; the traversal is the easy part.
Limitations
- Lineage is derived from the model, not observed from running pipelines. An undocumented transformation is invisible to it.