血缘分析核心概念：数据源、数据表、字段、ETL任务、数据流、依赖关系
做故障排查，你得先知道数据从哪来、到哪去、中间经历了什么。这就是血缘分析要回答的问题。
我刚开始接触数据治理时，觉得血缘分析就是个花架子——画几张漂亮的图，领导看了高兴。直到有一次线上报表延迟了整整6个小时，我盯着几百个ETL任务一个个排查，那种感觉，就像在黑暗里摸开关。后来我花了三天把整个链路的手工血缘图画出来，才发现问题出在一个不起眼的字段类型转换上。嗯，从那以后，我再也不敢小看血缘分析了。
这一章，我们把血缘分析的六个核心概念讲透。你理解了它们，就等于拿到了故障排查的钥匙。
数据源：一切数据的起点
数据源，说白了就是数据最初产生的地方。它可以是关系型数据库、日志文件、消息队列、API接口，甚至是Excel表格。
在血缘分析中，数据源是整条链路的起点。没有数据源，后面的所有分析都是空中楼阁。
关键点：数据源在血缘图中通常用绿色节点表示，代表“源头”。故障排查时，如果数据源本身出了问题，下游所有依赖都会跟着遭殃。
我遇到过最典型的场景：业务方说报表数据不对，我第一反应是ETL逻辑有bug。查了半天，最后发现是源数据库的连接池满了，数据根本没读进来。所以，排查故障时，永远先确认数据源是否正常。
数据表：数据的容器
数据表是结构化数据的基本存储单元。在血缘分析中，表是核心节点——它既是上游ETL的输出目标，又是下游任务的输入来源。
一张表可能被几十个任务同时读取，也可能由多个任务共同写入。这种多对多的关系，正是血缘分析要梳理的重点。
| 表类型 | 血缘中的角色 | 故障排查要点 |
|---|---|---|
| 源表 | 数据入口 | 检查数据是否完整、是否被误删 |
| 中间表 | ETL输出/输入 | 关注数据一致性、分区是否正常 |
| 结果表 | 最终输出 | 验证数据准确性、时效性 |
实战技巧：我习惯在血缘图中给每张表标注“最后更新时间”。故障发生时，一眼就能看出哪张表的数据“卡住”了。
字段：最细粒度的数据单元
字段级别的血缘分析，才是真正体现功力的地方。很多故障，表面上是表或任务的问题，根因却在字段上。
举个例子：上游表有个字段叫 user_id，类型是 VARCHAR(32)。下游ETL任务把它映射成 INT，结果某天源数据里出现了一个带字母的ID，任务直接报错。这种问题，表级别的血缘分析根本看不出来，只有字段级别的血缘才能定位。
注意：字段级别的血缘分析需要更精细的元数据采集。我曾经因为漏采了一个字段的转换逻辑，排查了整整两天。别偷懒，字段映射关系一定要记录完整。
ETL任务：数据的搬运工
ETL任务，就是负责把数据从A点搬到B点，中间可能做清洗、转换、聚合。在血缘分析中，ETL任务是连接数据源和数据表的桥梁。
每个ETL任务都有三个关键属性：输入、输出、逻辑。故障排查时，我们最关心的是“这个任务依赖哪些上游数据？”和“这个任务影响了哪些下游表？”
我曾经接手过一个系统，ETL任务之间互相依赖，形成了一个复杂的网状结构。有一次某个任务失败了，下游十几个任务全部挂掉。如果没有血缘分析，你根本不知道影响范围有多大。
数据流：数据流动的路径
数据流，就是数据从源头到终点的完整路径。它把数据源、ETL任务、数据表串联起来，形成一条或多条链路。
在故障排查中，数据流的价值在于：你可以沿着链路逐级排查，找到断点或异常点。
举个例子：报表A的数据来自中间表B，中间表B的数据来自ETL任务C，ETL任务C的数据来自源表D。如果报表A的数据不对，你就沿着这条链路反向排查：先看中间表B的数据对不对，再看ETL任务C有没有报错，最后看源表D的数据是否正常。
核心原则：数据流是故障排查的“导航地图”。没有它，你就是在迷宫里乱撞。
依赖关系：谁依赖谁，谁影响谁
依赖关系是血缘分析中最复杂、也最有价值的部分。它描述了数据节点之间的上下游关系。
依赖关系有两种：
- 直接依赖：任务A的输出直接作为任务B的输入
- 间接依赖：任务A的输出经过多层传递后影响任务B
故障排查时，间接依赖往往是最容易被忽略的。我遇到过这样的情况：一个底层表的字段类型变更，影响了三层之后的报表。变更的人觉得“只是改个字段类型，不影响业务”，结果报表挂了三天。
避坑指南：我曾经因为没梳理清楚依赖关系，上线了一个“小改动”，结果导致20多个下游任务全部失败。从那以后，我要求所有变更必须附带血缘影响分析报告。
知识体系总览
下面这张图，把六个核心概念的关系画清楚了。你把它记在脑子里，后面每一章都会用到。
六个概念，层层递进。数据源是起点，数据表和字段是存储单元，ETL任务是处理逻辑，数据流是路径，依赖关系是纽带。你掌握了它们，血缘分析就不再是抽象的概念，而是实实在在的排查工具。