【大数据】Apache Calcite架构：从 SQL 到执行计划的转换框架

文章目录

- 一、Calcite 架构：只做 SQL 访问框架，不做存储和计算
- 二、Calcite 处理流程：SQL 字符串到执行结果的五阶段转换
- 三、SQL 解析：从字符串到抽象语法树（SQL → SqlNode）
- 四、SQL 验证：确保语法正确性和语义合法性（SqlNode → SqlNode）
- 五、关系代数转换：从 SQL 语法树到逻辑计划（SqlNode → RelNode）
- 六、查询优化：基于规则的计划转换（RelNode → RelNode）
- 七、执行阶段：从优化计划到查询结果（RelNode → 执行结果）
- 八、Schema 和 Adapter：连接不同数据源的桥梁
- 九、Calcite 在实际项目中的应用：模块化带来的灵活性
- 总结

Apache Calcite 是一个动态的数据管理框架，它实现了 SQL 的解析、验证、优化和执行。说它"动态"，是因为 Calcite 是模块化和插件式的，上述任何一个步骤都对应着一个相对独立的模块。你可以选择使用其中的一个或多个模块，也可以对任意模块进行定制化扩展。

这种灵活性让 Calcite 可以在现有的存储或计算系统上方便地构建 SQL 访问层。比如 Apache Hive 仅使用了 Calcite 进行优化，却保留了自己的 SQL 解析器；而 Apache Flink 和 Apache Drill 则大量使用了 Calcite 的各个模块。理解 Calcite 的原理，已经成为理解大数据系统中 SQL 访问层实现原理的必备条件。

核心问题：Calcite 如何将一条 SQL 语句转换为可执行计划？这个转换过程经历了哪些阶段，每个阶段解决了什么问题？

一、Calcite 架构：只做 SQL 访问框架，不做存储和计算

Calcite 的核心定位是只提供构建 SQL 访问的框架，它省略了数据存储、处理算法和元数据存储库等关键组成部分。这种设计带来的好处是，使用 Calcite 可以十分方便地构建联邦查询引擎，即屏蔽底层物理存储和计算引擎，使用一个统一的 SQL 接口实现数据访问。

Calcite 的整体架构包含几个核心组件：

JDBC 接口：提供标准的 JDBC/ODBC 接口访问
SQL Parser 和 Validator：将 SQL 字符串解析并验证为内部的抽象语法树（SqlNode）
Query Optimizer：在关系代数（RelNode）基础上进行查询优化
Enumerator 执行计划：将优化后的关系代数转换为可执行计划

这种设计的核心思想是关注点分离：Calcite 专注于 SQL 处理逻辑，而将存储和计算交给外部系统。通过 Adapter 机制，Calcite 可以连接不同的数据源和执行引擎，实现真正的联邦查询。

二、Calcite 处理流程：SQL 字符串到执行结果的五阶段转换

Calcite 的完整处理流程实际上就是 SQL 的解析、优化与执行流程。整个过程分为 5 个阶段：

Parser：将 SQL 字符串转化为抽象语法树（AST），用SqlNode树表示
Validator：根据元数据信息验证SqlNode树，确保语法和语义正确
Converter：将SqlNode树转化为关系代数（RelNode树），便于优化
Optimizer：对关系代数进行优化，输出优化后的RelNode树
Execute：将优化后的RelNode生成执行计划并执行

Enumerator是 Calcite 内置的执行模型，它将关系代数计划转换为可执行的迭代式 Java 代码。关系代数计划首先被转换为可枚举的关系表达式（EnumerableRel），然后转换为可执行的 Java 代码，最后通过Enumerator接口执行并生成查询结果。

这个五阶段设计的核心思想是分层抽象：每一层都专注于自己的职责，通过标准化的数据结构（SqlNode、RelNode）在不同层之间传递，实现了高度的模块化和可扩展性。

三、SQL 解析：从字符串到抽象语法树（SQL → SqlNode）

SQL 解析阶段的核心任务是将 SQL 字符串转换为抽象语法树（AST），Calcite 中用SqlNode树表示。

Calcite 使用 JavaCC 做 SQL 解析，根据定义的语法规则文件（Parser.jj）生成解析器代码。解析器需要完成两个任务：一是定义 SQL 的词法和语法规则，二是实现词法和语法分析器，将 SQL 字符串转换为 AST。

设计思想：使用代码生成工具（JavaCC）而不是手写解析器，可以更容易地扩展 SQL 语法，支持不同的 SQL 方言。AST 作为中间表示，将 SQL 的语法结构与后续的语义处理解耦。

四、SQL 验证：确保语法正确性和语义合法性（SqlNode → SqlNode）

生成的 SqlNode 对象是一个未经验证的抽象语法树，需要进入语法检查阶段。语法检查需要元数据信息，包括表名、字段名、函数名、数据类型的检查。

Calcite 本身不管理和存储元数据，需要先将元信息注册到 Calcite 中。可以通过ReflectiveSchema通过反射自动发现表结构，也可以通过其他方式注册元数据。

验证过程分为三步：

将元数据封装到 CatalogReader 对象
创建 SqlValidator 对象，提供检验能力
进行校验，包括表名、字段名、函数名、数据类型的验证

设计思想：验证阶段将语法树标准化，并注册 scopes 和 namespaces（代表元信息），为后续的关系代数转换做准备。这种设计将语法验证与语义处理分离，使得验证逻辑可以独立扩展。

五、关系代数转换：从 SQL 语法树到逻辑计划（SqlNode → RelNode）

这一步将 SqlNode 转换成 RelNode，生成逻辑计划（Logical Plan）。核心是将 SQL 语法树转换为关系代数表达式，以便进行后续的优化。

转换过程需要初始化关系表达式构建器（RexBuilder）、关系优化集群（RelOptCluster）和转换器（SqlToRelConverter）。转换器根据查询类型（SELECT、INSERT 等）调用不同的转换方法，将 SQL 的各个部分（FROM、WHERE、SELECT 等）转换为对应的关系代数操作。

设计思想：关系代数是查询优化的基础，因为它提供了数学上的等价变换规则。将 SQL 转换为关系代数，使得优化器可以应用各种优化规则，而不需要理解 SQL 的具体语法。

转换后的逻辑计划示例（从下往上看）：

LogicalSort(sort0=[$0], dir0=[ASC]) LogicalProject(NAME=[$1], EXPR$1=[$2]) LogicalAggregate(group=[{0, 1}], EXPR$1=[COUNT()]) LogicalProject(deptno0=[$5], NAME=[$6], empid=[$0]) LogicalFilter(condition=[>($0, 5)]) LogicalJoin(condition=[=($1, $5)], joinType=[inner]) LogicalTableScan(table=[[HR, emps]]) LogicalTableScan(table=[[HR, depts]])