血缘辅助问题定位
数据不对时最耗时间的往往不是修，而是找到“哪一次变更导致的”。血缘把这件事转成可检索的路径：从出问题的表出发看上游任务与最近代码变更，定位问题引入点；再看下游受影响清单，圈定需要回刷与通知的范围。配合任务运行记录与发布记录对齐时间线，通常能在半小时内把范围从“整条链路”收敛到“某次变更”。前提是血缘完整——动态 SQL 拼接出来的表往往解析不出依赖，这是最常见的盲区。
基本信息
| 上游用途 | 定位问题引入点：任务、DDL 变更、数据源异常 |
|---|---|
| 下游用途 | 评估影响面与需要回刷的范围 |
| 时间线 | 任务运行记录与代码发布记录对齐 |
| 常用工具 | 元数据平台血缘图、调度平台依赖图、发布记录 |
| 前提 | 血缘完整，动态 SQL 是典型盲区 |
典型使用场景
- 报表反馈数字异常，从报表汇总表回溯到明细表与源表
- 确认某次代码发布影响哪些表，做上线前评估
- 上游表结构变更（字段删除、类型调整）后排查下游报错
- 指标对不上时确认两条指标链路是否真正独立
- 事故复盘：还原从异常发生到被发现的完整链路
排查时间线示例
排查时间线示例
10-11 09:00 报表反馈支付金额异常（比昨日低 30%）
10-11 09:10 查血缘：金额来自 dwd_trade_order_detail_di → dws_trade_category_1d
10-11 09:20 查上游任务与发布记录：08:30 上线了一版过滤条件变更
10-11 09:30 确认该变更误过滤掉退款冲正单，导致金额偏低
10-11 09:40 回滚变更，回刷当日分区（回刷前先冻结增量写入）
10-11 10:20 复检行数与金额勾稽通过，通知下游重跑并记录变更上下游排查动作
| 方向 | 找什么 | 常见结论 | 后续动作 |
|---|---|---|---|
| 上游 | 最近的任务失败、DDL 变更、发布记录 | 问题由某次变更引入 | 回滚或修数据并回刷 |
| 上游 | 源系统抽取量与耗时 | 源头数据缺失或延迟 | 联系上游并等待补数 |
| 下游 | 依赖该表的任务与报表清单 | 影响面超出预期 | 通知相关方并排定重跑顺序 |
| 横向 | 同口径的另一条链路 | 两条链路出现差异 | 先对口径再查数据 |
把每次发布记录与任务运行记录对齐做成固定动作：出问题时能立刻回答“当时有谁改过什么”，定位速度会明显提升。
血缘不完整时只凭经验猜上游，容易修错表：改了不相关的任务，真问题仍在，还多出一次无谓变更。
字段级血缘比表级更省事：字段改名或类型变更时，表级血缘只能给出“这张表受影响”，字段级能直接列到具体列与任务。