Understanding Data Impact
This walkthrough guides you through using lineage to understand the impact of changes before making them.
Scenario
You need to make changes to a data product (schema modification, deprecation, or retirement). Before proceeding, you want to understand who and what will be affected.
Step 1: Open the Product Lineage
Navigate to the Data Product you plan to modify and select the Lineage tab. This view visualizes both upstream and downstream relationships, providing an immediate overview of dependencies.
Step 2: Identify Downstream Consumers
Expand Downstream Lineage
Focus on the nodes to the right of your product. Click the expand controls to reveal deeper dependencies, or use depth selectors (like :+3) to view up to three levels downstream at once.
Document All Consumers
For each downstream product, note the Product Name to understand what is affected, the Steward/Owner to know whom to notify, and the Criticality to assess the potential impact of your changes.
Export or screenshot the lineage for reference in your change request.
Step 3: Use Global Lineage for Complex Analysis
For a broader analysis, navigate to Data Lineage → Global View. You can use dbt-style selectors to explore complex chains. For example, product_name+ selects the product and all its downstream dependencies, while +product_name+ reveals the full upstream and downstream chain.
Example: Schema Change Impact
Using current_product+ will show you every asset that depends on your product, allowing for a comprehensive impact assessment.
Step 4: Assess Impact by Product
For each affected downstream product, check its Criticality by viewing its governance roles and any dependent contracts. Also review Quality Dependencies—downstream checks might fail after your change, so plan for post-change monitoring.
Step 5: Identify Stakeholders
Build a Notification List
Construct a list of people to notify: Stewards (found in the Governance tab) should be your primary contact, Owners must approve major changes, and Active Users (visible in access request history) should be warned of potential disruptions.
Check for Contracts
Review the Contracts tab to see if any SLAs might be breached by your changes. Contract owners usually require special notification and potentially a renegotiation of terms.
Step 6: Plan the Change
Create a Change Request
Document your planned change, detailing exactly what is changing, why it is necessary, the proposed timeline, and a rollback plan in case of issues.
Staged Rollout
Consider a phased approach: start by notifying stakeholders, then add deprecation warnings. Proceed to make the change, monitor for issues, and finally remove the deprecated elements once confirmed safe.
Step 7: Communicate
Before the Change
Send notifications to all stewards and owners of downstream products. Include details on what is changing, the timing, any actions they need to take, and contact information for questions.
Sample Notification
Subject: Upcoming Schema Change to [Product Name]
We are modifying [specific change] on [date].
Impact: This may affect products downstream including [list].
Action Needed: Please review your dependencies and update references if needed.
Questions: Contact [your email]
Create a Meeting if Needed
For major changes, schedule a governance meeting with affected stakeholders. Use the meeting notes to track decisions and ensure alignment.
Step 8: Execute and Monitor
During the Change
Execute the modification, triggering any necessary resyncs. identifying updates to product documentation immediately to reflect the new state.
After the Change
Monitor downstream quality checks for failures and watch for new issues being reported. Follow up with the stakeholders you notified to ensure the transition was smooth.
Real-World Examples
Example 1: Renaming a Column
When renaming orders.customer_id to orders.cust_id, use lineage to find all downstream references. Notify stewards of the change and date, provide a migration window, execute the rename, and then monitor for broken dependencies.
Example 2: Deprecating a Product
To retire a legacy_metrics table, generate the full downstream list and identify a replacement product. Issue a 30-day deprecation notice, track the migration progress via issues, and archive the table only when no active dependencies remain.
Key Takeaways
Always check lineage before changes because unknown dependencies can cause incidents. Communicate early to give stakeholders time to prepare, monitor after changes as problems may not be immediate, and document the process so future changes benefit from history.