4. SQL Parser 实战：基于 Apache Calcite 解析 SQL，提取血缘要素

上一章我们聊了血缘分析的理论框架，说白了就是「谁生谁」的关系图。但理论再漂亮，落不了地也是白搭。这一章我们直接动手——用 Apache Calcite 把 SQL 语句拆开，把输入表、输出表、字段映射关系一个个拎出来。

我最早做血缘工具时，第一反应是自己写正则匹配。结果呢？被各种嵌套子查询、CTE、函数套函数按在地上摩擦。后来老老实实用 Calcite，才发现专业的事就该交给专业的库。

4.1 为什么选 Calcite？

市面上能解析 SQL 的库不少，比如 ANTLR、Druid、JSqlParser。我个人的选择标准很简单：

  • 要能处理多种方言——公司里 Hive、Spark、Flink、MySQL 混着用，一个库搞定最好
  • 要有完整的语法树——不光解析出表名，字段级依赖也得能拿到
  • 社区活跃——踩坑了能搜到答案，或者有人修

Calcite 恰好满足这三点。它内部自带 SQL 解析器（基于 JavaCC 生成），能把 SQL 转成抽象语法树（AST），然后通过 Visitor 模式遍历，提取我们需要的信息。

核心思路：SQL → 解析 → SqlNode 语法树 → 遍历节点 → 提取 Table/Column 引用

4.2 环境准备与依赖

我用的是 Maven 项目，Calcite 版本选 1.35.0（2023 年底发布的，比较稳定）。

<dependency>
    <groupId>org.apache.calcite</groupId>
    <artifactId>calcite-core</artifactId>
    <version>1.35.0</version>
</dependency>

嗯，这里要注意：Calcite 的依赖会拉进来一堆东西，包括 avatica、protobuf 等。如果你的项目里已经有这些库，记得检查版本冲突。

4.3 第一个例子：解析简单 SELECT

我们先从最基础的开始。解析一条 SELECT * FROM orders，看看 Calcite 能吐出什么。

import org.apache.calcite.sql.*;
import org.apache.calcite.sql.parser.*;

public class SimpleParser {
    public static void main(String[] args) throws SqlParseException {
        String sql = "SELECT * FROM orders";
        
        SqlParser parser = SqlParser.create(sql);
        SqlNode sqlNode = parser.parseQuery();
        
        System.out.println(sqlNode.getClass().getName());
        System.out.println(sqlNode.toString());
    }
}

输出结果：

class org.apache.calcite.sql.SqlSelect
SELECT *
FROM `orders`

看到没？Calcite 自动给表名加了反引号。这是它的默认行为——把标识符标准化。我个人习惯在创建 Parser 时指定配置，关掉这个特性：

SqlParser.Config config = SqlParser.config()
    .withQuotedCasing(SqlParser.Casing.UNCHANGED)
    .withUnquotedCasing(SqlParser.Casing.UNCHANGED);
SqlParser parser = SqlParser.create(sql, config);

4.4 提取输入表与输出表

实际的血缘分析，我们需要知道：这条 SQL 读了哪些表（输入），写了哪些表（输出）。

对于 SELECT 语句，输入表就是 FROM 子句里的表，输出表通常是 INSERT/CTAS 的目标表。我写了一个工具方法，用 Visitor 遍历 SqlNode：

import org.apache.calcite.sql.*;
import org.apache.calcite.sql.util.SqlBasicVisitor;
import java.util.*;

public class TableExtractor extends SqlBasicVisitor<Void> {
    private final Set<String> tables = new HashSet<>();
    
    @Override
    public Void visit(SqlCall call) {
        if (call instanceof SqlIdentifier) {
            // 处理多部分标识符，如 db.table
            SqlIdentifier id = (SqlIdentifier) call;
            tables.add(id.toString());
        }
        // 递归遍历子节点
        for (SqlNode operand : call.getOperandList()) {
            if (operand != null) {
                operand.accept(this);
            }
        }
        return null;
    }
    
    public Set<String> getTables() {
        return tables;
    }
}

但等等——这个实现太粗糙了。它会把所有标识符都当成表名，包括列名、别名。我在项目中踩过这个坑，后来改成只处理 FROM/JOIN 子句里的标识符。

更靠谱的做法是：先判断 SqlNode 的类型，如果是 SqlSelect，就专门处理其 from 节点：

public Void visit(SqlCall call) {
    if (call instanceof SqlSelect) {
        SqlSelect select = (SqlSelect) call;
        SqlNode from = select.getFrom();
        extractTableFromFromClause(from);
    }
    return super.visit(call);
}

private void extractTableFromFromClause(SqlNode node) {
    if (node instanceof SqlIdentifier) {
        tables.add(node.toString());
    } else if (node instanceof SqlJoin) {
        SqlJoin join = (SqlJoin) node;
        extractTableFromFromClause(join.getLeft());
        extractTableFromFromClause(join.getRight());
    } else if (node instanceof SqlBasicCall) {
        // 处理子查询
        SqlBasicCall call = (SqlBasicCall) node;
        if (call.getOperator() instanceof SqlSelectOperator) {
            // 递归处理子查询
            call.getOperandList().forEach(this::extractTableFromFromClause);
        }
    }
}

避坑指南：我曾经在处理子查询别名时，把子查询的别名也当成了表名。比如 SELECT * FROM (SELECT * FROM src) t，这里的 t 不是物理表。解决办法是：只提取 SqlIdentifier 中不带别名的部分，或者通过 SqlValidator 解析出真实表名。

4.5 字段映射关系提取

字段级血缘才是硬骨头。我们需要知道：输出字段来自哪些输入字段，经过了什么转换。

对于简单的 SELECT a, b + c AS d FROM t，映射关系是：

  • 输出字段 a → 输入字段 t.a
  • 输出字段 d → 输入字段 t.b + t.c

我写了一个 ColumnLineageExtractor，核心逻辑是遍历 SELECT 列表中的每个表达式：

public class ColumnLineageExtractor extends SqlBasicVisitor<Void> {
    private final List<ColumnMapping> mappings = new ArrayList<>();
    private String currentAlias;
    
    @Override
    public Void visit(SqlCall call) {
        if (call instanceof SqlSelect) {
            SqlSelect select = (SqlSelect) call;
            SqlNodeList selectList = select.getSelectList();
            for (SqlNode item : selectList) {
                // 处理每个 SELECT 项
                processSelectItem(item);
            }
        }
        return super.visit(call);
    }
    
    private void processSelectItem(SqlNode item) {
        if (item instanceof SqlBasicCall) {
            SqlBasicCall call = (SqlBasicCall) item;
            // 处理 AS 别名
            if (call.getOperator() instanceof SqlAsOperator) {
                String alias = call.getOperandList().get(1).toString();
                SqlNode expr = call.getOperandList().get(0);
                // 提取表达式中的列引用
                List<String> sourceCols = extractColumnRefs(expr);
                mappings.add(new ColumnMapping(alias, sourceCols));
            }
        } else if (item instanceof SqlIdentifier) {
            // 直接是列名，没有别名
            mappings.add(new ColumnMapping(item.toString(), 
                Collections.singletonList(item.toString())));
        }
    }
}

注意：字段映射提取最怕遇到函数嵌套和 CASE WHEN。比如 SELECT UPPER(SUBSTR(name, 1, 3)) AS short_name，你需要递归遍历表达式树，找到最底层的列引用。我建议用 Calcite 的 SqlVisitor 配合 SqlNode.accept() 做深度遍历，不要自己写递归——容易漏掉深层嵌套。

4.6 完整示例：解析 INSERT … SELECT

实际生产环境里，最常见的血缘场景是 ETL 任务中的 INSERT INTO target SELECT ... FROM source。我们来看一个完整例子：

String sql = "INSERT INTO dws.daily_sales " +
             "SELECT o.order_id, o.amount * p.discount AS final_amount " +
             "FROM ods.orders o " +
             "JOIN dim.product p ON o.product_id = p.id " +
             "WHERE o.status = 'completed'";

SqlParser parser = SqlParser.create(sql);
SqlNode sqlNode = parser.parseStmt();

// 判断类型
if (sqlNode instanceof SqlInsert) {
    SqlInsert insert = (SqlInsert) sqlNode;
    
    // 输出表
    SqlNode targetTable = insert.getTargetTable();
    System.out.println("输出表: " + targetTable.toString());
    
    // 输入表（从 SELECT 子句中提取）
    SqlNode source = insert.getSource();
    if (source instanceof SqlSelect) {
        TableExtractor extractor = new TableExtractor();
        source.accept(extractor);
        System.out.println("输入表: " + extractor.getTables());
    }
    
    // 字段映射
    ColumnLineageExtractor lineage = new ColumnLineageExtractor();
    source.accept(lineage);
    System.out.println("字段映射: " + lineage.getMappings());
}

输出结果：

输出表: `dws`.`daily_sales`
输入表: [`ods`.`orders`, `dim`.`product`]
字段映射: 
  order_id → [o.order_id]
  final_amount → [o.amount, p.discount]

4.7 踩坑记录

做这个功能时，我踩了不少坑。列出来给大家参考：

问题 现象 原因 解决方案
CTE 解析丢失 WITH 子句中的临时表没被识别 SqlWith 节点需要单独处理 增加 SqlWith 分支，递归处理其 body
别名覆盖真实表名 把子查询别名当成物理表 Visitor 没有区分别名和表名 通过 SqlValidator 解析出原始表名
函数内列引用遗漏 UDF(column) 中的 column 没被提取 只处理了顶层 SELECT 项 递归遍历所有 SqlCall 的 operand
UNION ALL 重复表 同一张表在 UNION 两侧出现两次 没有去重 用 Set 存储表名，最后转 List

我的建议：不要试图一次性写出完美的解析器。先处理 80% 的常见场景（简单 SELECT、INSERT SELECT、JOIN），然后针对 CTE、子查询、窗口函数逐步补充。我第一个版本只支持 5 种 SQL 模式，上线后两周内迭代到支持 20+ 种。

4.8 本章小结

这一章我们动手实现了 SQL 解析的核心能力：

  • 用 Calcite 把 SQL 转成语法树
  • 通过 Visitor 模式提取输入表和输出表
  • 递归遍历表达式，提取字段级映射关系
  • 处理了 INSERT SELECT、JOIN、子查询等常见场景

代码量不大，但细节很多。尤其是字段映射那块，不同 SQL 方言、不同函数写法，都会影响解析结果。我建议你拿自己公司的真实 SQL 去测试，大概率会发现一些边界情况——这正是血缘工具落地的价值所在。

一句话总结：SQL Parser 是血缘分析的「翻译官」，把人类写的 SQL 翻译成机器能理解的血缘关系图。Calcite 帮我们省了 80% 的解析工作，剩下的 20% 靠踩坑经验填平。

SQL Parser 血缘提取流程 原始 SQL 语句 SqlParser.parseStmt() SqlNode 抽象语法树 TableExtractor ColumnLineageExtractor 输入表 / 输出表 字段映射关系 核心：通过 Visitor 模式遍历 SqlNode，分别提取表级和字段级血缘要素
← 上一章 📖 返回目录 下一章 →