Approach (summary): prioritize fields by combined business impact (downstream consumers / dashboard usage / revenue-sensitive metrics) and technical feasibility (cost to backfill, data availability, risk). I'll measure impact with SQL, estimate compute/cost, then apply a rubric that yields a ranked backfill plan.1) Measure scope and current NULLssql
-- count nulls per column in analytics table
SELECT
count(*) AS total_rows,
SUM(CASE WHEN col_a IS NULL THEN 1 ELSE 0 END) AS col_a_nulls,
SUM(CASE WHEN col_b IS NULL THEN 1 ELSE 0 END) AS col_b_nulls
FROM analytics.events;
2) Measure downstream usage: dashboards & modelssql
-- number of dashboard tiles referencing each column (from metadata)
SELECT column_name, COUNT(DISTINCT dashboard_id) AS dashboards
FROM catalog.column_references
WHERE table_name='analytics.events'
GROUP BY column_name;
-- number of dependent models/jobs (e.g., dbt lineage or job deps)
SELECT column_name, COUNT(DISTINCT model_name) AS dependent_models
FROM lineage.column_usage
WHERE table_name='analytics.events'
GROUP BY column_name;
3) Measure actual user-impact: dashboard queries & alertssql
-- recent query volume that filters/aggregates by column
SELECT column_name, SUM(query_count) AS queries_last_30d
FROM metrics.column_query_stats
WHERE table_name='analytics.events' AND ts >= now() - INTERVAL '30 days'
GROUP BY column_name;
4) Estimate backfill cost- Estimate rows to update = null_count- Estimate per-row compute cost: measure sample using EXPLAIN ANALYZE or run small batch and extrapolate.sql
-- sample timing for updating 1k rows
EXPLAIN ANALYZE
UPDATE analytics.events
SET col_a = computed_value
WHERE col_a IS NULL
LIMIT 1000;
- Compute cost estimate = (time_per_1k / 1000) * null_count * cost_per_cpu_sec- Storage I/O / vacuum costs should be added for large updates.5) Decision rubric (score 0-5 each; prioritize highest total)- Business Impact (weight 0.5): dashboards_count, downstream_models, revenue_impact, SLA risk- User Impact (weight 0.2): active_query_volume, alert_breakage- Technical Feasibility (weight 0.2): availability of source data to reconstruct, complexity of transformation- Cost / Risk (weight 0.1): estimated compute/time, locking riskCompute final_score = 0.5*BI + 0.2*UI + 0.2*TF + 0.1*(5 - CostScore)6) Example decision steps- Score each column using above queries.- Pick top N where final_score above threshold and cost/time fits maintenance window.- Run backfill in batches; test on dev; run audits comparing pre/post aggregates.- Communicate schedule and rollback plan to stakeholders.Edge considerations: for critical metrics consider backfilling historical snapshots; for low-feasibility fields prefer downstream workarounds (e.g., change dashboard to use alternative column) before heavy backfill.