简单了解RBO、CBO和HBO

简介: 简单了解RBO、CBO和HBO

RBO

基于规则的优化器 指的是不需要额外的信息,通过用户下发的SQL语句进行的优化,主要通过改下SQL,比如SQL子句的前后执行顺序等。比较常见的优化包括谓语下推、字段过滤下推、常量折叠、索引选择、Join优化等等。RBO对数据不敏感,在表大小固定的情况下,无论中间结果数据怎么变化,只要SQL保持不变,生成的执行计划就都是固定的

CBO

基于代价的优化器,根据收集的统 计信息来计算每种执行方式的代价,进而选择最优的执行方式。

引人了重新排序 Join(JoinReorder)和自动MapJoin(AutoMapJoin )优化规则等,同时基于 Volcano 模型的优 化器会尽最大的搜索宽度来获取最优计划

可以设置规则白名单(使用哪些优化规则)、黑名单(关闭哪些优化规则)

Optimizer 会提供谓词下推( PredicatePushDown )优化,主要目的是尽量早地进行谓词过滤,以减少后续操作的数据量,提高性能。但需要注意的是:

UDF:对于UDF是否下推,优化器做了限制,不会任意下推这种带有用户意图的函数,主要是因为不同用户书写的函数含义不一样,不可以一概而论。不确定函数:对于不确定函数,优化器也不会任意下推,比如 sample 函数,如 果用户将其写在 where 子句中,同时语句存在Join ,则优化器是不会下推到 TableScan 的 隐式类型转换:书写 SQL 语句时,应尽量避免 Join Key 存在隐式类型转换。

CBO优化器通过给CPU、IO、NETWORK赋予代价,来指导生成更优的执行计划

CBO组成

① Meta Manager:优化器在选择优化策略时会使用一些元数据,如数据表元数据,分区元数据,统计信息元数据等。
② Statistics:为优化器提供准确的统计信息,进行优化策略的选择
③ Rule Set:每一条优化规则都是特定场景下的优化点,优化器根据代价模型选择启用哪些规则。规则分为:
    + Substitute Rule:优化了一定好的规则
    + Explore Rule:优化后需要考虑各种因素的规则
    + Build Rule:优化后不能再次优化的规则
④ Volcano Planner Core:把所有信息统一处理,根据代价模型,涉及代价最小的方案

代价计算:发生在产生的新节点注册阶段,计算规则如下:

+ 如果代价不存在或者子节点的代价还没计算,则忽略
+ 如果有代价,则将本身的代价和子节点的代价相加,若小于目前的最优策略,则认为当前节点是最优的。还会对其父节点的代价进行迭代计算,进而估算整条链路的代价

HBO

(History-Based Optimizer,基于历史的优化器)

在任务稳定的情况下,可以考虑基于任务的历史执行情况进行资源评估,即采用HBO

提高 CPU 利用率
提高内存利用率
提高 Instance 并发数
降低执行时长

针对大促这类数据量暴涨的场景, HBO 也增加了根据数据量动态调整 Instance 数的功能,主要依据 Map 的数据量增长情况进行调整。

HBO 分配资源方法:

① 核心思想:基础资源评估+加权资源评估
② 基础资源评估:对于map任务的数量根据用户提交任务的数据量和每个map任务期望执行的数据量来估算;对于reduce任务个数由map任务的输入数据量估算或者根据近几天map任务对reduce任务的输出数据量的平均值进行估算。
③ 加权资源评估:通过当前任务近期执行速度与任务预期执行速度作比较,如果小于预期则等比例添加资源,估算出最终的任务数量

参考资料:

https://www.6aiq.com/article/1670429368683
https://zhuanlan.zhihu.com/p/627340125

常见RBO优化点

各种表达式的重写和化简
Cast 消除
谓词化简
公共谓词提取
列裁剪
Shuffle 列裁剪 (确保任何多余的列不要参与网络传输)
谓词下推
等价谓词推导(常量传播)
Outer Join 转 Inner Join
Limit Merge
Limit 下推
聚合 Merge
Intersect Reorder
常量折叠
公共表达式复用
子查询改写
Lateral Join 化简
Empty Node 优化
Empty Union, Intersect, Except 裁剪
In 转 Semi Join 或者 Inner Join  (http://mysql.taobao.org/monthly/2023/01/01/)
聚合算子复用
  # 比如对于下面的 SQL:
  # SELECT AVG(x), SUM(x) FROM table
  #我们可以让 AVG(x) 复用 SUM(x) 的计算结果,减少计算量
Primary Key 相关优化
冗余 Group By 消除
Sum 常量转 Count
Data Skipping

常见CBO优化点

多阶段聚合优化
Join 左右表 Reorder
Join 多表 Reorder
Join 分布式执行选择
Shuffle Join
Broadcast Join
Bucket Shuffle Join
Colocate Join
Replication Join
Join 和 Aggregate Runtime Colocate, 避免 Shuffle
CTE 复用
CTE 列裁剪
Agg 上拉
Agg 下推 Join
Agg 下推 GroupingSets
窗口下推 Group By
算子融合
物化视图选择与改写
利用基数信息进行优化

HBO常见优化点

表元数据本地缓存(表来源、表定义、分区个数、分区信息、文件列表、统计信息等)
hdfs文件缓存
sql执行记录结果集落表(sql提交失败、运行失败、运行成功)
保存历史sql执行时,预估内存值和实际消耗内存值
DataCache
多表物化视图
相关文章
|
6月前
|
存储 关系型数据库 MySQL
MySQL查询执行计划详解(EXPLAIN)
一、单表查询 访问方法/访问类型: • const:通过主键值或唯一二级索引与一个常熟进行等值查询(不包括NULL),只会生成一条记录 • ref:普通二级索引与一个常数进行等值比较,可能生成多条记录 • ref_or_null:ref的前提下可以加上or key is null • range:对应的扫描区间为若干个单点扫描区间或范围扫描区间(不包括负无穷到正无穷的范围) • index:扫描区间为全表,但是可以在二级索引中扫描(因为二级索引每条记录占用空间更小,所以需要读的页更少) • all:直接扫描全部的聚集索引记录
|
SQL Oracle 关系型数据库
Oracle优化04-Optimizer优化器
Oracle优化04-Optimizer优化器
108 0
|
SQL Oracle 关系型数据库
Oracle优化05-执行计划
Oracle优化05-执行计划
461 0
|
SQL Oracle 关系型数据库
|
SQL 存储 关系型数据库
几个必须掌握的SQL优化技巧(三):Explain分析执行计划
在应用的开发过程中,由于开发初期的数据量一般都比较小,所以开发过程中一般都比较注重功能上的实现,但是当完成了一个应用或者系统之后,随着生产数据量的急剧增长,那么之前的很多sql语句的写法就会显现出一定的性能问题,对生产的影响也会越来越大,这些不恰当的sql语句就会成为整个系统性能的瓶颈,为了追求系统的极致性能,必须要对它们进行优化。
297 0
几个必须掌握的SQL优化技巧(三):Explain分析执行计划
|
SQL 索引 存储
执行计划的生成
原文:执行计划的生成   SQL Server使用许多技术来优化资源消耗: 基于语法的查询优化; 无用计划匹配以避免对简单查询的深度优化; 根据当前分布统计的索引和连接策略; 多阶段的查询优化以控制优化开销; 执行计划缓冲以避免重新生成执行计划;   以上技术按以下顺序执行: 解析器; 代数化器; 查询优化器; 执行计划生成,缓冲和hash计划生成; 查询执行;   其执行顺序如下:    一、解析器(parser)   当查询被提交时,SQL Server将它传递给关系引擎中的解析器。
1131 0
|
SQL 关系型数据库 MySQL
sql优化——explain
sql优化——explain http://www.bieryun.com/3431.html 利用explain可以得到sql的执行计划,是查询性能优化不可缺少的一部分。 explain得到的列明解释: id: 用来标识select语句的,id越大越先执行。
1542 0
|
SQL 数据库 索引