3、数据修复场景概览：常见数据质量问题类型、数据修复的典型流程、血缘分析在修复中的定位
各位同学，今天我们来聊聊数据修复这个“脏活累活”。说实话，我在数据治理这行摸爬滚打了十几年，见过太多因为数据问题导致线上事故的案例。有一次，某电商大促当天发现订单金额对不上，整个技术团队通宵排查，最后发现是上游一个字段类型改了，下游没感知。嗯，这就是典型的“数据静默错误”。
所以这一章，我想把数据修复的“家底”给你翻一翻。咱们先看问题长什么样，再讲修复流程，最后重点说说——血缘分析在这个链条里到底扮演什么角色。
3.1 常见数据质量问题类型
数据质量问题，说白了就是“数据不符合预期”。我习惯把它们分成六大类，你对照一下自己项目里遇到过哪些：
| 类型 | 典型表现 | 我见过的真实案例 |
|---|---|---|
| 完整性缺失 | 字段为空、记录丢失、外键悬空 | 某银行客户信息表，身份证号缺失率高达15% |
| 准确性偏差 | 数值错误、单位不一致、精度丢失 | 某报表系统把“万元”当“元”累加，差了两个数量级 |
| 一致性冲突 | 同一实体在不同系统取值不同 | CRM和ERP里同一个客户的“省份”字段，一个写“北京”，一个写“北京市” |
| 时效性过期 | 数据未及时更新、延迟到达 | 某实时风控系统，特征数据延迟了30分钟，导致误放过欺诈交易 |
| 唯一性重复 | 主键冲突、重复记录 | 某用户画像表，同一个用户ID出现了3条不同记录 |
| 规范性违规 | 格式不符、编码错误、超出枚举范围 | 日期字段混用“2024-01-01”和“2024/01/01” |
核心观点： 80%的数据修复工作，其实是在处理前两类——完整性和准确性问题。但真正难搞的，是那些“看起来对，实际上错”的静默错误。
3.2 数据修复的典型流程
数据修复不是拍脑袋改数据。我建议你记住这个五步法，我在多个大厂的数据治理项目中都用它：
- 问题发现与定级——通过质量监控规则或业务反馈，定位异常数据，评估影响范围（P0/P1/P2）。
- 根因分析——追查数据从哪来、经过哪些转换、在哪个环节出错。这一步最耗时，也是血缘分析的主战场。
- 修复方案设计——确定是回刷历史数据、补录缺失值、还是修正ETL逻辑。要评估对下游的影响。
- 修复执行与验证——在隔离环境执行修复，比对修复前后的数据差异，确认无误后上线。
- 复盘与预防——更新质量规则、补充监控点、优化数据链路，防止同类问题再次发生。
我的经验： 很多团队在第二步“根因分析”上花的时间，占了整个修复周期的60%以上。为什么？因为数据链路太长了，手动追查就像在迷宫里找出口。这时候，血缘分析的价值就体现出来了。
你想想看，如果没有血缘关系图，你要怎么查一个字段的源头？打开几十个SQL脚本，一个一个看字段映射？我曾经在一个项目里，为了查一个“用户等级”字段的异常，翻了17个ETL任务，花了整整两天。后来上了血缘分析工具，同样的排查，10分钟搞定。
3.3 血缘分析在修复中的定位
好，现在咱们聊聊核心问题：血缘分析在数据修复里到底干什么用？
我用一句话概括：血缘分析是数据修复的“导航地图”和“影响雷达”。
具体来说，它有三个关键定位：
- 定位病灶——从异常数据出发，反向追溯数据流经的所有节点，快速定位问题源头是哪个表、哪个字段、哪个ETL步骤。
- 评估波及范围——从问题源头正向推导，列出所有受影响的上下游表、报表、API、模型，避免“修了一个坑，炸了一片路”。
- 验证修复效果——修复完成后，通过血缘链路比对修复前后的数据流向，确保所有下游节点都得到了正确数据。
我画了一张图，帮你理解血缘分析在修复流程中的位置：
避坑指南： 我曾经在一个项目中，只做了反向溯源就匆忙修复，结果修复后把下游一个实时报表搞崩了。为什么？因为没做正向影响分析。记住：修复一个数据问题，至少要影响3层下游——直接消费层、聚合层、展示层。缺一层都可能出事故。
最后，我想强调一个观点：血缘分析不是数据修复的“可选配置”，而是“基础设施”。没有血缘分析，你就像在黑暗里修水管——只能靠摸，靠猜，靠运气。有了它，你才能做到“看得清、修得准、影响可控”。