血缘核心概念：表级血缘、字段级血缘、ETL血缘、报表血缘

数据血缘这东西，说白了就是给数据做"身世调查"。你得知道一张表从哪来、经过谁的手、最后变成了什么。我做了这么多年数据治理，见过太多因为血缘不清导致的线上事故——凌晨三点被电话叫醒去修报表，那种滋味可不好受。

今天咱们就把血缘的四个核心层次掰开揉碎讲清楚。你想想看，如果连血缘的粒度都分不清，后面做治理就是空中楼阁。

一、表级血缘：最粗的粒度，但最常用

表级血缘，就是看表与表之间的依赖关系。比如一张 dwd_sales_order 依赖 ods_order 和 dim_product。它不关心具体是哪个字段，只关心"谁用了谁"。

我在项目中遇到过一件事：业务方说"我要下线这张表"，我查了表级血缘发现没有下游依赖，就同意了。结果第二天报表跑不出来——原来有个存储过程直接读了这张表的物理文件，根本没走血缘采集。嗯，这里要注意，表级血缘只能覆盖显式依赖。

二、字段级血缘：真正的硬核功夫

字段级血缘，追踪的是"这个字段的值是从哪个字段算出来的"。比如 dwd_sales.amount 来自 ods_order.price * ods_order.quantity。这才是数据治理的深水区。

对比维度	表级血缘	字段级血缘
粒度	表	字段
采集难度	低（解析SQL FROM子句即可）	高（需要解析表达式、函数、CASE WHEN）
存储量	小	大（字段组合爆炸）
业务价值	中（知道谁依赖谁）	高（知道数据怎么算出来的）

我曾经踩过一个坑：某张报表的 profit 字段突然变成负数，查了表级血缘发现上游没变。后来用字段级血缘一追，发现是某个ETL脚本把 cost 和 revenue 的加减顺序写反了。字段级血缘，就是这种"破案"的利器。

三、ETL血缘：过程即血缘

ETL血缘，关注的是"数据在加工过程中经历了什么"。它比字段级血缘多了一层——不仅知道字段映射，还知道经过了哪些算子、过滤条件、聚合逻辑。

举个例子：

-- 原始SQL
INSERT INTO dws_daily_sales
SELECT 
    order_date,
    SUM(amount) AS total_amount
FROM dwd_sales
WHERE status = 'PAID'
GROUP BY order_date;

ETL血缘会记录：

• 输入：dwd_sales（全表扫描）
• 过滤：status = 'PAID'
• 聚合：SUM(amount) + GROUP BY order_date
• 输出：dws_daily_sales.total_amount

我个人习惯把ETL血缘叫做"过程血缘"。它最大的价值在于：当数据质量出问题时，你能定位到具体是哪个环节出了问题。是过滤条件错了？还是聚合函数写错了？一目了然。

四、报表血缘：离用户最近的一层

报表血缘，就是看报表上的每个指标、每个图表，对应的是哪张表、哪个字段、哪个ETL过程。它是血缘治理的"最后一公里"。

你想想看，业务方看到的是一张漂亮的折线图，但背后可能涉及：

• 3张事实表
• 5个维度表
• 2个聚合层
• 1个前端计算逻辑

报表血缘要做的，就是把这条链路完整串起来。

报表元素	血缘链路示例
销售额折线图	报表 → dws_daily_sales → dwd_sales → ods_order
毛利率仪表盘	报表 → dws_profit → (dwd_revenue + dwd_cost) → ods_finance
客户留存表	报表 → ads_customer_retention → dws_user_behavior → dwd_log

我在项目中遇到过最头疼的事：业务方说"这个月的毛利率不对"，我查了字段级血缘发现数据没错，ETL血缘也没问题。最后发现是报表前端写死了某个过滤条件——这就是报表血缘缺失的代价。

五、四种血缘的关系图谱

这四种血缘不是孤立的，它们构成了一个金字塔结构：

从这张图你能看出来：

• 表级血缘是地基，必须稳
• 字段级血缘是骨架，决定精度
• ETL血缘是肌肉，记录过程
• 报表血缘是皮肤，直面用户

我个人建议的落地路径是：先花2周把表级血缘跑通，再用1个月攻坚字段级，ETL血缘可以跟着调度系统一起做，报表血缘最后补。别想着一步到位——我见过太多团队因为追求完美血缘，结果半年过去了连一张表都没跑通。