hive 成本优化器 (CBO - Cost-Based Optimizer) 原理

Hive 的 成本优化器（CBO, Cost-Based Optimizer） 是 Hive 从 规则驱动（RBO） 向 数据驱动 转型的关键组件，它通过统计信息估算执行计划的成本，从而选择最优的物理执行计划，显著提升复杂查询（尤其是多表 Join、子查询）的性能。

---

一、为什么需要 CBO？

在 CBO 出现前，Hive 仅使用 RBO（Rule-Based Optimizer），依赖固定规则优化（如谓词下推、列裁剪），但无法回答：

• 哪张表更小？应该作为 MapJoin 的小表？
• Join 顺序如何安排才能减少中间数据量？
• 是否值得对某个子查询物化？

✅ CBO 的核心思想：用数据说话，选择“代价最低”的执行路径。

---

二、CBO 的工作原理

1. 依赖统计信息（Statistics）

CBO 需要以下元数据来估算成本：

统计项	说明	获取方式
表行数（numRows）	表总记录数	ANALYZE TABLE ... COMPUTE STATISTICS
列基数（cardinality）	列去重值数量	... FOR COLUMNS col1, col2
列最小/最大值	用于范围查询估算	同上
列空值比例（numNulls）	影响过滤效率	同上
表大小（totalSize）	估算 I/O 成本	自动收集或手动分析

📌 统计信息存储在 Metastore 中（TAB_COL_STATS, PART_COL_STATS 表）。

---

2. 优化流程

SQL → AST → Logical Plan 
       ↓
   [RBO 优化]（谓词下推、列裁剪等）
       ↓
   收集统计信息 → 估算各算子成本
       ↓
   [CBO 优化]（基于成本重排 Join 顺序、选择 Join 策略等）
       ↓
Physical Plan → 执行引擎

---

三、CBO 能优化哪些场景？

✅ 1. Join 顺序重排（Join Reordering）

• 问题：A JOIN B JOIN C，不同顺序产生中间结果大小差异巨大。
• CBO 决策：根据表大小和过滤率，选择 (A ⋈ B) ⋈ C 还是 A ⋈ (B ⋈ C)。
• 效果：减少 Shuffle 数据量，避免数据倾斜。

✅ 2. 自动选择 Join 策略

• 根据表大小决定使用：
  • MapJoin（小表广播）
  • Common Join（Shuffle + Reduce）
  • SMB Join（分桶表合并）
• 无需手动写 /*+ MAPJOIN */！

✅ 3. 子查询优化（Subquery Decorrelation）

• 将相关子查询转为 Join：

  -- 相关子查询
  SELECT * FROM orders o 
  WHERE o.amount > (SELECT AVG(amount) FROM orders WHERE user_id = o.user_id);
  
  -- CBO 可能转为：
  SELECT o.* 
  FROM orders o
  JOIN (SELECT user_id, AVG(amount) AS avg_amt FROM orders GROUP BY user_id) t
    ON o.user_id = t.user_id
  WHERE o.amount > t.avg_amt;
  

✅ 4. 分区裁剪增强

• 结合统计信息，更精准地跳过无关分区。

---

四、如何启用 CBO？

步骤 1️⃣：开启 CBO 参数

-- 启用 CBO（Hive 0.14+ 默认开启，但需确认）
SET hive.cbo.enable = true;

-- 启用 Join 重排（关键！）
SET hive.join.reorder = true;          -- Hive 2.x+
SET hive.optimize.joinreorder = true;  -- Hive 1.x（旧参数）

-- 启用基于成本的 MapJoin 转换
SET hive.auto.convert.join = true;
SET hive.auto.convert.join.noconditionaltask = true;
SET hive.auto.convert.join.noconditionaltask.size = 20971520; -- 20MB

步骤 2️⃣：收集统计信息（最关键！）

-- 全表统计（行数、文件大小）
ANALYZE TABLE sales COMPUTE STATISTICS;

-- 列级统计（基数、空值、min/max）
ANALYZE TABLE sales COMPUTE STATISTICS FOR COLUMNS product_id, region, amount;

-- 分区表（需指定分区）
ANALYZE TABLE sales PARTITION(dt='2023-01-01') COMPUTE STATISTICS;
ANALYZE TABLE sales PARTITION(dt='2023-01-01') COMPUTE STATISTICS FOR COLUMNS ...;

⚠️ 没有统计信息，CBO 会退化为 RBO！

---

五、验证 CBO 是否生效

方法 1：查看执行计划

EXPLAIN FORMATTED SELECT ...;

• 检查是否有 Cost: xxx 字段；
• 观察 Join 顺序是否合理。

方法 2：查看日志

• 开启 debug 日志：

  SET hive.log.level=DEBUG;
  

• 搜索 Cost-based optimizer 相关日志。

方法 3：对比优化前后

• 关闭 CBO 执行一次，再开启执行一次，对比耗时。

---

六、CBO 的局限性与注意事项

限制	说明
依赖统计信息质量	过期/缺失统计信息会导致错误决策
不支持所有操作符	如窗口函数、复杂 UDF 可能跳过 CBO
动态分区统计难维护	需定期增量更新统计信息
大表全列统计开销大	可只对 Join/Where 涉及的列收集
Hive 版本差异	Hive 2.x+ CBO 更成熟，1.x 功能有限

---

七、最佳实践

1. 定期更新统计信息（尤其高频更新的表）：

   -- 增量收集（Hive 3.0+）
   ANALYZE TABLE sales UPDATE STATISTICS FOR COLUMNS ...;
   

2. 只收集关键列的统计信息，避免全表全列分析；

3. 结合分区设计，对热点分区重点收集；

4. 监控 CBO 决策，发现异常时可临时关闭：

   SET hive.cbo.enable = false; -- 用于调试
   

5. 生产环境建议开启，但需配套统计信息管理流程。

---

八、总结

特性	说明
核心价值	基于数据分布智能选择最优执行计划
关键前提	准确、及时的统计信息
主要收益	Join 性能提升 2~10 倍，减少资源浪费
适用场景	多表关联、复杂子查询、大表 Join
推荐指数	⭐⭐⭐⭐☆（需配套统计信息管理）

💡 CBO 不是“银弹”，而是“数据驱动优化”的基础设施。
当你的 Hive 数仓进入中大规模阶段，建立统计信息收集机制 + 启用 CBO 是性能调优的必经之路。

通过合理使用 CBO，你可以让 Hive 从“被动执行 SQL”升级为“主动优化查询”，真正释放大数据分析的性能潜力。