向量化与 CBO 各自解决什么
向量化把逐行处理的执行方式改成按批处理，一批约上千行一起算，函数调用次数大幅减少，扫描密集的查询受益最明显。CBO 则是在编译期用统计信息估算每种执行计划的代价，决定 join 顺序与连接方式。两者相互独立，但都依赖一件事：表与分区的统计信息得是真的。
基本信息
| 向量化 | 按批（约千行）列式处理，降低逐行开销 |
|---|---|
| CBO | 基于代价优化，选择 join 顺序与算法 |
| 共同依赖 | ANALYZE 收集的行数与列统计信息 |
| 开关 | hive.vectorized.execution.enabled、hive.cbo.enable |
| 前提 | ORC 等列式存储格式效果最好 |
典型使用场景
- 宽表扫描型报表：一行代码改开关就能看到明显提速
- 多表关联链路：统计信息准确时 CBO 才能选对连接顺序
- 分区表增量加工：按分区逐个收集统计，避免全表重算
- 新手调优：先看 EXPLAIN 里的行数估算是否离谱，再决定是否加 hint
- 引擎混用环境：向量化只在部分引擎生效，跨引擎任务不要把它当通用优化手段
开启与收集统计
开启与收集统计
-- 会话级开启向量化与 CBO
set hive.vectorized.execution.enabled=true;
set hive.vectorized.execution.reduce.enabled=true;
set hive.cbo.enable=true;
-- 收集分区统计信息，CBO 才有决策依据
ANALYZE TABLE dwd_trade_order_di PARTITION (dt='2026-10-12')
COMPUTE STATISTICS FOR COLUMNS;
-- 查看估算行数是否合理
EXPLAIN SELECT count(1) FROM dwd_trade_order_di WHERE dt='2026-10-12';能力与前提对照
| 能力 | 关键参数 | 前提条件 |
|---|---|---|
| 向量化读取 | hive.vectorized.execution.enabled | 列式存储格式 |
| 向量化 reduce | hive.vectorized.execution.reduce.enabled | 聚合算子支持批处理 |
| CBO 连接顺序 | hive.cbo.enable | 表与列统计信息 |
| 统计信息收集 | ANALYZE TABLE ... COMPUTE STATISTICS | 按分区定期调度 |
| 计划查看 | EXPLAIN | — |
统计信息不是一次性工作：新分区每天产出，统计就要跟着更新，否则 CBO 一直拿旧数据做判断，计划可能比人工写的还差。
向量化对自定义函数与部分复杂表达式不支持，遇到不支持时会静默回退到逐行执行；以为开了开关就一定加速，是常见的误判。
排查顺序怎么排
看到任务慢，先看 EXPLAIN 里的估算行数与实际差多少，再决定是补统计信息还是加连接提示；确认计划合理之后，才轮到向量化这类执行层开关。顺序颠倒的话，人工 hint 会掩盖统计信息缺失这个根因，下次换个任务又会重新踩一遍。
日常维护清单
- 每天对新分区补收统计信息，加入调度而非人工执行
- 定期抽样对比开关前后的执行时间，确认收益仍然存在
- 记录自定义函数清单，评估能否改写成内置表达式以恢复向量化
- 对超宽表的列统计信息成本做评估，必要时只收关键列