对于所有这些伟大的答案，我想补充的是，重新分区是利用数据并行化的最佳选择之一。而coalesce提供了一个廉价的选择来减少分区，并且在将数据写入HDFS或其他接收器以利用大写入时非常有用。

我发现这在以拼花格式写数据时很有用，可以充分利用它。

它避免了完全洗牌。如果已知分区数量正在减少，则执行器可以安全地将数据保存在最小分区数量上，只将数据从额外的节点移到我们保留的节点上。

所以，它会是这样的:

Node 1 = 1,2,3
Node 2 = 4,5,6
Node 3 = 7,8,9
Node 4 = 10,11,12

然后合并到2个分区:

Node 1 = 1,2,3 + (10,11,12)
Node 3 = 7,8,9 + (4,5,6)

注意，节点1和节点3不需要移动其原始数据。

有一个重分区>>合并的用例，即使在@Rob的回答中提到的分区号减少，也就是将数据写入单个文件。

@Rob的回答暗示了一个好的方向，但我认为需要一些进一步的解释来理解引擎盖下面发生了什么。

如果您需要在写入数据之前过滤数据，那么重新分区比coalesce更适合，因为coalesce将在加载操作之前下推。

例如: load () . map(…).filter(…).coalesce (1) .save ()

翻译: load () .coalesce (1) . map(…).filter(…).save ()

这意味着您的所有数据将被压缩到一个单独的分区中，在那里它将被过滤，失去所有的并行性。 这种情况甚至会发生在非常简单的过滤器，如column='value'。

load().map(…).filter(…).repartition(1).save()

在这种情况下，在原始分区上并行地进行过滤。

举个数量级的例子，在我的例子中，当从Hive表加载后过滤109M行(~105G)和~1000个分区时，运行时从合并(1)的~6h下降到重新分区(1)的~2m。

具体示例取自AirBnB的这篇文章，这篇文章非常好，甚至涵盖了Spark中重新分区技术的更多方面。

但是你也应该确保，如果你在处理巨大的数据，将要合并的节点的数据应该是高度配置的。因为所有的数据都会加载到那些节点上，可能会导致内存异常。 虽然赔款很贵，但我还是愿意用它。因为它对数据进行了洗牌和平均分配。

在合并和重新分区之间进行明智的选择。

联合——可以增加或减少分区 重新分区——只会增加分区

但是我想说性能纯粹是基于用例的。联合并不总是比重新划分好。

Coalesce使用现有分区来最小化数据量 被打乱。重新分区将创建新的分区并执行满分区 洗牌。 合并会产生具有不同数据量的分区 (有时分区有许多不同的大小)和 重新分区会产生大小大致相同的分区。 合并可以减少分区，但修复可以用来增加或减少分区。