SQL查询优化器浅析|青训营笔记

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

postgresql：在国外比较用的多学院派、代码比较优雅、模块化比较好;mysql代码相比较乱（Mysql面向事务的数据库）

为什么SQL查询优化器放在第一节课讲？ SQL是非常流行的，数据分析师，数据挖掘师用SQL就能简单的处理好大数据相关操作，不必特地编写code； SQL被很多接口支持，Spark、hive、MR、Flink都有相关SQL接口

RBO基于规则，CBO基于代价

SQL-->[Parser]-->AST-->[Analyzer]-->Logical Plan-->[Optimizer]-->physical Plan-->[Executor]

1.0 SQL分析

• SQL经过Parser分析成一个抽象语法树
• String -->AST（abstract syntax tree）
• AST经过Analyzer进行SQL分析输出逻辑任务
• optimizer-面对非单机的大数据查询，海量数据下优化很重要（影响查询速度）
• 将优化后的逻辑计划拆分->将拆分后的fragment进行执行每个node有多个实例（跨节点传输效率较低）

01小结

• One SQL rules big data all
• SQL需要依次经过Parser，Analyzer，Optimizerhe和Executorde的处理
• 查询优化器是数据库的大脑，在大数据场景下对查询性能至关重要
• 查询优化器需要感知数据分布，充分利用数据的亲和性
• 查询优化器按照最小化网络数据传输的目标把逻辑计划拆分成多个物理计划片段

2.0 SQL 优化器

• 上下TOP -DOWN 下上BOTTOM-UP
• 第二种优化方式根据优化的方法划分 RBO
• 根据执行代价进行划分 CBO

RBO

• 关系代数，结合律什么的，减小运算
• 优化原则：优化I/O、网络、CPU,内存
• 第一种优化规则：列裁剪
• 去掉一部分列、减少IO，减少后面的计算，【从上往下，先过滤（去掉不需要显示的列）再连接】（减少了SCAN的数据）
• 列裁剪后再谓词下推

谓词下推: 什么时候能推什么时候不能推（分join不同）

• 列裁剪---》谓词下推---》传递闭包
• 列裁剪---》谓词下推---》传递闭包-->Runtime Filter

Runtime Filter

如果提前过滤左边数据减少开销，能不能产生新的FILTER（） Min-MAX 肯产生数据不均衡的问题，IN-LIST在面对海量数据是（数据传递的开销比较大)

CBO

• 使用一个模型估算执行计划的代价，选择代价最小的执行计划
• 算子代价：CPU，内存，磁盘 I/O ，网络 I/O等代价
• 例如：SPARK JOIN 算子代价，分析CPU 和内存的代价权重weight

统计信息：统计表的汇总分区级别、列级别

统计信息的收集方式：在DDL里指定需要收集的统计信息；手动执行explain analyze staement；动态采样

ndv （num distinct value）列里面独立互不相同的数（NDV 也叫做唯一值数，是对表的字段唯一值个数的统计）

02总结：

• 主流RBO实现一般都有几百条基于经验归纳得到的优化规则
• RBO实现简单，优化速度快
• RBO不能保证得到最优的执行计划
• CBO使用代价模型和统计信息估算执行计划的代价
• CBO使用贪心或者动态规划算法寻找最优执行计划
• 大数据场景下CBO对查询性能非常重要

3.0 开源社区实践

Apache Calcite 3.3 -calcite CBO

03总结

• 主流的查询优化器都包含RBO和CBO
• Apache Caicite是大数据领域很流行的查询优化器
• Apache Caicite RBO定义了许多优化规则，使用pattern匹配子数，执行等价变换。
• Apache Caicite CBO基于Volcano/Cascade 框架
• Volcano/Cascade的精髓：Memo、动态规则、剪纸

4.0前沿趋势

• 大数据创业如火如荼，SQL查询优化器仍然是必不可少的一个重要组件
• 引擎架构的进化、云原生、湖仓一体等对SQL查询优化器有新的要求和挑战
• AI加持，学习型查询优化器在不断进化

提问简记： 大数据网络开销还好，主要在CPU和IO 存储和计算不分离性能更好，分用户时段采用不同策略，前沿趋势是存储和计算分离