📚 课程目录第4章血缘解析技术原理

4、血缘解析技术原理：SQL解析、ETL脚本解析、存储过程解析、血缘构建模型

血缘解析，说白了就是让机器读懂数据是怎么流动的。很多同学觉得这步就是写几个正则表达式，把表名和字段名摘出来就行。嗯，我刚开始也这么想，直到被一个嵌套了八层的子查询教做人。

这一章，我把自己在多个项目中踩过的坑、总结的经验，拆成四个部分来讲：SQL解析、ETL脚本解析、存储过程解析，以及最后的血缘构建模型。你想想看，如果连解析这关都过不了，后面的血缘可视化、影响分析全都是空中楼阁。

4.1 SQL解析：血缘解析的基石

SQL解析是整个血缘解析的核心。我见过不少团队，上来就写正则硬匹配，结果遇到CTE、子查询、CASE WHEN就崩了。说实话，正则只能处理最表层的东西，真正的SQL解析需要语法树级别的分析。

4.1.1 解析流程

我个人习惯把SQL解析分成三步走：

词法分析：把SQL字符串拆成一个个，比如SELECT、FROM、WHERE、表名、字段名
语法分析：根据SQL语法规则，把序列组装成抽象语法树（AST）
语义分析：遍历AST，提取出输入表、输出表、字段映射关系

核心要点：血缘解析不是要理解SQL的语义，而是要提取出数据的流向。说白了，我们只关心"数据从哪张表的哪个字段来，到哪张表的哪个字段去"。

4.1.2 常见SQL模式的血缘提取

我在项目中遇到过最头疼的就是各种SQL方言。不同数据库的语法差异，让解析器不得不做大量适配。下面这张表是我总结的常见模式：

SQL模式	输入表	输出表	字段映射示例
SELECT ... FROM	FROM子句中的表	无（查询）	直接映射
INSERT INTO ... SELECT	SELECT中的表	INSERT INTO的表	SELECT字段→INSERT字段
CREATE TABLE AS SELECT	SELECT中的表	CREATE的表	SELECT字段→新表字段
MERGE INTO ... USING	USING中的表	MERGE INTO的表	根据ON条件映射

举个例子，一条简单的INSERT语句：

INSERT INTO dws.dws_sales_daily (date_key, product_id, amount)
SELECT 
    txn_date,
    prod_id,
    SUM(txn_amt)
FROM ods.ods_txn_detail
WHERE txn_date = '2024-01-01'
GROUP BY txn_date, prod_id;

解析结果应该是：

输入表：ods.ods_txn_detail，字段txn_date、prod_id、txn_amt
输出表：dws.dws_sales_daily，字段date_key、product_id、amount
映射关系：txn_date → date_key，prod_id → product_id，SUM(txn_amt) → amount

避坑指南：我曾经在解析CASE WHEN表达式时，只提取了第一个分支的字段，导致血缘链路断了一大片。后来我强制要求解析器必须遍历所有分支，把每个分支的输入字段都记录下来。虽然解析时间多了20%，但血缘完整性从70%提升到了95%。

4.2 ETL脚本解析：从脚本中提取血缘

ETL脚本比纯SQL复杂得多。你想想看，一个典型的DataX或Kettle脚本，里面可能混着SQL、配置文件、自定义函数。我记得有一次接手一个老项目，ETL脚本里居然嵌着Python代码来调用Shell脚本再执行SQL...那感觉，真是酸爽。

4.2.1 脚本类型与解析策略

不同的ETL工具，解析策略完全不同。我按工具类型分了四类：

工具类型	代表工具	解析策略	难点
配置型	DataX、Kettle	解析XML/JSON配置	嵌套转换步骤
脚本型	Shell、Python	正则+语法分析	动态SQL拼接
SQL型	存储过程、DolphinScheduler	SQL解析器	多段SQL混合
可视化拖拽型	Informatica、Datastage	解析元数据导出文件	私有格式

4.2.2 实战：解析DataX脚本

DataX的脚本是JSON格式，结构相对清晰。但有个坑——它的字段映射藏在column数组里，而且支持表达式。我建议的做法是：

先解析reader部分，提取源表名和字段列表
再解析writer部分，提取目标表名和字段列表
根据column数组中的索引或名称，建立映射关系

{
  "job": {
    "content": [{
      "reader": {
        "name": "mysqlreader",
        "parameter": {
          "connection": [{"table": ["ods_txn_detail"]}],
          "column": ["txn_date", "prod_id", "txn_amt"]
        }
      },
      "writer": {
        "name": "hdfswriter",
        "parameter": {
          "path": "/user/hive/warehouse/dws_sales_daily",
          "column": [
            {"name": "date_key", "type": "string"},
            {"name": "product_id", "type": "string"},
            {"name": "amount", "type": "double"}
          ]
        }
      }
    }]
  }
}

解析结果：

输入：ods_txn_detail → txn_date, prod_id, txn_amt
输出：/user/hive/warehouse/dws_sales_daily → date_key, product_id, amount
映射：按位置一一对应（第1列→第1列，以此类推）

注意：DataX的column映射如果用了通配符*，解析器必须去查源表的元数据才能展开字段列表。我曾经因为这个漏掉了30%的字段血缘，后来加了一层元数据缓存才解决。

4.3 存储过程解析：最难啃的骨头

存储过程解析，说实话，是血缘解析里最难的部分。为什么？因为存储过程里有变量、游标、条件分支、循环、动态SQL...我见过最夸张的一个存储过程，两千多行，里面嵌套了十几个游标循环，还用了EXECUTE IMMEDIATE拼接SQL。这种脚本，纯静态解析基本不可能100%准确。

4.3.1 存储过程的特殊挑战

我总结了三个主要难点：

变量追踪：字段值可能被赋给变量，变量又参与后续SQL拼接，必须做数据流分析
动态SQL：运行时才拼接出来的SQL，静态解析只能做近似推断
条件分支：IF-ELSE分支导致不同的执行路径，血缘关系是"或"的关系

4.3.2 我的解析策略

我个人习惯用"两阶段解析法"：

静态扫描阶段：先用正则和语法分析，提取出所有静态SQL片段，记录每个片段出现的上下文（变量值、条件分支）
符号执行阶段：模拟变量赋值过程，追踪变量的值流向，把动态SQL中的变量替换成可能的取值

举个例子：

CREATE PROCEDURE sp_load_sales(IN p_date VARCHAR(10))
BEGIN
    DECLARE v_sql VARCHAR(1000);
    SET v_sql = 'INSERT INTO dws_sales SELECT * FROM ods_txn WHERE dt = ''' || p_date || '''';
    EXECUTE IMMEDIATE v_sql;
END;

解析结果：

输入表：ods_txn（静态推断）
输出表：dws_sales（静态推断）
字段映射：ods_txn.* → dws_sales.*（近似映射，因为SELECT *）
血缘置信度：80%（因为动态SQL和SELECT *导致不确定性）

经验之谈：对于存储过程，我建议不要追求100%的解析准确率。我曾经花了两周时间优化一个存储过程的解析器，准确率从85%提到90%，但投入产出比太低。实际项目中，80%以上的准确率配合人工校验，效率最高。

4.4 血缘构建模型：把碎片拼成图谱

前面三步解析出来的都是碎片化的血缘关系——一条SQL、一个ETL脚本、一个存储过程各自的血缘。最后一步，就是把这些碎片拼成一张完整的血缘图谱。

4.4.1 核心模型设计

我设计的血缘模型包含三个核心实体：

实体	属性	说明
数据集	ID、名称、类型、库名、表名	代表一张表或一个文件
字段	ID、名称、类型、所属数据集ID	代表一个字段或一列
加工节点	ID、名称、类型、SQL文本、脚本路径	代表一次数据加工过程

关系类型：

数据集依赖：加工节点→输入数据集
数据集产出：加工节点→输出数据集
字段映射：输入字段→输出字段（通过加工节点关联）

4.4.2 构建流程

我建议按这个顺序构建：

节点注册：把所有解析出来的加工节点（SQL、ETL、存储过程）注册到图谱中
数据集关联：根据表名匹配，把输入/输出数据集关联到加工节点
字段映射建立：根据解析结果，建立字段级别的映射关系
链路合并：把相同数据集作为桥梁，串联上下游加工节点
环路检测：检查是否存在循环依赖，如果有，标记出来让数据团队确认

关键点：字段级别的血缘才是真正有用的血缘。表级别的血缘只能告诉你"数据从哪张表来"，字段级别的血缘才能告诉你"这个字段的值为什么不对"。

4.4.3 血缘图谱示例

下面这张图展示了一个典型的血缘链路：从ODS层到DWS层，再到应用层。我用SVG画了一个简化版：

4.4.4 血缘存储与查询

我建议用图数据库来存储血缘关系。关系型数据库在查询多级上下游时，性能会急剧下降。举个例子，查询"某个字段的上游五层"，图数据库可能几毫秒就返回了，MySQL可能要写递归CTE跑好几秒。

常用的存储方案对比：

存储方案	优点	缺点	适用场景
Neo4j	多级查询快、可视化好	运维成本高	大规模血缘图谱
JanusGraph	可扩展性强、支持HBase	配置复杂	超大规模集群
MySQL + 缓存	运维简单、团队熟悉	多级查询慢	中小规模（表级血缘）

注意：不要一开始就上Neo4j。我见过一个团队，只有几百张表就上了Neo4j集群，结果运维成本比开发成本还高。小规模先用MySQL+缓存，等血缘节点超过1万再考虑图数据库。

4.5 本章小结

血缘解析技术，说白了就是三件事：读懂SQL、读懂脚本、拼成图谱。SQL解析是基础，ETL脚本解析是扩展，存储过程解析是难点，血缘构建模型是最终产出。

我个人觉得，做血缘解析最重要的是"适度原则"——不要追求100%的解析准确率，那会陷入过度工程化的泥潭。80%的自动化解析 + 20%的人工校验，是性价比最高的方案。