2. 数据血缘基础：从哪来、到哪去、怎么查

数据血缘，说白了就是一张“数据从哪里来、经过谁的手、变成了什么”的地图。我刚开始做数据治理时，经常被业务问：“这个报表里的销售额，到底是从哪个系统来的？”那时候我只能翻半天文档，还不一定准。后来我才意识到，缺的就是血缘。

2.1 数据血缘的定义

数据血缘（Data Lineage）记录的是数据从产生、流转、加工到最终消费的完整路径。它不只是画一条线，而是把每个环节的输入、输出、转换逻辑都记录下来。

举个例子：你看到一张报表上的“本月新增用户数”。这个数字可能来自用户注册表，经过ETL清洗，再聚合到数据仓库，最后被BI工具拉取。血缘就是把这些步骤串起来，告诉你每一步发生了什么。

2.2 血缘的粒度：从粗到细

血缘不是只有一种粒度。根据你的需求，可以分为三个层级。我建议团队先做粗粒度，再逐步细化，否则一开始就做字段级，容易陷入细节出不来。

粒度	描述	典型场景
系统级	记录数据在系统之间的流转，比如从CRM到数仓	系统迁移、接口变更影响分析
表级	记录数据在表之间的依赖关系，比如A表→B表	表结构变更、ETL任务调整
字段级	记录字段级别的映射和转换，比如A.col1 → B.col2	字段类型变更、数据质量排查

你想想看，如果只是系统级血缘，你只知道数据从CRM到了数仓，但不知道具体是哪个表、哪个字段。反过来，字段级血缘虽然最精确，但构建成本也最高。我个人习惯是：核心业务表做字段级，普通表做表级，系统级只用来做全局概览。

2.3 血缘的构建方式：静态解析 vs 动态追踪

构建血缘主要有两种方式。我两种都用过，各有各的坑。

2.3.1 静态解析

静态解析，就是通过分析SQL脚本、存储过程、ETL配置文件等静态代码，来推导数据依赖关系。它不跑数据，只读代码。

优点：

• 速度快，不需要等待数据执行
• 可以覆盖历史脚本
• 对系统性能无影响

缺点：

• 只能解析结构化的代码，动态SQL、存储过程里的条件分支容易漏
• 如果代码不规范，解析结果可能不准
• 无法捕获运行时才确定的表名或字段名

-- 静态解析示例：分析这条SQL，可以推导出 target_table.col_a 依赖 source_table.col_b
INSERT INTO target_table (col_a, col_c)
SELECT col_b, col_d
FROM source_table
WHERE col_e > 100;

2.3.2 动态追踪

动态追踪，是在数据实际执行时，通过拦截SQL执行计划、日志或使用数据库钩子，来捕获真实的依赖关系。它不猜，只看实际发生了什么。

优点：

• 准确度高，能捕获所有运行时依赖
• 能处理动态SQL、临时表、条件分支
• 可以记录数据量、执行时间等运行时信息

缺点：

• 对系统有性能开销，尤其是高并发场景
• 需要提前部署采集代理
• 无法追溯历史数据

2.3.3 两种方式对比

维度	静态解析	动态追踪
准确性	中等，依赖代码质量	高，捕获实际执行
性能影响	无	有，需控制范围
覆盖范围	结构化代码	所有执行路径
历史追溯	可以	不能
实施成本	低，工具成熟	高，需定制开发

我个人的建议是：静态解析做基础，动态追踪做补充。先用静态解析快速搭出血缘框架，然后对核心链路开启动态追踪来校准。这样既快又准。

2.4 血缘构建方式对比图

下面这张图展示了两种构建方式的流程差异，以及它们各自覆盖的范围。

2.5 避坑指南

做血缘构建时，有几个坑我踩过，分享给你：

• 不要追求100%覆盖：我曾经试图把所有临时表、中间表都纳入血缘，结果维护成本比收益还高。建议只覆盖核心链路，覆盖率做到80%就够用。
• 注意循环依赖：有些ETL脚本会写回源表，形成循环。静态解析很难发现，动态追踪能直接暴露。遇到这种情况，需要和业务确认是否合理。
• 血缘不是一次性的：代码在变，数据流在变，血缘也要持续更新。我建议每周自动扫描一次，每月人工复核一次。
• 字段级血缘别硬做：如果SQL里用了大量函数嵌套、CASE WHEN，字段级解析会非常复杂。这时候可以退而求其次，先做表级，等工具成熟了再细化。