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