山大软工实践hive(10)-transform方法流程结束

2021SC@SDUSC

山大软工实践hive(10)-transform方法流程结束

dispatch方法的后半部分

在我查看的这个优化器的transform方法里，defaultProc是null，不过这里rule多半不是null，如下
proCtx为null

proc在这里只能取到FilterTransformer，它是该优化器的内部类
然后下下它调用了该类的process方法

可以看到除了nd其他都没有被使用
这个方法里要先解决这些标记荧光的地方是干什么的

继承了Node，可以看做是Node的扩展。里面的重点变量是 TypeInfo typeInfo

在Oprator类里，看到了conf，conf是 T extends OperatorDesc

而getPredicate方法只在FilterDesc里有,类型为ExprNodeDesc

接下来看generateClause，它同为该内部类的方法

这个方法走了一遍tansform方法的流程，除了返回值不同
这个OrExprProcessor类也是内部类，根据之前的推论，这个在最后会被调用process方法
另外，这里的startNoeds是被选中的nd.getConf.getPredicate（），这个walk方法会对这个出发的节点进行层次遍历。

再看它的process

超级长。不过这个方法通过看注释能够明显知道它在干这个优化器注释里说的事：什么or子句改成in，并且处理其中的and子句

先看注释1,2对应部分，首先看是不是or运算，如果是则看是否小于阈值（优化器初始化时的参数，应该可以修改，如下）


顺便，突然意识到，可以去搜这个路径的配置文件的相关信息，或许能知道是干什么的，在这里，找到了hive配置说明

虽然可以想象把一系列or统一成in，但不知道是如何效率上的提升，以及可行性

不过这里提醒我的是，HiveConf.Confvars，里面存了一堆用户可操作的配置信息

先跳过这方法后面部分，先看返回的结果
首先，这个方法要么返回null，要么返回修改后的predicate，返回后回到dispatch方法

然后同理，有则返回predicate，返回到walker的dispatch

这里往retMap放predicate存起来，这个在后面会在当nodeoutput不为null时返回所有头结点的（nd，retval）键值对，至于这个方法的return，在后面没用上，就不截图了

然后会回到generateInClause

可以理解为，输入旧predicate，如果不改变，则返回null，改变则返回newPredicate，再返回到process

如果有新的predicate，再把filter（where语句）的内容修改为新的子句就行。然后这里return null，返回到dispatch，这一段就和上面类似，不过retMap存的键值对的值都为null。最后返回到transform

return pctx；虽然这个在过程中没有什么改变，但实际改变的内容我们已经看到了：FilterOperator对应的语句的改变
也意识到，不管walker怎么花里胡哨，这里的Rule “FIL%”限制死了要被计算的内容：仅限一个FIL算子

也可以认为，对于各种奇怪的优化，它们会写不同的优化规则的正则表达式，只有满足条件的才会被尝试优化，这样的正则表达式表达的是算子链，代表该优化器要优化的结构。然后让walker去遍历，去看能不能优化，每查看一个算子，把Cost最小的优化的结果记录到算子本身，也可能是null代表不优化。

总结

这篇就先到这，后面有能力在回头看这个OrExpression.process后面部分
下篇可以先去看自己搜到过原理并理解了的优化器，看看它们的各部分怎么处理