4. 血缘解析技术（上）：SQL静态解析、存储过程解析、ETL脚本解析

好，咱们进入实战环节最硬核的部分——血缘解析。

说白了，血缘分析的第一步，就是得让机器读懂你的代码。不管是SQL、存储过程还是ETL脚本，机器得知道它从哪张表读数据、经过什么转换、最后写到了哪张表。这个过程，就是解析。

我个人习惯把解析技术分成两大类：静态解析和动态解析。这一章我们先啃静态解析这块硬骨头。

4.1 静态解析的核心思路

静态解析，就是不跑代码，光看源码就能分析出数据流向。你想想看，这其实挺像编译器干的事——词法分析、语法分析、生成抽象语法树（AST），然后从AST里把表名、字段名、Join条件这些关键信息捞出来。

我在项目中遇到过最头疼的情况：一个SQL写了2000行，嵌套了8层子查询，还有各种CTE（公用表表达式）。手工看？眼睛都看花。但用解析器，几秒钟就能把血缘链路理清楚。

核心要点： 静态解析不依赖数据运行环境，速度快、成本低，适合离线批量分析。但遇到动态SQL、存储过程中的变量拼接，它就有点力不从心了。

4.2 SQL静态解析：两大主流工具

做SQL解析，业界用得最多的就是ANTLR和JSqlParser。我两个都用过，各有千秋。

4.2.1 ANTLR：通用解析引擎

ANTLR（Another Tool for Language Recognition）是一个强大的语法分析器生成器。它可以根据你定义的语法文件（.g4文件），自动生成词法分析器和语法分析器的代码。

嗯，这里要注意：ANTLR本身不认SQL，你得给它喂SQL的语法文件。好在社区已经提供了标准的SQL语法文件，比如MySQL、Oracle、Hive的都有。

// ANTLR解析SQL的典型流程
// 1. 加载语法文件（如MySqlParser.g4）
// 2. 创建词法分析器
MySqlLexer lexer = new MySqlLexer(CharStreams.fromString(sql));
// 3. 创建语法分析器
CommonTokenStream tokens = new CommonTokenStream(lexer);
MySqlParser parser = new MySqlParser(tokens);
// 4. 解析得到AST
ParseTree tree = parser.statement();
// 5. 遍历AST，提取血缘信息
MySqlParserBaseVisitor<Void> visitor = new MySqlParserBaseVisitor<Void>() {
    @Override
    public Void visitTableSource(MySqlParser.TableSourceContext ctx) {
        // 提取表名
        System.out.println("发现表: " + ctx.getText());
        return super.visitTableSource(ctx);
    }
};
visitor.visit(tree);
我的经验： ANTLR的优点是灵活，几乎可以解析任何语言。但缺点也很明显——你得自己写Visitor遍历AST，提取血缘信息的逻辑得从头搭。我曾经为一个复杂的Hive SQL写Visitor，整整调了两天。

4.2.2 JSqlParser：专为SQL而生

JSqlParser是Java生态里专门解析SQL的库。它内置了SQL语法，开箱即用，API设计得很直观。

// JSqlParser解析SQL示例
String sql = "SELECT a.id, b.name " +
             "FROM schema_a.user_table a " +
             "JOIN schema_b.order_table b ON a.id = b.user_id " +
             "WHERE a.status = 'active'";

// 解析SQL
Statement statement = CCJSqlParserUtil.parse(sql);

// 如果是SELECT语句
if (statement instanceof Select) {
    Select select = (Select) statement;
    SelectBody selectBody = select.getSelectBody();
    
    // 提取FROM子句中的表
    if (selectBody instanceof PlainSelect) {
        PlainSelect plainSelect = (PlainSelect) selectBody;
        FromItem fromItem = plainSelect.getFromItem();
        System.out.println("源表: " + fromItem);
        
        // 提取SELECT字段
        List<SelectItem> selectItems = plainSelect.getSelectItems();
        for (SelectItem item : selectItems) {
            System.out.println("输出字段: " + item);
        }
    }
}
对比维度 ANTLR JSqlParser
学习成本 高，需要理解语法文件 低，API直观
灵活性 高，可自定义语法 中，只支持标准SQL
方言支持 需要额外语法文件 内置MySQL、Oracle等
性能 中等 较快
社区活跃度 高 中等
避坑指南： 我曾经用JSqlParser解析一个带Oracle Hint的SQL，直接报语法错误。后来发现JSqlParser对某些数据库方言支持不够好。如果你的环境里SQL方言很重，建议先用ANTLR+对应方言的语法文件。

4.3 存储过程解析：动态与静态的博弈

存储过程解析比普通SQL复杂得多。为什么？因为存储过程里有变量、有循环、有条件判断，甚至还有动态SQL拼接。

我记得有一次解析一个Oracle存储过程，里面用EXECUTE IMMEDIATE拼接了SQL字符串。静态解析根本看不出来最终执行的SQL是什么，因为变量值要到运行时才知道。

4.3.1 静态解析策略

对于存储过程，静态解析能做的是：

  • 识别表依赖：从静态SQL片段中提取表名
  • 分析控制流：识别IF-ELSE、LOOP等结构
  • 变量追踪：追踪变量的赋值和引用关系
  • 调用关系：识别存储过程之间的调用链
-- 一个典型的存储过程示例
CREATE PROCEDURE process_order(p_order_id INT)
BEGIN
    DECLARE v_status VARCHAR(20);
    DECLARE v_sql VARCHAR(1000);
    
    -- 静态可解析：直接引用表
    SELECT status INTO v_status FROM orders WHERE order_id = p_order_id;
    
    -- 动态SQL：静态解析无法确定最终SQL
    SET v_sql = CONCAT('SELECT * FROM ', v_status, '_orders');
    PREPARE stmt FROM v_sql;
    EXECUTE stmt;
    
    -- 条件分支
    IF v_status = 'completed' THEN
        INSERT INTO order_archive SELECT * FROM orders WHERE order_id = p_order_id;
    END IF;
END;
静态解析能做的： 识别出orders表、order_archive表，以及INSERT和SELECT操作。
静态解析做不到的： 无法确定v_status_orders这个动态表名到底是什么。

4.3.2 我的实践方案

对于存储过程，我一般采取分层解析策略：

  1. 第一层：用正则或简单解析器提取所有静态SQL片段
  2. 第二层：分析变量赋值链，尝试推断动态SQL的可能值
  3. 第三层：对于无法静态确定的，标记为"待运行时确认"

说白了，存储过程的静态解析只能做到80%的覆盖率。剩下的20%，要么靠运行时采样，要么靠人工标注。

4.4 ETL脚本解析：多语言混搭的挑战

ETL脚本比存储过程更头疼。为什么？因为一个ETL任务里可能混着SQL、Shell脚本、Python代码，甚至还有配置文件。

我之前处理过一个Kettle的ETL任务，里面既有SQL步骤，又有JavaScript脚本步骤，还有调用外部Shell的步骤。解析这种脚本，你得同时懂好几种语言的解析器。

4.4.1 常见ETL工具的血缘解析难点

ETL工具 解析难点 应对策略
Informatica XML格式的工作流，映射关系复杂 解析XML，提取Source/Target映射
DataStage 二进制或专有格式 使用官方API或导出为DSL
Kettle XML格式，步骤间通过Hop连接 解析XML，追踪Hop连线
Shell脚本 动态拼接、管道操作 正则匹配+执行路径模拟

4.4.2 一个Kettle脚本解析的简化示例

// Kettle的XML片段（简化）
<transformation>
    <info>
        <name>用户数据清洗</name>
    </info>
    <step>
        <name>读取源数据</name>
        <type>TableInput</type>
        <sql>SELECT user_id, name, email FROM source_db.users</sql>
    </step>
    <step>
        <name>数据过滤</name>
        <type>FilterRows</type>
        <condition>name IS NOT NULL</condition>
    </step>
    <step>
        <name>写入目标</name>
        <type>TableOutput</type>
        <table>target_db.clean_users</table>
    </step>
    <hop>
        <from>读取源数据</from>
        <to>数据过滤</to>
    </hop>
    <hop>
        <from>数据过滤</from>
        <to>写入目标</to>
    </hop>
</transformation>

解析这个XML，我们就能得到：source_db.users → 过滤 → target_db.clean_users 这条血缘链路。

我的建议： 解析ETL脚本时，不要试图一次性搞定所有工具。先挑你们公司用得最多的那个工具，把它的解析器写好。其他的，能用通用解析器兜底就用通用解析器。

4.5 本章知识体系总览

为了让你更直观地理解静态解析的整体架构，我画了一张图：

静态血缘解析技术架构 输入：SQL / 存储过程 / ETL脚本 原始代码文本 解析引擎 ANTLR + SQL语法文件 通用解析器 JSqlParser 专用SQL解析器 自定义解析器 正则/XML解析 解析结果（AST / 中间表示） 表名提取 字段映射 Join条件 过滤条件 输出：血缘关系图谱 表级血缘 / 字段级血缘 / 转换逻辑 注：存储过程和ETL脚本需要额外处理动态SQL和跨语言调用

这张图把静态解析的流程串起来了：从原始代码输入，经过不同的解析引擎，得到中间表示，最后输出血缘关系图谱。你实际做项目时，可以根据自己的技术栈选择合适的解析引擎。

最后提醒一句： 静态解析不是万能的。遇到动态SQL、运行时变量、外部调用这些情况，别硬撑。该标记为"待确认"就标记，该上动态解析就上动态解析。我在一个项目中硬要用静态解析搞定所有存储过程，结果花了三周只覆盖了60%，后来改用运行时采样，一周就补上了剩下的40%。
← 上一章 📖 返回目录 下一章 →