SQL, data modeling, data quality, EDA, visualization · insight-1071
Check downstream consumers through lineage before renaming or retyping a column
- Evidence type
- practitioner heuristic
- Difficulty
- medium
- Roles
- Data analyst, Data scientist, ML engineer
- Industries
- cross-industry
Summary: situation, action, reason, boundary
Situation
A source team renames fare_amount to base_fare in the booking table and says "only the mart uses it".
Action
Query the lineage graph (datasets and jobs that read the table, their owners and last run), notify the owners, ship the change as add-new-then-deprecate-old with a date, and watch downstream freshness and null-rate checks during the switch.
Reason
A dependency you cannot list is a dependency you cannot protect; lineage turns "who uses this" from a guess into a query.
Boundary
Shared tables, feature stores, metrics layers and data products with several teams.
Symptom or risk
Unlisted consumers, such as a notebook, a feature pipeline or an export, break or, worse, silently read NULLs, and the failure surfaces days later in a model metric.
Exceptions
Private scratch tables with a single owner.
Trade-offs
Lineage is only as complete as its instrumentation; ad hoc SQL may be missing.
Pitfalls
Trusting table-level lineage for a column-level change.
Lessons and concepts
Claims and their sources
OpenLineage models Jobs that consume or produce Datasets, with Runs as occurrences of jobs and facets as extensible metadata, which allows dependency questions to be answered from collected events.