Spark：如何选择合适的分区数？Reduce分区相关疑问

一、典型的Reduce分区大小 #

生产环境中，Reduce分区的常规理想范围是128MB到256MB，这也是Spark默认配置（spark.sql.files.maxPartitionBytes默认128MB）对齐的标准。

• 如果你的shuffle管理器对大分区表现优异，可以测试256MB甚至512MB的分区，但要警惕：过大的分区会让单个Executor承担更高的内存压力，容易引发OOM（内存溢出），尤其是处理密集型数据（如含大字段的结构化数据、二进制数据）时风险更高。
• 针对不同数据类型可灵活调整：纯文本、稀疏数据这类内存占用较低的类型，分区上限可放宽到256MB；而密集型数据建议保持在128MB以内。

二、选择合适分区数的经验法则 #

1. 基于集群CPU核心数匹配 #

通常设置分区数为集群总CPU核心数的2_{3倍。比如集群有80个可用核心，分区数设为160}240，既能充分利用CPU资源，避免核心闲置，也不会因任务过多导致调度开销飙升。

2. 基于数据总量反推 #

用总数据量除以理想分区大小（128MB/256MB）得到基准分区数，再结合核心数调整：

• 如果基准数远小于核心数的2倍，适当往上调分区数，保证每个核心都有任务可处理；
• 如果基准数远大于核心数的3倍，可适当合并分区，避免任务调度的额外开销抵消并行计算的优势。

3. 结合GroupByTest的参数调试 #

你用GroupByTest做基准测试时，可以按以下逻辑倒推参数：
比如要测试256MB的Reduce分区，假设每个KV对的valSize是100字节，那么每个Mapper的numKVPairs可设为 256*1024*1024/100 ≈ 2684万；再根据集群核心数设置numMappers（建议等于核心数），最后用总数据量/256MB得出reducer数量，确保每个Reducer处理的分区大小符合测试预期。

4. 关注shuffle内存限制 #

分区数过多会导致shuffle内存被分散到大量任务中，可能引发每个任务的内存不足；分区数太少则会让单个任务处理的数据量过大，触发频繁GC甚至OOM。需要结合spark.shuffle.memoryFraction等配置平衡两者。

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