数据血缘采集实践：从 SQL 解析到算子级字段血缘构建

为什么表级血缘不够用

大多数数据治理平台在初期都只能做到表级血缘——知道 A 表的产出依赖 B 表和 C 表，但不知道 A 表的哪个字段来自 B 表的哪个字段、经过了什么计算。当数据质量问题发生时（比如某个指标值异常），表级血缘无法帮你定位到具体的加工逻辑。

字段级血缘解决的核心问题是：从任意一个字段出发，能完整追溯它的上游来源和下游影响。这要求血缘解析必须下沉到 SQL 的算子级别——不只是识别 FROM 和 JOIN，还要解析 SELECT、WHERE、GROUP BY、窗口函数、子查询等每种算子对字段的变换。

有赞在数据资产治理中实践了完整的元数据采集体系，其核心路径是：先通过 ANTLAR4 构建 SQL Parser 提取 SQL 脚本的结构化信息，再将解析结果转化为表/字段级别的血缘关系，最后通过采集 SDK 入库。这一实践覆盖了 Hive、MySQL、Kafka 等多种平台组件，基础元数据量达 10 万以上。

三步路径

第一步：SQL Parser 构建

构建 SQL Parser 是字段级血缘的基础。有赞的做法是基于 ANTLAR4 实现了一套自研 SQL 改写工具，在解析 SQL 的同时提取表名、字段名和算子结构。这一步的关键挑战在于 SQL 方言的多样性——HiveQL、MySQL SQL、Spark SQL 在语法上存在差异，需要针对性地扩展语法规则。

实际工程中，推荐的做法是：

• 优先覆盖高频 SQL 模式：先支持 SELECT-FROM-WHERE-GROUP BY、JOIN、子查询等 80% 场景的语法，再逐步扩展窗口函数、CTE、UNION 等复杂语法。
• 保留原始 SQL 位置信息：每个 AST 节点需携带源码行号和列号，方便后续的血缘映射和问题排查。
• 处理动态 SQL：对于通过变量拼接的 SQL（如 Airflow 模板），需要在运行时获取实际执行的 SQL 文本，静态解析无法覆盖。

第二步：算子级解析

拿到 SQL 的 AST 之后，需要逐算子追踪字段的变换关系。核心思路是为每种算子维护一个输入字段 → 输出字段的映射表：

• SELECT 算子：逐列表达式分析。SELECT a + b AS total 映射为 total ← a, b；SELECT UPPER(name) 映射为 name_upper ← name。
• JOIN 算子：记录 JOIN 条件涉及的字段和来源表，以及两侧字段的对应关系。
• 聚合算子：GROUP BY 字段保持不变，聚合函数的输入字段被标记为聚合来源（如 SUM(amount) 的输出字段依赖于 amount）。
• 窗口函数：解析 PARTITION BY 和 ORDER BY 子句中的字段依赖，以及窗口函数的输入字段。
• 子查询 / CTE：递归解析内部 SQL，将外层查询的字段依赖传递到最内层的源表字段。

MetaDataAssets 提供了字段级血缘的完整解决方案，通过独创的算子级解析技术将血缘解析准确率提升到 99% 以上，其核心思路与上述路径一致——不是简单地匹配表名和字段名，而是理解每个 SQL 算子对数据流的变换语义。

第三步：Hub 表行级裁剪

在大规模数据仓库中，存在大量公共 Hub 表（如用户维度表、指标汇总表）。这些表被数百个下游任务引用，如果不加裁剪，任何上游变更都会触发数百个下游任务的血缘告警，造成严重的"血缘泛化"问题。

行级裁剪的核心思路是：依据下游任务实际读取的字段和过滤条件，动态过滤掉无关的血缘路径。具体实现包括：

• 字段级裁剪：如果下游任务只读取 Hub 表的 user_name 和 region 两个字段，那么 Hub 表的其他 200 个字段的血缘路径被裁剪掉。
• 条件级裁剪：如果下游任务有 WHERE region = '华北' 的过滤条件，那么 region = '华南' 的数据路径可以被标记为"低影响"。
• 合并链路：当多个下游任务通过相同的字段口径访问 Hub 表时，将血缘链路合并为一条公共路径，避免重复展示。

有赞在实践中发现，经过行级裁剪后，血缘图的节点数可减少 60%~80%，影响分析的召回率保持不变但干扰率大幅下降。MetaDataAssets 同样强调行级裁剪能力，称其能将血缘收敛到"可用"的程度——低于 5% 的影响分析打扰率。

监控与质量保障

血缘采集不是一次性工程，需要持续的质量保障机制：

• 采集链路监控：对 SQL 解析服务的接口按核心/重要/一般分级告警，核心接口异常触发电话告警，一般异常触发邮件告警。
• 结果数据比对：定期比较当日采集的血缘数量与近 7 天均值，异常波动触发告警。
• 数据质量规则：定义无关联任务的表数量、无上下游的表数量等质量指标，通过自动化探查持续发现和修复血缘缺失。

数据血缘的价值最终体现在两个场景：影响分析（上游字段变更时快速定位受影响的下游报表和指标）和问题溯源（指标异常时从结果字段逐层追溯到源数据）。只有字段级、算子级的血缘精度，才能让这两个场景真正可用。