Spark中repartition与coalesce使用场景及分区数确定方法

如何确定需要设置的分区数量 #

你可以结合数据量、集群资源、作业逻辑三个维度判断：

• 按数据量估算：单分区数据量控制在128MB~256MB是通用最优区间，避免分区过小导致大量任务调度开销，也避免分区过大引发节点OOM、数据倾斜问题。
• 按并行度匹配：分区数建议设置为当前作业可使用的Executor总核心数的2~3倍，既保证所有计算核心都能被充分利用，也能预留缓冲应对个别分区执行耗时更长的情况。
• 结合业务逻辑调整：如果后续逻辑存在大量过滤、关联、聚合操作，或者已知存在数据倾斜，可以适当调高分区数打散数据；如果是作业最终写入阶段为了减少小文件数量，可以适当调低分区数。

repartition与coalesce的适用场景选择 #

二者的核心差异是：

repartition一定会触发全量数据Shuffle，将数据按照规则重新打散分配到指定数量的分区；coalesce默认不触发Shuffle，仅通过合并相邻分区的方式调整分区数，不会产生跨节点的数据传输开销。

根据需求直接对应选择即可：

• 优先选择coalesce的场景：
  • 仅需要减少分区数量，且调整幅度不大，比如从1000个分区合并到200个，无Shuffle开销性能远高于repartition
  • 作业执行末尾为了减少输出文件数调整分区的场景，绝大多数情况都可以直接用coalesce
• 必须选择repartition的场景：
  • 需要增加分区数量时，coalesce不支持提升分区数，只能用repartition
  • 需要按指定字段打散数据时，比如按用户ID重分区解决数据倾斜，需要用repartition(200, col("user_id"))这类带分区键的写法
  • 减少分区的幅度特别大时，比如从1000个分区直接降到10个，直接用coalesce会导致少量Executor承担所有计算压力，此时用带Shuffle的repartition可以将数据均匀分配到更多节点执行，整体效率更高

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