简单了解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
多表物化视图
相关文章
|
消息中间件 分布式计算 大数据
大数据面经 字节跳动 (整理)
大数据面经 字节跳动 (整理)
839 0
|
存储 分布式计算 运维
【2023云栖】刘一鸣:Data+AI时代大数据平台建设的思考与发布
本文根据2023云栖大会演讲实录整理而成,演讲信息如下: 演讲人:刘一鸣 | 阿里云自研大数据产品负责人 演讲主题:Data+AI时代大数据平台应该如何建设
103757 16
|
3月前
|
人工智能 运维 Apache
Flink Agents 0.3 Roadmap解读
Apache Flink Agents 是 Apache Flink 新晋子项目,专注构建事件驱动的流式 AI Agent。0.3 版本 roadmap 已公布:支持 Agent Skills 集成、Mem0 长期记忆、跨语言 Action/Events、Python 3.12、日志分级与可观测性增强等,目标打造生产级流式 Agent 框架。
625 2
|
3月前
|
存储 分布式计算 运维
迅雷基于阿里云 EMR Serverless Spark 实现数仓资源效率与业务提升
迅雷基于阿里云 EMR Serverless Spark 实现数仓资源效率与业务提升,在迁移到 EMR Serverless Spark 之后,TCO 明显下降,平台按作业生命周期弹性拉起与回收,只为实际消耗付费;同时,托管化带来了稳定性与调度效率提升;更关键的是交付确定性提升,大作业整体可提速约 1 小时,报表链路从长尾波动变成更可控的出数节奏。
|
存储 SQL 分布式计算
数仓架构师必知必会
数仓架构师必知必会
|
SQL Serverless 测试技术
体验 Serverless StarRocks × Paimon (DLF) 查询 TPC-DS 标准库性能
本文介绍如何通过共享TPC-DS样例数据集,创建并绑定DLF Catalog到StarRocks实例,实现高效数据查询与分析。内容涵盖RAM用户授权、外部Catalog连接、性能测试(如TPC-DS Query 3)、数据写入内外表、物化视图构建数仓DWD-ADS层,以及通过Quick BI进行可视化报表展示的完整流程,助力快速搭建湖仓一体架构。
326 0
|
SQL 存储 缓存
阿里云EMR StarRocks X Paimon创建 Streaming Lakehouse
讲师焦明烨介绍了StarRocks的数据湖能力,如何使用阿里云EMR StarRocks构建基于Paimon的极速实时湖仓,StarRocks与Paimon的最新进展及未来规划。
806 59
|
缓存 分布式计算 资源调度
Spark 与 MapReduce 的 Shuffle 的区别?
MapReduce 和 Spark 在 Shuffle 过程中有显著区别。MapReduce 采用两阶段模型,中间数据写入磁盘,I/O 开销大;而 Spark 使用基于内存的多阶段执行模型,支持操作合并和内存缓存,减少 I/O。Spark 的 RDD 转换优化减少了 Shuffle 次数,提升了性能。此外,Spark 通过 lineage 实现容错,资源管理更灵活,整体大数据处理效率更高。
|
数据采集 存储 数据挖掘
基于 StarRocks 的风控实时特征探索和实践
【6月更文挑战第9天】StarRocks 是一款高性能分析型数据库,适用于风控实时特征处理,提供快速数据分析,助力企业高效准确的风控决策。通过建立适合的数据模型,收集整合实时特征数据,并利用 StarRocks 的实时加载与查询功能,企业能实时计算风险指标。同时,确保数据准确性、一致性和完整性,以及进行性能优化,是实现高效风控的关键。随着业务发展,持续优化 StarRocks 应用将帮助企业应对复杂风险挑战,推动健康发展。
454 8
|
消息中间件 分布式计算 Kafka
50道大数据精选面试题
50道大数据精选面试题