openLooKeng新下推框架的介绍与实践

openLooKeng执行计划优化简介

在讲述下推框架之前，我们先来简单介绍一下openLooKeng执行计划优化的大致流程。

如上图所示，接收到用户SQL语句之后，SQL被转换成一个Abstract syntax tree (AST)树。AST树再被转换成逻辑执行计划树。然后，也就是执行计划优化过程中最重要的一步，使用规则（Rule）或者优化器（Optimizers）进行执行计划优化，每一个PlanOptimizer可以操作一个子执行计划树，PlanOptimizer基于统计或者经验，用一个更优的子执行计划替换当前的子树，达到优化的目的。PlanOptimizers通常是长期的经验累积得出来的一些优化规则，比如谓词下推、join reorder等等。PlanOptimizers可以存储一些物理执行信息在ConnectorHandle中。新下推框架则工作在这一层。

得到最优的执行计划之后，逻辑执行计划被转换成物理执行计划，然后被分片，分割成按照stage执行的一个个子树，最终调度到worker上执行。

PrestoSql下推方案介绍

最初，openLooKeng是从PrestoSql演进而来，在其基础上增加了很多功能特性，以及大量的性能优化。在讲述openLooKeng的新下推框架之前，先大概介绍其原下推方案。

• 根据社区的讨论，PrestoSql原下推框架有一些目标:

1）使用现有的Rule或Optimizer的框架，而且不是使用基于visitor模式的PlanOptimizers来实现下推，同时能够让connector提供转换rules来实现下推；

2）并不是建立一个原生的机制来支持所有操作的下推。

• 先来看看prestoSql的执行过程：

1）首先，引入一些列的下推规则，每一个规则负责下推相应的操作到TableScan操作中，比如PushFilterIntoConnector, PushProjectionIntoConnector, PushAggregationIntoConnector等等；

2）上述的这些rules通过指定的metadata调用与connectors交互，如果connector支持这个操作下推，操作则被下推到TableScan操作，同时在connectorTableHadle中记录相关信息。

• 下面以PushFilterIntoConnector为例说明。