字段血缘的核心概念：字段级血缘、表级血缘、ETL血缘、应用层血缘

聊数据血缘，很多人一上来就画大图，什么「全链路数据地图」之类的。我个人习惯，先把血缘拆成四个层次来看。你想想看，一个数据从业务系统产生，到最终出现在报表里，中间经过了多少跳转？每一跳的血缘粒度都不一样。

我在项目中遇到过不少团队，上来就说「我们要做血缘分析」，结果连字段级和表级都没分清楚，最后搞出来的东西既不能追溯问题，也没法做影响分析。嗯，这里我们先把这个基础打牢。

2.1 字段级血缘：最细粒度的数据追溯

字段级血缘，说白了就是「一个字段从哪来，到哪去」。它是血缘分析的最小单元，也是最有价值的一层。

举个例子，你看到一张报表里有个「客户总消费金额」字段，它可能来自：

• 订单表的 amount 字段经过 SUM 聚合
• 加上退款表的 refund_amount 做减法
• 再乘以一个汇率转换系数

字段级血缘就要把这些细节全部记录下来。我建议你在做字段级血缘时，至少记录以下信息：

属性	说明	示例
源字段	原始数据中的字段名	ods_order.amount
目标字段	最终输出的字段名	dws_customer.total_amount
转换逻辑	字段经过的运算或函数	SUM(amount) - SUM(refund)
数据质量规则	字段级别的校验条件	amount > 0

2.2 表级血缘：宏观的数据流转脉络

表级血缘关注的是表与表之间的依赖关系。它不像字段级那么细，但胜在宏观、清晰。

你想想看，一个数据仓库里可能有几百张表，如果每张表都画字段级血缘，那图就乱成一锅粥了。表级血缘的作用，就是先给你一张「地图」，让你知道数据大概是怎么流的。

表级血缘通常记录：

• 源表 → 目标表的依赖关系
• ETL任务的输入输出表
• 表之间的数据量级关系

下面这张图展示了字段级血缘和表级血缘的关系：

2.3 ETL血缘：数据加工的过程记录

ETL血缘，关注的是「数据是怎么被加工的」。它记录的是从源数据到目标数据的整个转换过程，包括脚本、任务、调度等信息。

我个人习惯把ETL血缘分成三个部分来看：

1. 输入血缘：ETL任务读取了哪些表、哪些字段
2. 转换血缘：数据经过了哪些清洗、聚合、关联操作
3. 输出血缘：ETL任务写入了哪些表、哪些字段

我曾经在一个项目中，发现某个ETL任务每天跑3小时，严重影响下游报表时效。通过ETL血缘分析，发现这个任务做了大量不必要的全表扫描——因为开发人员复制了上一个任务的脚本，忘了加分区过滤。这就是ETL血缘的价值：不只是看数据流，还能看性能问题。

2.4 应用层血缘：数据消费的最后一公里

应用层血缘，说白了就是「数据最终被谁用了」。它记录的是数据从数据仓库到报表、API、数据产品等消费端的映射关系。

这一层经常被忽略，但恰恰是最容易出问题的。你想想看，一个报表里的指标算错了，业务部门来找你，你查了半天发现是报表层自己做了额外的计算，跟数据仓库没关系。这就是应用层血缘要解决的问题。

应用层血缘通常包含：

消费端类型	血缘记录内容	常见问题
报表	报表名称、指标来源、过滤条件	报表层二次计算导致数据不一致
API	接口路径、返回字段、数据源表	接口字段变更未通知下游
数据产品	产品名称、数据模型、刷新频率	产品依赖的表被下线

2.5 四个层次的关系

这四个层次不是孤立的，它们构成了一个完整的血缘体系：

• 字段级血缘是基础，提供最细粒度的追溯能力
• 表级血缘是骨架，展示整体的数据流转脉络
• ETL血缘是过程，记录数据加工的具体逻辑
• 应用层血缘是终点，追踪数据消费的最终去向

在实际项目中，我建议你从表级血缘入手，先建立整体的数据流转地图。然后逐步细化到字段级和ETL血缘，最后再补齐应用层。别想着一步到位，那会把自己累死。