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的源码实现

没有更多推荐了,返回首页