原作者禁止修改内容,但是由于微信篇幅所限,不得不将本文截开。大家有兴趣可以点击【阅读原文】查看原始文章。
---------------------------------------------------------------------
这里是 Calcite 系列文章的第二篇,后面还会有文章讲述 Calcite 的实践(包括:如何开发用于 SQL 优化的 Rule)。本篇文章主要介绍 Apache Calcite 优化器部分的内容,会先简单介绍一下 RBO 和 CBO 模型,之后详细讲述 Calcite 关于这两个优化器的实现 —— HepPlanner 和 VolcanoPlanner,文章内容都是个人的一些理解,由于也是刚接触这块,理解有偏差的地方,欢迎指正。
什么是查询优化器
查询优化器是传统数据库的核心模块,也是大数据计算引擎的核心模块,开源大数据引擎如 Impala、Presto、Drill、HAWQ、 Spark、Hive 等都有自己的查询优化器。Calcite 就是从 Hive 的优化器演化而来的。
优化器的作用:将解析器生成的关系代数表达式转换成执行计划,供执行引擎执行,在这个过程中,会应用一些规则优化,以帮助生成更高效的执行计划。
关于 Volcano 模型和 Cascades 模型的内容,建议看下相关的论文,这个是 Calcite 优化器的理论基础,代码只是把这个模型落地实现而已。
基于规则优化(RBO)
基于规则的优化器(Rule-Based Optimizer,RBO):根据优化规则对关系表达式进行转换,这里的转换是说一个关系表达式经过优化规则后会变成另外一个关系表达式,同时原有表达式会被裁剪掉,经过一系列转换后生成最终的执行计划。
RBO 中包含了一套有着严格顺序的优化规则,同样一条 SQL,无论读取的表中数据是怎么样的,最后生成的执行计划都是一样的。同时,在 RBO 中 SQL 写法的不同很有可能影响最终的执行计划,从而影响执行计划的性能。
基于成本优化(CBO)
基于代价的优化器(Cost-Based Optimizer,CBO):根据优化规则对关系表达式进行转换,这里的转换是说一个关系表达式经过优化规则后会生成另外一个关系表达式,同时原有表达式也会保留,经过一系列转换后会生成多个执行计划,然后 CBO 会根据统计信息和代价模型 (Cost Model) 计算每个执行计划的 Cost,从中挑选 Cost 最小的执行计划。
由上可知,CBO 中有两个依赖:统计信息和代价模型。统计信息的准确与否、代价模型的合理与否都会影响 CBO 选择最优计划。 从上述描述可知,CBO 是优于 RBO 的,原因是 RBO 是一种只认规则,对数据不敏感的呆板的优化器,而在实际过程中,数据往往是有变化的,通过 RBO 生成的执行计划很有可能不是最优的。事实上目前各大数据库和大数据计算引擎都倾向于使用 CBO,但是对于流式计算引擎来说,使用 CBO 还是有很大难度的,因为并不能提前预知数据量等信息,这会极大地影响优化效果,CBO 主要还是应用在离线的场景。
优化规则
无论是 RBO,还是 CBO 都包含了一系列优化规则,这些优化规则可以对关系表达式进行等价转换,常见的优化规则包含:
谓词下推 Predicate Pushdown
常量折叠 Constant Folding
列裁剪 Column Pruning
其他
在 Calcite 的代码里,有一个测试类(org.apache.calcite.test.RelOptRulesTest
)汇集了对目前内置所有 Rules 的测试 case,这个测试类可以方便我们了解各个 Rule 的作用。在这里有下面一条 SQL,通过这条语句来说明一下上面介绍的这三种规则。
1 | select 10 + 30, users.name, users.age |
谓词下推(Predicate Pushdown)
关于谓词下推,它主要还是从关系型数据库借鉴而来,关系型数据中将谓词下推到外部数据库用以减少数据传输;属于逻辑优化,优化器将谓词过滤下推到数据源,使物理执行跳过无关数据。最常见的例子就是 join 与 filter 操作一起出现时,提前执行 filter 操作以减少处理的数据量,将 filter 操作下推,以上面例子为例,示意图如下(对应 Calcite 中的 FilterJoinRule.FilterIntoJoinRule.FILTER_ON_JOIN
Rule):
在进行 join 前进行相应的过滤操作,可以极大地减少参加 join 的数据量。
常量折叠(Constant Folding)
常量折叠也是常见的优化策略,这个比较简单、也很好理解,可以看下 编译器优化 – 常量折叠 这篇文章,基本不用动脑筋就能理解,对于我们这里的示例,有一个常量表达式 10 + 30
,如果不进行常量折叠,那么每行数据都需要进行计算,进行常量折叠后的结果如下图所示( 对应 Calcite 中的 ReduceExpressionsRule.PROJECT_INSTANCE
Rule):
常量折叠前后的对比
列裁剪(Column Pruning)
列裁剪也是一个经典的优化规则,在本示例中对于jobs 表来说,并不需要扫描它的所有列值,而只需要列值 id,所以在扫描 jobs 之后需要将其他列进行裁剪,只留下列 id。这个优化带来的好处很明显,大幅度减少了网络 IO、内存数据量的消耗。裁剪前后的示意图如下(不过并没有找到 Calcite 对应的 Rule):
Calcite 中的优化器实现
有了前面的基础后,这里来看下 Calcite 中优化器的实现,RelOptPlanner 是 Calcite 中优化器的基类,其子类实现如下图所示:
Calcite 中关于优化器提供了两种实现:
HepPlanner:就是前面 RBO 的实现,它是一个启发式的优化器,按照规则进行匹配,直到达到次数限制(match 次数限制)或者遍历一遍后不再出现 rule match 的情况才算完成;
VolcanoPlanner:就是前面 CBO 的实现,它会一直迭代 rules,直到找到 cost 最小的 paln。
前面提到过像calcite这类查询优化器最核心的两个问题之一是怎么把优化规则应用到关系代数相关的RelNode Tree上。所以在阅读calicite的代码时就得带着这个问题去看看它的实现过程,然后才能判断它的代码实现得是否优雅。
calcite的每种规则实现类(RelOptRule的子类)都会声明自己应用在哪种RelNode子类上,每个RelNode子类其实都可以看成是一种operator(中文常翻译成算子)。
VolcanoPlanner就是优化器,用的是动态规划算法,在创建VolcanoPlanner的实例后,通过calcite的标准jdbc接口执行sql时,默认会给这个VolcanoPlanner的实例注册将近90条优化规则(还不算常量折叠这种最常见的优化),所以看代码时,知道什么时候注册可用的优化规则是第一步(调用VolcanoPlanner.addRule实现),这一步比较简单。
接下来就是如何筛选规则了,当把语法树转成RelNode Tree后是没有必要把前面注册的90条优化规则都用上的,所以需要有个筛选的过程,因为每种规则是有应用范围的,按RelNode Tree的不同节点类型就可以筛选出实际需要用到的优化规则了。这一步说起来很简单,但在calcite的代码实现里是相当复杂的,也是非常关键的一步,是从调用VolcanoPlanner.setRoot方法开始间接触发的,如果只是静态的看代码不跑起来跟踪调试多半摸不清它的核心流程的。筛选出来的优化规则会封装成VolcanoRuleMatch,然后扔到RuleQueue里,而这个RuleQueue正是接下来执行动态规划算法要用到的核心类。筛选规则这一步的代码实现很晦涩。
第三步才到VolcanoPlanner.findBestExp,本质上就是一个动态规划算法的实现,但是最值得关注的还是怎么用第二步筛选出来的规则对RelNode Tree进行变换,变换后的形式还是一棵RelNode Tree,最常见的是把LogicalXXX开头的RelNode子类换成了EnumerableXXX或BindableXXX,总而言之,看看具体优化规则的实现就对了,都是繁琐的体力活。
一个优化器,理解了上面所说的三步基本上就抓住重点了。
—— 来自【zhh-4096 】的微博
下面详细讲述一下这两种 planner 在 Calcite 内部的具体实现。
HepPlanner
使用 HepPlanner 实现的完整代码见 SqlHepTest。
HepPlanner 中的基本概念
这里先看下 HepPlanner 的一些基本概念,对于后面的理解很有帮助。
HepRelVertex
HepRelVertex 是对 RelNode 进行了简单封装。HepPlanner 中的所有节点都是 HepRelVertex,每个 HepRelVertex 都指向了一个真正的 RelNode 节点。
1 | // org.apache.calcite.plan.hep.HepRelVertex |
HepInstruction
HepInstruction 是 HepPlanner 对一些内容的封装,具体的子类实现比较多,其中 RuleInstance 是 HepPlanner 中对 Rule 的一个封装,注册的 Rule 最后都会转换为这种形式。
HepInstruction represents one instruction in a HepProgram.
1 | //org.apache.calcite.plan.hep.HepInstruction |
HepPlanner 处理流程
下面这个示例是上篇文章(Apache Calcite 处理流程详解(一))的示例,通过这段代码来看下 HepPlanner 的内部实现机制。
1 | HepProgramBuilder builder = new HepProgramBuilder(); |
上面的代码总共分为三步:
初始化 HepProgram 对象;
初始化 HepPlanner 对象,并通过
setRoot()
方法将 RelNode 树转换成 HepPlanner 内部使用的 Graph;通过
findBestExp()
找到最优的 plan,规则的匹配都是在这里进行。
1. 初始化 HepProgram
这几步代码实现没有太多需要介绍的地方,先初始化 HepProgramBuilder 也是为了后面初始化 HepProgram 做准备,HepProgramBuilder 主要也就是提供了一些配置设置和添加规则的方法等,常用的方法如下:
addRuleInstance()
:注册相应的规则;addRuleCollection()
:这里是注册一个规则集合,先把规则放在一个集合里,再注册整个集合,如果规则多的话,一般是这种方式;addMatchLimit()
:设置 MatchLimit,这个 rule match 次数的最大限制;
HepProgram 这个类对于后面 HepPlanner 的优化很重要,它定义 Rule 匹配的顺序,默认按【深度优先】顺序,它可以提供以下几种(见 HepMatchOrder 类):
ARBITRARY:按任意顺序匹配(因为它是有效的,而且大部分的 Rule 并不关心匹配顺序);
BOTTOM_UP:自下而上,先从子节点开始匹配;
TOP_DOWN:自上而下,先从父节点开始匹配;
DEPTH_FIRST:深度优先匹配,某些情况下比 ARBITRARY 高效(为了避免新的 vertex 产生后又从 root 节点开始匹配)。
这个匹配顺序到底是什么呢?对于规则集合 rules,HepPlanner 的算法是:从一个节点开始,跟 rules 的所有 Rule 进行匹配,匹配上就进行转换操作,这个节点操作完,再进行下一个节点,这里的匹配顺序就是指的节点遍历顺序(这种方式的优劣,我们下面再说)。
2. HepPlanner.setRoot(RelNode –> Graph)
先看下 setRoot()
方法的实现:
1 | // org.apache.calcite.plan.hep.HepPlanner |
HepPlanner 会先将所有 relNode tree 转化为 HepRelVertex,这时就构建了一个 Graph:将所有的 elNode 节点使用 Vertex 表示,Gragh 会记录每个 HepRelVertex 的 input 信息,这样就是构成了一张 graph。
在真正的实现时,递归逐渐将每个 relNode 转换为 HepRelVertex,并在 graph
中记录相关的信息,实现如下:
1 | //org.apache.calcite.plan.hep.HepPlanner |
到这里 HepPlanner 需要的 gragh 已经构建完成,通过 DEBUG 方式也能看到此时 HepPlanner root 变量的内容:
3. HepPlanner findBestExp 规则优化
1 | //org.apache.calcite.plan.hep.HepPlanner |
主要的实现是在 executeProgram()
方法中,如下:
1 | //org.apache.calcite.plan.hep.HepPlanner |
这里会遍历 HepProgram 中 instructions(记录注册的所有 HepInstruction),然后根据 instruction 的类型执行相应的 executeInstruction()
方法,如果instruction 是 HepInstruction.MatchLimit
类型,会执行 executeInstruction(HepInstruction.MatchLimit instruction)
方法,这个方法就是初始化 matchLimit 变量。对于 HepInstruction.RuleInstance
类型的 instruction 会执行下面的方法(前面的示例注册规则使用的是 addRuleInstance()
方法,所以返回的 rules 只有一个规则,如果注册规则的时候使用的是 addRuleCollection()
方法注册一个规则集合的话,这里会返回的 rules 就是那个规则集合):
1 | //org.apache.calcite.plan.hep.HepPlanner |
接下来看 applyRules()
的实现:
1 | //org.apache.calcite.plan.hep.HepPlanner |
在这里会调用 getGraphIterator()
方法获取 HepRelVertex 的迭代器,迭代的策略(遍历的策略)跟前面说的顺序有关,默认使用的是【深度优先】,这段代码比较简单,就是遍历规则+遍历节点进行匹配转换,直到满足条件再退出,从这里也能看到 HepPlanner 的实现效率不是很高,它也无法保证能找出最优的结果。
总结一下,HepPlanner 在优化过程中,是先遍历规则,然后再对每个节点进行匹配转换,直到满足条件(超过限制次数或者规则遍历完一遍不会再有新的变化),其方法调用流程如下:
思考
1. 为什么要把 RelNode 转换 HepRelVertex 进行优化?带来的收益在哪里?
关于这个,能想到的就是:RelNode 是底层提供的抽象、偏底层一些,在优化器这一层,需要记录更多的信息,所以又做了一层封装。