这是我参与「第四届青训营 」笔记创作活动的第1天

分析引擎这一块，都可以用SQL接口

SQL会经过四个组件的处理，第一步是一个SQL输入，变成输出为AST,然后AST会经过一个Analyzer的处理，输出为一个Logical Plan(就是逻辑的计划)，之后经过一个优化器处理，也是重点内容 Optimizer，然后优化器处理之后，会输出为一个Physical Plan（物理执行计划），最后是Executor，他会执行其计划，然后处理数据，然后发给用户。

Optimizer典型策略

1）去除子查询 2）把操作符放置到union的两边 3）合并2个相邻的filter 4）把filter操作符放置到Project里面，即先做过滤，再选择 5）下推filter至join的左边和右边 6）剪裁列 7）合并两个相邻的limit 8）替换null表达式 9）优化in操作符 10）合并常量 11）简化like表达式 12）简化filter表达式

RBO（Rule-based Optimizer）：根据关系代数等价语义，重写查询 ; 基于启发式规则 ; 会访问表的元信息 (catalog)，不会涉及具体的表数据(data)

列裁剪

在列裁剪中在先根据上方算子需要哪些列，在SCAN时候就只读取需要的列，这与就可以减少读取时间，进行优化。例如下方图片中，就是根据上方算子发现只需要sield,userld,id,sield,name这几列

谓词下推

谓词下推就是把Filterh中查询进行下推，这样在JOIN就只需要连接满足Filter中的就可以了，这样就减少后续算子执行的时间。这下面图片例子中就是把filter中的 user.siteld > 123 进行下推先进行filter后在进行JOIN连接，以此来达到减少后续执行时间的目的。

传递闭包

传递闭包我们直接看下面的例子，在左边JOIN中 pv.siteld = user.siteld , 在filter 中有选择条件 user.siteld > 123,那么JOIN后 pv.siteld 也是大于 123 所以我们不妨在SCAN读表后就进行选择这样就是减少读取列。

runtime filter

runtime filter比较特殊是在运行时实现的，首先就是我们在右边filter之后我们得到了选择后的列，在根据JOIN中的条件我们就可以得到数据的范围信息，然后在运行时传到左边形成一个固定的filter。

CBO（Cost-based Optimizer）：使用模型估算执行计划代价，成本最小的执行计划