Hive按指定字段执行Distribute By为何会导致存储占用大幅上升？

ORC作为列式存储格式，压缩效率高度依赖单文件内同列值的聚集度，Hive的distribute by会控制数据到Reducer的分发规则，直接决定了每个输出ORC文件内的数据分布特征，因此会显著影响最终存储体积。

不同分发规则的体积差异原因 #

• 无分发规则（14.5GB基线）：数据按上游Map输出的随机顺序写文件，各字段的聚集度处于中等水平，压缩效率为常规基线值。
• 按cuid分发（11.7GB，体积最小）：你的表中有14个设备与应用环境字段，这类字段的取值和cuid（设备唯一标识）完全绑定，同一个cuid对应的设备型号、系统版本、App版本等字段值固定。按cuid分发后，相同cuid的行全部落到同一个ORC文件中，14个环境字段的重复率极高，ORC的字典编码、RLE编码效率拉满，因此压缩比最高，体积最小。
• 按point_name分发（28.6GB，体积翻倍）：point_name是埋点名称，同一个埋点对应的访问用户、设备是完全随机的。按point_name分发后，同一个ORC文件内全是同一埋点的访问数据，设备环境字段的取值完全打散，重复率骤降，压缩效率大幅降低，因此体积直接翻倍。
• 按point_name+cuid组合分发（29.6GB，体积最大）：组合分发键的基数是「埋点数量 × 设备数量」，远高于单个字段的基数，会导致单个Reducer分到的数据量大幅降低，甚至产生大量小ORC文件：ORC的文件元数据（footer、索引等）的占比大幅提升，再加上环境字段重复率低的问题，最终体积比单独按point_name分发更高。

兼顾查询效率与存储成本的方案 #

如果需要保留BI/BA按point_name查询的便利性，同时控制存储成本，可以调整写入逻辑：

1. 采用两级分发排序：distribute by point_name, cuid sort by point_name, cuid，既保证同一point_name的数据相对集中，也能让同cuid的行聚集，兼顾压缩效率
2. 也可以设置表按point_name分区，分区内按cuid分发排序，查询时可以直接命中对应埋点的分区，不需要扫全表，同时分区内的压缩效率也能保持较高水平。

内容的提问来源于stack exchange，提问作者ro51n