- 综合排序
- 最热优先
- 最新优先
- 来自专栏大数据&分布式
Hive CBO优化剖析
基于Operator转为Task，基于物理计划树(算子树) 实现物理优化 CBO优化 实现原理 Hive使用HiveVolcanoPlanner 继承原生的Calcite VolcanoPlanner 实现CBO优化器，CalcitePlanner继承Hive的SemanticAnalyzer(语义解析)，Override重写了基于QB获取逻辑算子树Operator的genOPTree方法。 Hive基于CBO优化的解析数据对象流转如下所示： Hive CBO实现内核：在QB转Operator逻辑计划时进行扩展处理，QB → Calcite CBO优化 → Operator。 本文通过背景介绍、解析流程、CBO优化三部分详述Hive CBO原理。Hive SQL核心解析流程包括解析、语义分析、逻辑优化、物理优化步骤。 Hive CBO优化依赖Calcite 火山模型优化器实现，本文介绍了相关的CBO实现原理，CBO统计元数据和ANALYZE执行实现。 我正在参与2024腾讯技术创作特训营最新征文，快来和我瓜分大奖！
88062编辑于 2024-04-27 - 来自专栏mazhen.tech
基于代价优化（CBO）实现代码导读
CBO的整体思路是：从逻辑查询计划树，自上而下枚举每个逻辑运算符可能的物理算子，从所有可能的执行路径中选择一条评估代价最小的作为物理查询计划。 CBO核心流程的代码在plan/optimizer.go中的physicalOptimize： func physicalOptimize(logic LogicalPlan) (PhysicalPlan
30210编辑于 2023-11-24 - 来自专栏about云
Apache Spark 2.2中基于成本的优化器（CBO）
Spark的基于成本的优化器（CBO）并讨论Spark是如何收集并存储这些数据、优化查询，并在压力测试查询中展示所带来的性能影响。 CBO依赖细节化的统计信息来优化查询计划。要收集这些统计信息，用户可以使用以下这些新的SQL命令： [AppleScript] 纯文本查看 复制代码 ? 查询的性能测试和分析 我们使用非侵入式方法把这些基于成本的优化加入到Spark，通过加入全局配置spark.sql.cbo.enabled来开关这个特性。 总之，关闭CBO,查询花费了241秒。 使用了CBO的Q25 另一方面，用了CBO,Spark创建了优化方案可以减小中间结果（如下）。在该案例中，Spark创建了浓密树而不是左-深度树。 这是因为使用或没使用CBO的查询计划没有不同 (例如，即使没有CBO, Spark’s Catalyst 优化器的柱状图也可以优化这些查询。
2.5K70发布于 2018-03-26 - 来自专栏老虎刘谈oracle性能优化
CBO规则下的优化器还是要按规则办事
另外, like 'xxxxx%' 也用不了降序索引. test case2: with as写法 有些人把with as 的写法当成了SQL优化的方法,好像用了这个语法就能让SQL效率提高, 下面这个案例是把一个复杂的生产案例做了简化 tmp where object_id=100 union all select count(*) from tmp where object_id=200; 上面SQL, 因为tmp被使用了两次, 被优化器自动做了 上面两个案例我认为优化器应该能够做出最好的选择, 实际并不如我们想象的那么美好. oracle数据库有公认的最强大的优化器, 强大如此, 也有一些可以改进的地方. oracle 的优化器是CBO (costed
52430编辑于 2022-06-27 - 来自专栏大数据架构
Spark SQL 性能优化再进一步 CBO 基于代价的优化
它属于 LogicalPlan 的优化，所有优化均基于 LogicalPlan 本身的特点，未考虑数据本身的特点，也未考虑算子本身的代价。 Spark CBO 原理 CBO 原理是计算所有可能的物理计划的代价，并挑选出代价最小的物理执行计划。其核心在于评估一个给定的物理执行计划的代价。 优化 Join 类型 在 Spark SQL 中，Join 可分为 Shuffle based Join 和 BroadcastJoin。 优化多表 Join 顺序 未开启 CBO 时，Spark SQL 按 SQL 中 join 顺序进行 Join。极端情况下，整个 Join 可能是 left-deep tree。 开启 CBO 后， Spark SQL 将执行计划优化如下 ?
1.2K30发布于 2018-10-10 - 来自专栏大数据架构
Spark SQL 性能优化再进一步 CBO 基于代价的优化
它属于 LogicalPlan 的优化，所有优化均基于 LogicalPlan 本身的特点，未考虑数据本身的特点，也未考虑算子本身的代价。 更适合本例 [Spark SQL build side with CBO] 优化 Join 类型 在 Spark SQL 中，Join 可分为 Shuffle based Join 和 BroadcastJoin [Spark SQL join type selection with CBO] 优化多表 Join 顺序 未开启 CBO 时，Spark SQL 按 SQL 中 join 顺序进行 Join。 后， Spark SQL 将执行计划优化如下 [Spark SQL multi join reorder with CBO] 优化后的 Join 有如下优势，因此执行时间降至 71 秒 Join 树不再是 ——解决Spark数据倾斜（Data Skew）的N种姿势 Spark SQL / Catalyst 内部原理 与 RBO Spark SQL 性能优化再进一步 CBO 基于代价的优化 Spark CommitCoordinator
1.6K30发布于 2018-10-09 - 来自专栏BigDataplus
Hive优化器原理与源码解析系列—CBO成本模型CostModel(一)
但除了MapReduce和Tez外，其他引擎都有自己优化器实现。 优化器在用户HiveConf配置的引擎信息，来使用不同的成本模型。 优化器的成本模型CostModel设计的是否完善、是否科学直接决定着CBO优化器计算构建出执行计划plan是否准确，同样Hive优化器根据CostMode也是基于Hive Operator Tree操作树中节点 = hive.cbo.costmodel.cpu，依次类推）： CPU成本 = HiveConf.ConfVars.HIVE_CBO_COST_MODEL_CPU 网络成本 = CPU成本 * HiveConf.ConfVars.HIVE_CBO_COST_MODEL_NET 在这里来确定Join 算法可减少优化器的搜索空间，提高效率。
1.8K30编辑于 2022-04-25 - 来自专栏大数据&分布式
Spark CBO统计元数据
Logical Plan(未解析逻辑计划)； 基于Analyzer#apply规则的匹配作用，绑定树节点信息(元数据Catalog)后生成Logical Plan(逻辑计划)； 基于Optimizer#apply优化低效的逻辑树结构 ，生成Optimized Logical Plan(优化逻辑计划)； 基于SparkPlanner#plan，根据Optimized Logical Plan匹配对应的Strategy并生成一组Physical 统计信息 Spark 2.2 开始支持CBO优化，触发统计元数据更新的时机如下： ANALYZE：AnalyzeTableCommand、AnalyzeColumnCommand； ALTER：AlterTableAddPartitionCommand
69596编辑于 2025-03-20 - 来自专栏沃趣科技
SQL优化案例-改变那些CBO无能为力的执行计划
用户写的sql，Oracle会进行等价改写，即使是RBO优化模式，Oracle也会给你做一些转换，这些转化都是基于一种固定的算法，oracle称这种转换是“启发式”的。 网上有很多优化法则，有的说exists比in效率高，有的说in比exists执行的快，那就要看SQL是如何写的，CBO是如何转换的，是否能转换？当然这种转换不是基于成本的而是“基于启发的转化”。 当Oracle没办法做transformation的时候，可能就是sql产生问题的时候，此时就要我们去找原因了，下面通过一些案例，说明这种优化器无能为力的情况（为了保护客户的隐私，表名和部分列已经重命名
1.2K70发布于 2018-05-15 - 来自专栏数栈技术分享
袋鼠云数栈基于CBO在Spark SQL优化上的探索
原文链接：袋鼠云数栈基于 CBO 在 Spark SQL 优化上的探索 一、Spark SQL CBO 选型背景 Spark SQL 的优化器有两种优化方式：一种是基于规则的优化方式 (Rule-Based 2、CBO 是 RBO 改进演化的优化方式 CBO 是对 RBO 改进演化的优化方式，它能根据优化规则对关系表达式进行转换，生成多个执行计划，在根据统计信息 (Statistics) 和代价模型 (Cost ● CBO 优化例子 而使用 CBO 优化器得到的执行计划图如下： 我们不难看出，CBO 优化器充分考虑到中间结果，感知到中间结果的变化满足能 Broadcast Join 的条件，所以生成的最终执行计划会选择 四、未来展望 在 CBO 优化方面持续投入研究后，Spark SQL CBO 整体相比较 RBO 而言已经有了很大的性能提升。 AQE 是动态 CBO 的优化方式，是在 CBO 基础上对 SQL 优化技术又一次的性能提升。
1.6K20编辑于 2022-06-10 - 来自专栏BigDataplus
Hive优化器原理与源码解析系列—CBO成本模型CostModel(二)
Hive优化器原理与源码解析系列—CBO成本模型CostModel(一) 这篇文章是关于Tez引擎的CostModel成本模型：HiveTezCostModel Tez引擎的成本模型，相对比较完善， SMB Join SMB Join又称Sort Merge Bucket Join，是对上述Bucket Map Join关联算法的优化，如果要Join的数据已按Join key排序的，则避免创建哈希表 相对于MR引擎的默认成本模型要完善了很多，越准确的成本模型越有利于CBO构建出越优化的执行计划。
81320编辑于 2022-04-25 - 来自专栏大数据&分布式
Presto CBO统计元数据
ConnectorMetadata#getTableStatistics获取元数据信息，目前仅Hive Connector、Iceberg Connector支持获取元数据的统计信息，统计信息用于树节点Visitor遍历时进行CBO 优化。 ConnectorMetadata#getTableStatistics获取元数据信息，目前仅Hive Connector、Iceberg Connector支持获取元数据的统计信息，统计信息用于树节点Visitor遍历的CBO 优化： Hive统计元数据：调用HiveStatisticsProvider#getTableStatistics方法，底层调用对应Metastore Client RPC接口，包括 getTableStatistics
53342编辑于 2024-05-12 - 来自专栏bisal的个人杂货铺
CBO如何选择相同cost的索引
ACOUG年会杨长老的演讲中，曾提到一个问题， 一条SQL语句，两种执行计划的cost值相同，CBO是如何选择执行计划？ 对于以下SQL， select * from z where a=1 and b=1; 根据10053显示，可以看出，IDX_Z_01和IDX_Z_02这两个索引，cost相同，CBO会选择何种执行计划 值相同的索引的选择》 http://www.dbsnake.net/handle-equally-costed-indexes.html 文章总结来讲， 对于Oracle 10gR2及其以上的版本，CBO 先验证(2)的观点，从上面10053可以看出，两个索引的cost相同，叶子块数相同，此时CBO选择的是IDX_Z_01，因为他的名字，排在IDX_Z_02前面， Best:: AccessPath: Index: IDX_Z_02 Col#: 2 LVLS: 1 #LB: 20 #DK: 10000 LB/K: 1.00 DB/K: 1.00 CLUF: 18.00 此时CBO
1.3K60发布于 2019-01-30 - 来自专栏罗超频道
360来了个CBO，对搜索市场影响几何？
刘允于去年7月离开Google此后去向不明，半年后的今天被证实加入360担任CBO（首席商业官）。 他并不属于360搜索，而是整个奇虎的CBO。但几乎可以肯定的是，搜索的商业化是他的重点工作之一。
718110发布于 2018-04-28 - 来自专栏Oracle数据库技术
CBO 查询转换(3)：结合谓词下推机能（Join Predicate Pushdown）
咱们来接下来探讨一下 View 和表结合，这时候 CBO 会如何转换用户的 SQL 呢。 通常的一个 View 和表去结合，View 里没什么特殊处理的话，就直接去使用表作 JOIN 即可。 这种情况下，CBO 就会想展开困难的话，那要是把 View 和表结合的谓词下推到 View 中是不是会产生什么神奇效果呢。 继续通过 10053 EVENT Trace 再去探究一下，CBO 是怎样实现的。
37010编辑于 2022-08-19 - 来自专栏bisal的个人杂货铺
Oracle CBO选错执行计划的一种场景
Resc: 2.0002 Resc_io: 2.0000 Resc_cpu: 7121 Resp: 2.0002 Resp_io: 2.0000 Resc_cpu: 7121 Oracle CBO 0 10-JAN-18 测试时间是1月11日，前一天22:00统计信息采集任务，就认为表中记录数为0，即是一张空表，但是由于索引统计信息正确，显示几千万数据，自然CBO 了解了下，由于做性能测试，10日曾经清理了表数据，11日进行了批量数据导入，但是统计信息，未进行手工采集，因此用了前一天自动采集的，导致统计信息，和表的实际信息不符，为CBO提供了错误的信息，因而选错了执行计划 正如dbsnake书中所说，若系统批量导入数据，建议业务使用前，立即采集相关表的统计信息，因为每日22:00，才会进行统计信息自动采集，之间的时间差，就有可能因为统计信息不准，让CBO选错执行计划。 虽然CBO对于执行计划cost计算，属于机密，但是10053可以间接，让我们了解CBO如何选择，某一个执行计划，再根据表、索引等统计信息，结合来看，有可能就发现一些线索。
60860发布于 2019-01-30 - 来自专栏小麦苗的DB宝专栏
【DB笔试面试574】在Oracle中，什么是RBO和CBO？
♣ 题目部分 在Oracle中，什么是RBO和CBO？ ♣ 答案部分 Oracle数据库中优化器（Optimizer）是SQL分析和执行的优化工具，是Oracle数据库中内置的一个核心模块。 Oracle数据库里的优化器又分为RBO（rule-Based Optimizer，基于规则的优化器）和CBO（Cost-Based Optimizer，基于成本的优化器）这两种类型。 从Oracle 10g开始，Oracle数据库默认都是基于CBO的优化方式。 （二）CBO 从Oracle 7开始就引入了CBO。CBO是基于成本的优化器，它根据可用的访问路径、对象的统计信息、嵌入的Hint来选择一个成本最低的执行计划。 优化器在使用CBO时，主要参照的是表、列及索引的统计信息。
1.6K20发布于 2019-09-29 - 来自专栏Oracle数据库技术
CBO 查询变化(1):子查询展开机能（Subquery Unnesting）
有时候用户写的 SQL，对于优化器来说并不一定是最好的，可能作出的执行计划不会用到合适的结合处理。 所以，CBO 会在作执行计划之前，用一堆十分难懂的机能去转换用户作的 SQL。
40520编辑于 2022-08-19 - 来自专栏数据和云
深入内核：CBO对于Cost值相同索引的选择
这里我们稍微讨论一下CBO对于Cost值相同的索引的选择，可能会有朋友认为在同样Cost的情况下，Oracle会按照索引名的字母顺序来选择索引，实际上并不完全是这样，CBO对于Cost值相同的索引的选择和 原理说明 MOS上文章“Handling of equally ranked (RBO) or costed (CBO) indexes [ID 73167.1]”明确指出——When the CBO See Bug 6734618 这意味着对于Oracle 10gR2及其以上的版本，CBO对于Cost值相同的索引的选择实际上会这样： 1-如果Cost值相同的索引的叶子块数量不同，则Oracle会选择叶子块数量较少的那个索引 电子渠道（网络销售）分析系统、数据治理 IT基础架构 分布式存储解决方案 | zData一体机 | 容灾环境建设 数据架构 Oracle DB2 MySQL NoSQL 专项服务：架构/安全/容灾/优化 /整合/升级/迁移 运维服务：运维服务 代维服务 人才培养：个人认证 企业内训 软件产品：SQL审核、监控、数据恢复 应用架构 应用软件和中间件：数据建模 | SQL审核和优化 | 中间件服务
1.9K60发布于 2018-03-05 - 来自专栏Oracle数据库技术
深入SQL执行计划之CBO查询转换(5)：星型转换（Star Transformation）
“Star Transformation”是ORACLE为了解决上面问题，结合ORACLE数据库特有的“Bitmap”索引而作出的优化。 “Star Transformation”是如何实现的呢？ 在看一下CBO的动作，我们可以看到启用”Star Transformation“后，上面的SQL文被转换成了下面的SQL文： SELECT "T1" .
48910编辑于 2022-08-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号