Whole View

本文分析的是逻辑执行计划优化的代码结构，具体每种Rule的实现不做分析。

看本文之前最好参考之前那篇逻辑执行计划模型的文章。

Architecture

几个关键类/接口的关系：

每个关键类/接口的实现和继承结构在下面各节展开。

Optimizer

PlanOptimizer是抽象类，主要和Rule、PlanTransformListener、OperatorPlan打交道。

public abstract class PlanOptimizer {

    protected List<Set<Rule>> ruleSets;
    protected OperatorPlan plan;
    protected List<PlanTransformListener> listeners;
    protected int maxIter;

它接受一个OperatorPlan，即Operators的DAG模型，在optimize()方法里，遍历ruleSet，得到几批Rules，即Set<Rule>。对于每批Rules，调用每个rule.match(plan)来处理传入的OperatorPlan，返回一个匹配成功的List<OperatorPlan> matches，对这些match的plans进行进一步处理。首先获得rule的transformer，然后进行transformer的check()和transform()操作。如果需要Listener操作的，还会遍历listeners，让每个PlanTransformListener监听到transformer进行的transform操作，transformer的reportChanges()方法可以返回他transform操作修改的部分。

代码如下：

    public void optimize() throws FrontendException {

        for (Set<Rule> rs : ruleSets) {
            boolean sawMatch = false;
            int numIterations = 0;
            do {
                sawMatch = false;
                for (Rule rule : rs) {
                    List<OperatorPlan> matches = rule.match(plan);
                    if (matches != null) {
                        Transformer transformer = rule.getNewTransformer();
                        for (OperatorPlan m : matches) {
                            try {
                                if (transformer.check(m)) {
                                    sawMatch = true;
                                    transformer.transform(m);
                                    if (!rule.isSkipListener()) {
                                        for(PlanTransformListener l: listeners) {
                                            l.transformed(plan, transformer.reportChanges());
                                        }
                                    }
                                }
                            } catch (Exception e) {
                                StringBuffer message = new StringBuffer("Error processing rule " + rule.name);
                                if (!rule.isMandatory()) {
                                    message.append(". Try -t " + rule.name);
                                }
                                throw new FrontendException(message.toString(), 2000, e);
                            }
                        }
                    }
                }
            } while(sawMatch && ++numIterations < maxIter);
        }
    }

实现类：

LogicalPlanOptimizer

LogicalPlanOptimizer类是PlanOptimizer的子类

默认加载两个Listener：

Listener的这两个实现在PlanTransformerListener一节具体展开讲述。

初始化的时候会buildRuleSets()，把需要添加的Rule都生成出来，然后校对该Rule是否被强制加入，或被turn off，从而选择性地放入优化规则。以下列举了所有候选的优化规则，Rule是顺序执行的：

Transformer

Transformer是抽象类，有三个方法需要子类实现：

check()方法，利用pattern来匹配plan里符合的operator集合，返回match的operator集

transform()方法，具体实施对tree的转换操作

reportChanges()方法，报告tree的哪部分被transform操作过了（只包括被修改了的或增加了的，不包括删除的node），目的是为了让Listener得知，从而可以修改schema或annotation等等。

继承结构如下：

PlanTransformerListener

PlanTransformListener监听一个plan被修改后会触发。

举例：

当一个Rule把一次join里的Filter步骤提前到join操作之间做，那么过滤部分的input schema很可能需要改变，此时一个schema listener就会被触发并执行。

PlanTransformListener是一个接口，需要实现一个方法：

public void transformed(OperatorPlan fp, OperatorPlan tp) throws FrontendException;

下面具体介绍两个实现类

ProjectionPatcher

作用是在映射操作中修补引用信息

有两个内部静态类

SchemaPatcher

使用于逻辑执行计划优化过程，当plan被transform了之后修补schema信息。

Rule

public abstract class Rule {
    protected String name = null;
    protected OperatorPlan pattern;
    transient protected OperatorPlan currentPlan;
private transient Set<Operator> matchedNodes =
new HashSet<Operator>();
    private boolean mandatory;
    private boolean skipListener = false;

Rule已经把 match(OperatorPlan plan)方法的逻辑实现好了。

子类需要实现的是buildPattern()方法，来制定各自的”模式”，即pattern变量。

子类还需要实现getNewTransformer()方法来实例化一个transformer，transformer的check()和transform()方法会进一步处理rule匹配的operators。

Rulematch()的用途是确保plan的所有子plan都满足该rule的pattern。

实现逻辑比较繁杂。

Rule继承结构

具体每个Rule不分析了。

全文完 :)