Hive CBO 为什么依赖统计信息？
面试怎么回答
Hive CBO 需要用表行数、文件大小、列 NDV、NULL 数和最小最大值等统计估算过滤与 Join 后的基数，再比较 Join 顺序、算法和 Shuffle 成本。统计缺失或过期会造成广播大表、错误 Join 顺序等问题。我会在分区产出后增量收集关键统计，并用 EXPLAIN 和实际运行指标校准估算。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
SQL 没改、数据量也差不多，执行计划却突然把大表当成小表去做 Map Join。
CBO 做的是成本比较；如果表行数、NDV 和边界统计不可信，再聪明的优化器也只能用错误输入做决定。
Hive CBO 用表级与列级统计估算每个算子的基数和成本，再决定 Join 顺序、Join 算法等计划；统计缺失或过期会让估算误差层层放大。
CBO 先估算中间结果规模
过滤会剩多少行、两个表 Join 后会膨胀还是收缩，决定了 Shuffle、内存和 CPU 成本。表行数、文件大小、列的 NDV、NULL 数、最小最大值等统计，为选择率和基数估算提供基础。
Join 顺序对分布式成本影响很大
多表关联若先产生巨大中间结果，会带来更多 Shuffle 和落盘；若先用高选择性条件缩小数据，再关联大表，成本可能低很多。Calcite CBO 会比较候选计划，但依赖统计判断哪一侧更小、过滤是否有效。
统计错误会导致连锁误判
分区新增后未收集统计，CBO 可能低估表规模；NDV 过期会错估 Join 基数；数据倾斜和字段相关性也会让独立假设失真。一次低估可能进一步影响广播、Join 顺序、Reducer 数和内存分配。
收集统计也要控制范围和时机
全表频繁 ANALYZE 成本很高。分区表应在新分区产出后收集增量统计，并定期校验汇总；高频参与过滤和 Join 的关键列优先收集列统计。大规模回刷、Schema 变更和数据分布突变后，要触发重新分析。
用 EXPLAIN 对比估算与实际
查看 CBO 计划、各节点估算行数和 Join 选择；结合执行时实际计数、Shuffle 大小和倾斜判断误差来自哪里。不要遇到坏计划就永久写 Hint，先确认统计是否缺失、分区是否被正确裁剪、谓词是否能下推。
统计不是万能真相
直方图、相关列、极端热点 Key 和复杂 UDF 仍可能难以估算。对稳定关键任务可以保留 Hint 或固定策略作为兜底，但要记录原因并周期复核，避免数据分布变化后原来的 Hint 反而变成瓶颈。
参考资料
- Hive Cost-Based Optimization：https://hive.apache.org/docs/latest/user/cost-based-optimization-in-hive/
- Hive EXPLAIN CBO：https://hive.apache.org/docs/latest/language/languagemanual-explain/