分析引擎这一块,都可以用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):使用模型估算执行计划代价,成本最小的执行计划