4. 数据血缘解析：血缘的粒度、解析原理与构建方式

数据血缘，说白了就是数据从哪来、到哪去、中间经历了什么。很多团队做资产目录做到一半，发现字段对不上、报表数据对不齐，回头一查——血缘没打通。嗯，这块确实是硬骨头，但也是数据治理的核心能力。

我个人习惯把血缘分成三个维度来讲：粒度、解析原理、构建方式。咱们一个一个拆开看。

4.1 血缘的粒度：表级 vs 字段级

先问个问题：你需要的血缘是「知道这张表从哪来」就够了，还是必须精确到「这个字段是从哪个表的哪个字段计算出来的」？

这就是表级血缘和字段级血缘的区别。

维度	表级血缘	字段级血缘
粒度	表与表之间的依赖关系	字段到字段的映射与转换
典型场景	数据链路梳理、影响分析	问题溯源、合规审计、数据质量
解析难度	低，SQL 中提取表名即可	高，需要解析表达式、函数、子查询
存储开销	小	大，字段级关系可能呈指数增长
维护成本	低	高，SQL 变更后需重新解析

举个例子，一条简单的 SQL：

CREATE TABLE dws_sales_summary AS
SELECT
    a.order_id,
    a.amount * b.discount_rate AS final_amount,
    c.user_name
FROM ods_orders a
JOIN dim_discount b ON a.discount_id = b.id
JOIN dim_user c ON a.user_id = c.id;

表级血缘只需要记录：dws_sales_summary 依赖 ods_orders、dim_discount、dim_user。

字段级血缘就要精确到：final_amount 来自 a.amount 和 b.discount_rate 的乘积，user_name 直接来自 c.user_name。

4.2 解析原理：SQL 解析 vs 日志解析

血缘怎么来的？两种主流方式：SQL 解析和日志解析。各有各的适用场景，也各有各的坑。

4.2.1 SQL 解析

这是最直接的方式。你拿到 ETL 脚本、视图定义、报表查询，用解析器把 SQL 拆成抽象语法树（AST），然后从中提取表名、字段名、表达式关系。

常用的解析工具：

• Antlr4：通用解析器生成工具，社区有现成的 SQL 语法文件
• Druid SQL Parser：阿里巴巴开源，对 MySQL、Oracle、PG 支持较好
• Calcite：Apache 项目，适合深度解析和优化
• sqlparse：Python 轻量级库，适合快速原型

解析流程大致如下：

SQL 文本 → 词法分析 → 语法分析 → AST → 遍历 AST → 提取血缘关系

4.2.2 日志解析

有些场景你拿不到 SQL——比如用的是商业 BI 工具、或者 ETL 工具不暴露脚本。这时候就得靠日志解析了。

原理很简单：数据库或计算引擎在执行 SQL 时，会记录审计日志、执行计划、或者 Query Profile。从这些日志里，可以反推出数据的流向。

常见的日志来源：

• 数据库审计日志：记录谁在什么时间执行了什么 SQL
• Spark / Flink 执行计划：包含完整的算子链路
• Hive / Presto 的 Query Profile：记录了输入输出表、读写字节数
• Kafka Connect / CDC 日志：记录数据在 topic 之间的流转

对比维度	SQL 解析	日志解析
数据来源	ETL 脚本、视图定义、查询语句	执行日志、审计日志、Profile
解析精度	高，可到字段级	中，通常只能到表级
实时性	离线，脚本变更后需重新解析	可实时，日志产生即解析
覆盖范围	仅限有脚本的场景	所有执行过的查询都能覆盖
典型工具	Antlr4、Druid、Calcite	Flume、Logstash、自研解析器

4.3 手动构建 vs 自动构建

血缘怎么建？两条路：手动画、自动跑。我见过不少团队在这上面纠结很久，其实核心就一句话——自动构建是目标，手动构建是起点。

4.3.1 手动构建

说白了就是靠人。业务分析师或者数据工程师，用 Excel、Draw.io、或者资产目录平台的手动编辑功能，一条线一条线地画出血缘关系。

适用场景：

• 数据链路简单，表数量在 50 张以内
• 核心报表或监管报送，需要人工确认血缘准确性
• 自动解析覆盖不到的自定义流程（比如人工导入导出）

4.3.2 自动构建

自动构建就是靠解析器定时扫描 SQL 脚本、调度系统、日志文件，自动生成血缘关系并更新到资产目录中。

典型的自动构建流程：

1. 采集：从 Git、调度平台、数据库审计日志中拉取 SQL 和日志
2. 解析：用解析器提取血缘关系
3. 去重合并：多条 SQL 可能产生相同的血缘关系，需要合并
4. 版本管理：记录每次变更的时间点和版本号
5. 写入图谱：将血缘关系写入图数据库或关系型存储

自动构建的成熟度可以分为几个阶段：

阶段	能力	典型特征
L1 基础	表级血缘自动采集	能识别 INSERT、CREATE AS SELECT 中的表依赖
L2 进阶	字段级血缘自动解析	能解析 SELECT 列表中的字段映射和简单表达式
L3 高级	复杂表达式与函数解析	能处理 CASE WHEN、窗口函数、UDF
L4 智能	增量解析与变更感知	只解析变更的部分，自动识别血缘断裂

4.4 知识体系总览

下面这张图把本章的核心知识点串起来了，你可以对照着梳理自己的血缘建设思路。

4.5 落地建议

最后聊点实际的。如果你现在要从零开始构建数据血缘，我会建议你按这个顺序来：

1. 先盘点：梳理现有 ETL 脚本、视图、报表查询，看看 SQL 覆盖度有多高
2. 选解析器：用 100 条典型 SQL 测试解析成功率，选一个最适合你技术栈的
3. 做表级血缘：快速上线，让团队看到效果，建立信心
4. 补日志解析：覆盖那些拿不到 SQL 的黑盒场景
5. 下钻到字段级：针对核心链路和问题频发的表，做字段级解析
6. 建立变更感知：接入 CI/CD 或调度系统，SQL 变更后自动触发重新解析