Data Lineage and Cataloging

You cannot protect what you cannot find — tracking where sensitive data actually flows once it leaves its source table, and why a searchable catalog beats tribal knowledge once an organization has more than a handful of pipelines.

Data Quality Testing Anti-Patterns mentioned lineage briefly, for localizing a quality failure to a specific stage. This article covers the fuller governance use case: classification and access control only protect data where someone has actually applied them, and lineage is how you find every place that needs to be.

What lineage actually tracks#

Data lineage is a record of where data originated, every transformation it passed through, and every place it ended up — structurally the same directed acyclic graph Lazy Evaluation and the DAG covers for a Spark job's transformation plan, applied across an entire organization's pipelines instead of one job:

Text
customers.email (source, classified: confidential)     |     vorders_enriched.customer_email (join, still contains email)     |     vmarketing_dashboard.top_customers (aggregation — does it still                                     contain raw email, or was                                     it dropped/masked here?)

Why classification alone is not enough#

PII Classification and Sensitivity covers tagging a source column as sensitive. That tag does not automatically travel with the data — a join that pulls email into a new derived table produces a new column, in a new table, that inherits none of the original's classification unless something tracks that inheritance explicitly. Without lineage connecting the derived table back to its source, a classified, carefully access-controlled column in one table can sit completely unprotected fifty transformations downstream, in a table nobody thought to classify because nobody could see where it came from.

This is the actual mechanism behind most governance failures

A leak rarely happens at the well-known, carefully protected source table. It happens in the derived, half-forgotten downstream table three joins away that inherited sensitive data without anyone noticing — exactly the gap lineage tracking exists to close.

The catalog: making lineage actually queryable#

A data catalog is the practical tool this depends on: a searchable inventory of what tables and columns exist, their classification, their owner, and — via metadata management — their lineage back to source. Without one, answering "does this table contain PII" means asking around and hoping someone remembers; with one, it is a lookup.

Automated capture vs. manual documentation#

Manually documenting lineage — a wiki page per pipeline, updated by hand — degrades the same way manual PII classification does: it goes stale the moment a pipeline changes and nobody remembers to update the page. Automated lineage capture, parsing query logs or pipeline code to build the dependency graph directly, stays accurate as the actual system changes, at the cost of needing tooling that understands the query language or orchestration framework in use. Most mature catalogs combine both — automated capture as the primary source of truth, with manual annotation for ownership and business context automation cannot infer.

Common mistakes#

Classifying a source column without tracking where it propagates#

The single most common gap this article covers — a well-classified source whose derived, downstream copies were never connected back to it, and therefore never inherited the same protection.

Relying on manual lineage documentation at real scale#

A handful of pipelines can be documented by hand and kept current. Dozens or hundreds cannot — the documentation drifts out of sync with reality almost immediately, and a stale lineage record is worse than none, because it creates false confidence that the picture is complete.

No catalog at all — lineage as tribal knowledge#

Knowledge of "where sensitive data actually lives" held only in a few people's heads is a bus-factor risk for the whole governance program, not just an inconvenience — the same accountability gap Data Contracts warns about for an unowned contract, here applied to an entire data estate instead of one dataset.

Further reading#

See also#