Hive 分区表和分桶表有什么区别？
面试怎么回答
分区按字段值形成目录，核心是通过分区裁剪减少扫描，适合日期、地区等常用过滤字段；分桶是在表或分区内部对字段做 Hash，按固定桶数组织数据，主要服务抽样、稳定分布和兼容条件下的 Join 优化。生产设计时我会先看过滤模式决定分区，再看 Join Key 和引擎能力决定是否分桶，同时评估分区数乘桶数带来的文件量，避免高基数分区和过多小文件。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多人会回答：
“分区是按字段建目录，分桶是按字段做 Hash。”
定义没错，但面试官更想知道的是：它们分别解决什么问题，生产中应该怎么选。
一句话概括：
分区解决少扫描哪些目录，分桶解决一个分区内部如何稳定分布数据。
第一步：先看分区解决什么问题
分区键的不同取值通常对应不同目录。
例如按 dt 分区：
table/dt=2026-08-23/
table/dt=2026-08-24/查询条件里带上分区字段后，Hive 可以做 Partition Pruning，只读取相关目录，而不用扫描整张表。
因此分区适合：
- 经常作为查询过滤条件的字段
- 日期、小时、地区、业务线等相对可控的取值
- 需要按目录进行生命周期和权限管理的场景
但分区不是越细越好。
如果按 user_id 这种高基数字段分区，会制造海量目录、分区元数据和小文件，查询规划与运维成本都会上升。
第二步：再看分桶解决什么问题
分桶会对指定字段计算 Hash，再按固定桶数把数据分到不同文件或数据集合中。
例如：
CLUSTERED BY (user_id) INTO 32 BUCKETS同一个 user_id 会稳定进入对应桶中。
分桶常用于：
- 对桶字段进行抽样
- 让相同 Key 的数据按固定规则分布
- 在引擎和参数支持时优化 Bucket Join
- 配合桶内排序改善特定读取模式
分桶通常发生在分区内部。可以先按 dt 选择目录，再按 user_id 把当天数据分成固定数量的桶。
第三步：真正的区别在“裁剪”与“组织”
分区是显式边界
查询写出 dt='2026-08-24'，引擎可以直接跳过其他日期目录。
如果查询没有分区过滤，分区表仍可能扫描大量目录。
分桶是固定分布
桶号由 Hash 和桶数共同决定。它不等于查询任意字段时都能跳过其他桶，也不会替代分区裁剪。
分桶优化还依赖数据是否真的按声明规则写出、两侧桶字段和桶数是否兼容，以及当前执行引擎是否使用对应优化。
只在建表语句里写了 CLUSTERED BY，不验证物理文件和执行计划，不能证明优化已经生效。
第四步：生产里怎么选择
我一般按下面的顺序判断：
先决定要不要分区
看主要查询是否长期按某些低到中等基数字段过滤，以及单分区数据量是否合理。
再决定要不要分桶
看是否存在稳定的 Join Key、抽样需求或桶内组织收益，并确认写入链路和查询引擎都能遵守桶规则。
最后控制文件数量
分区数乘以桶数，会直接影响文件数量。每天 24 个小时分区，每个分区再写 128 个桶，即使数据量不大，也可能持续制造小文件。
所以分区粒度、桶数、日数据量和写入并行度必须一起评估。
一个典型场景
比如一张用户行为表按 dt 分区、按 user_id 分桶。
查询最近一天的用户行为时，dt 条件负责只读取当天目录；需要按 user_id 与另一张兼容分桶表关联时，分桶才可能帮助减少数据重分布。
如果把两者反过来，按 user_id 分区、按 dt 分桶，就会出现大量用户目录，而常用日期过滤仍然无法高效裁剪。
选字段的依据不是“哪个字段重要”，而是查询怎样过滤、数据怎样关联。