HepPlanner源码分析——Calcite

Query Optimization for Distributed Database Systems

Calcite是开源的一套查询引擎,很多开源项目都使用了该开源项目,特别是对其Optimizer部分的使用,类似Drill、Hive、Flink都使用Calcite作为其优化引擎。
Calcite实现了两套Planner,HepPlanner和VolcanoPlanner,HepPlanner主要是一种贪婪式的Planner,而Volcano则是一种启发式的Planner,下面介绍下HepPlanner的源码实现。

1 HepPlanner介绍

HepPlanner是一套greedy方式的Planner,可以认为是所优即所得,即任何rule只要命中运行,就认为其产生的结果是更优。
例:Calcite实现的ProjectFilterTransposeRule,功能主要是将Project与Filter进行交换。

subTree1:
Project($0, $1)
    Filter($0 > 1)
-->rule apply to
subTree2:
Filter($0 > 1)
    Project($0, $1)

则HepPlanner会将subTree2作为更优的plan。

2 实现原理

实现原理主要分为几部分来介绍:
1)HepRelVertex
2)Graph & Vertex
3)HepProgram
4)Rule apply

2.1 HepRelVertex

HepRelVertex是对关系代数表达式RelNode进行了简单封装。HepPlanner的所有节点都是HepRelVertex,每个HepRelVertex都指向了一个真正的relNode节点。

Project($0, $1)
    TableScan($0,$1,$2)

则HepPlanner会封装成

HepRelVertex#1->currentRel(Project($0, $1))
    HepRelVertex#2->currentRel(TableScan($0,$1,$2))

所以从整体上看整个relNode树都是由HepRelVertex节点组成,只是其指向了一个内部relNode 节点。

2.2 Graph & Vertex

HepPlanner在将所有relNode tree转化为HepRelVertex时,构建了一个Graph,将所有的relNode节点关系使用Vertex表示。首先根据每个HepRelVertex构建了从其本身出发到其指向的孩子节点的source->dest之间的关系。
即DirectedGraph

HepRelVertex#1->currentRel(Project($0, $1))
    HepRelVertex#2->currentRel(TableScan($0,$1,$2))

则存在map

HepRelVertex#1 -> (HepRelVertex#1 -> HepRelVertex#2)
HepRelVertex#2 -> ()  --

所有的这些映射关系被当作整个plan tree的graph。

2.3 HepProgram

HepPlanner为了更好地采用Greedy算法,将每次运行的rule使用HepProgram进行组装。HepProgram由各种不同的HepInstruction组成,按照HepInstruction加入到HepProgram顺序执行,常用的HepInstruction有MatchLimit、MatchOrder、Rules组成,其中MatchLimit表示这次HepProgram优化的次数限制,如果不设置,则为无穷;MatchOrder则表示每次rule执行的顺序,包括ARBITRARY、BOTTOM_UP、TOP_DOWN三种方式,其中ARBITRARY被认为是最高效的apply方式,也是默认方式。
1. ARBITRARY
含义是rule每次Apply是从当前relNode节点开始,直到没有vertex执行后,采用root节点重新apply。
2. BOTTOM_UP
含义是针对所有Vertex,按照逆序方式apply。
3. TOP_DOWN
与BOTTOM_UP相反,对所有vertex按照顺序执行,即可以认为是从top到down方式。
4. DEPTH_FIRST
本人CI了一种新的Apply mode,即深度优先。为了解决每次rule apply时由于每次产生新的plan之后又从root节点开始apply,导致重复apply的次数太多。同时也作为了HepPlanner的默认方式,因为效率更高。
https://issues.apache.org/jira/browse/CALCITE-2111
Rules表示需要运行的优化规则。
HepPlanner运行HepProgram算法如下

for (HepInstruction instruction : currentProgram.instructions) {
instruction.execute(this);
int delta = nTransformations - nTransformationsLastGC;
if (delta > graphSizeLastGC) {
// The number of transformations performed since the last
// garbage collection is greater than the number of vertices in
// the graph at that time. That means there should be a
// reasonable amount of garbage to collect now. We do it this
// way to amortize garbage collection cost over multiple
// instructions, while keeping the highwater memory usage
// proportional to the graph size.
collectGarbage();
}
}

可以看到处理方式很简单,就是顺序执行每一个HepInstruction,然后当遇到transformation发生的次数到达一定程度时,清理一些中间结果的RelNode。

2.4 Rule apply

每次针对一个集合的rules是如何处理的呢?
算法如下:

int nMatches = 0;
boolean fixpoint;
do {
Iterator<HepRelVertex> iter = getGraphIterator(root);
fixpoint = true;
while (iter.hasNext()) {
HepRelVertex vertex = iter.next();
for (RelOptRule rule : rules) {
HepRelVertex newVertex =
applyRule(rule, vertex, forceConversions);
if (newVertex != null) {
++nMatches;
if (nMatches >= currentProgram.matchLimit) {
return;
}
if (fullRestartAfterTransformation) {
iter = getGraphIterator(root);
} else {
// To the extent possible, pick up where we left
// off; have to create a new iterator because old
// one was invalidated by transformation.
iter = getGraphIterator(newVertex);
// Remember to go around again since we're
// skipping some stuff.
fixpoint = false;
}
break;
}
}
}
} while (!fixpoint);

算法比较简洁,首先根据root节点构建整颗树的HepRelVertex迭代器,遍历每个HepRelVertex,同时与给定的rules进行match并apply,如果发现rule产生了更优的result,即发生transformation,然后继续按照MatchOrder构建HepRelVertex迭代器,从而继续apply,直接整颗树不再有transformatin产生或者达到了MatchLimit的限制。

3 优缺点

HepPlanner看似简单,但其实坑不少,也就是缺点也很明显。
1)Plan不是最优
每次rule产生的result当作下一次迭代的开始,也认为是当作这次最优的plan,则丢掉了其他优化可能,所以plan可能不是最优。
2)实现缺点
死循环:每次rule apply会产生一个结果,如果一个rule产生的pattern会继续apply同一个rule则会一直apply下去。这里也是MatchLimit的另外一个用途。
这里举例有大致有三类反复apply情况:
1)单个rule内部实现引发反复apply,如JoinCommuteRule,这个rule的实现是将join type进行swap,left->right, right->left,如果不加限制,则会一直apply下去。
2)多个rule组合引发反复apply,如ProjectFilterTransposeRule和FilterProjectTransposeRule。
如sql:select 1 from dept where abs(-1)=20
3)单个rule会一直产生的重复relNode。
目前还未在calcite找到类似rule,但使用的时候,我们写的rule有类似情况。
如FilterXXXTransposeRule,对于or处理,提取表达式后,剩余部分与原始Filter一样,导致后续生成的Filter还是会继续rule apply。
Apply次数不够优:每次rule apply之后,重新构建下一次的迭代,重复apply次数较多。

4 用途

HepPlanner在Calcite中主要是用来提前剪枝,方便给VolcanoPlanner提供一种次优plan后,继续优化,类似Drill等都是这样处理。

PS:后续会继续更新VolcanoPlanner的源码实现

展开阅读全文

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值