一、数据血缘基础：从“数据从哪来”说起

做数据治理这些年，我经常被问到同一个问题：“这个报表里的数字到底准不准？”
说实话，以前我很难回答。数据经过 ETL、多层聚合、业务逻辑加工，早就面目全非了。
直到我开始认真对待数据血缘，才真正有了底气。

这一章，我们就聊聊数据血缘最基础的东西。
说白了，就是搞清楚数据从哪来、经过谁、变成什么样、最后去了哪。

1.1 什么是数据血缘

数据血缘，英文叫 Data Lineage。
它记录的是数据从产生到消亡的完整路径。
你想想看，一张报表里的销售额，可能来自订单表、经过清洗、做过汇总、还被业务规则修正过。
血缘就是把这些环节串起来的一张“地图”。

我个人习惯把血缘分成两类：

• 表级血缘：表与表之间的依赖关系。比如 A 表 → B 表 → C 表。
• 字段级血缘：字段级别的映射。比如 A.col1 + A.col2 → B.col3。

我在项目中遇到过最典型的场景：
业务方说“这个指标不对”，我打开血缘图，一眼就看到中间有个字段映射错了。
没有血缘，你只能一层层翻代码，翻到崩溃。

1.2 血缘分析的价值

很多人觉得血缘分析就是个“锦上添花”的东西。
其实不然。我做过好几个数据治理项目，血缘分析的价值体现在三个层面：

价值维度	具体说明	我见过的真实案例
问题溯源	数据出问题时，快速定位根因	某电商大促期间，GMV 报表异常，靠血缘 10 分钟定位到上游一个字段被截断
影响分析	修改上游表时，评估下游影响范围	有一次要改订单表的字段类型，血缘图告诉我下游有 37 个任务会受影响
合规审计	满足监管对数据来源的追溯要求	金融客户做数据安全审计，血缘是必过项

嗯，这里要注意一点：
血缘分析的价值不是“一次性”的。它需要持续维护。
我曾经见过一个团队，花三个月把血缘建好了，结果半年后没人维护，全废了。

1.3 数据血缘 vs 数据地图 vs 数据目录

这三个概念经常被混在一起说。
我刚开始做数据治理时也分不清，后来踩过坑才明白它们的区别。

咱们直接看对比：

维度	数据血缘	数据地图	数据目录
核心关注	数据流转过程	数据分布位置	数据资产清单
粒度	字段级 / 表级	表级 / 库级	表级 / 字段级
典型用途	溯源、影响分析	找数据在哪	查数据是什么
动态性	动态（记录过程）	相对静态	相对静态
用户	数据工程师、分析师	所有数据使用者	数据管理者、分析师

说白了：

• 数据目录是“有什么数据” —— 像图书馆的索引卡。
• 数据地图是“数据在哪” —— 像图书馆的楼层导引。
• 数据血缘是“数据怎么来的” —— 像一本书的参考文献列表。

我遇到过最典型的误解：
有人觉得有了数据地图，就不需要血缘了。
其实完全不是一回事。地图告诉你“订单表在 Hive 的 ods 层”，但血缘告诉你“订单表里的 amount 字段是从三个源表聚合来的”。
这两个信息，缺一不可。

1.4 数据血缘的核心要素

一个完整的数据血缘描述，应该包含哪些东西？
我总结了一个“五要素”模型：

1. 数据源：数据从哪里来（表名、字段名、系统来源）
2. 变换过程：经过了什么处理（SQL、脚本、ETL 任务）
3. 数据目标：数据去了哪里（下游表、报表、API）
4. 执行信息：谁做的、什么时候做的、跑了多久
5. 依赖关系：上下游之间的依赖顺序

举个例子，一个简单的血缘描述：

源表：ods.order_info (字段: order_id, amount, create_time)
↓
变换：ETL 任务 dwd_order_daily (SQL: SELECT order_id, SUM(amount) FROM ods.order_info GROUP BY order_id)
↓
目标表：dwd.dwd_order_summary (字段: order_id, total_amount)
↓
执行信息：调度系统 Airflow, 每天凌晨 2 点, 运行时长 15 分钟

你看，有了这些信息，任何一环出问题，你都能快速定位。

1.5 本章知识体系总览

为了让你对本章内容有个整体印象，我画了一张图：

这张图把本章的核心内容串起来了。
从“什么是数据血缘”出发，到“血缘分析的价值”，再到“概念对比”，最后落到“五要素模型”。
你学完这一章，应该能回答三个问题：

• 数据血缘是什么？
• 它有什么用？
• 它跟数据地图、数据目录有什么区别？

嗯，这些基础打牢了，后面讲血缘采集、解析、可视化的时候，你才不会晕。