另一个不同之处是考虑到存在倾斜连接的情况，您必须在其之上进行合并。在大多数情况下，重新分区将解决倾斜连接，然后您可以进行合并。

另一种情况是，假设你在一个数据帧中保存了一个中等/大量的数据，你必须批量生成到Kafka。在某些情况下，在生成到Kafka之前，重新分区有助于collectasList。但是，当容量非常大时，重新分区可能会导致严重的性能影响。在这种情况下，直接从dataframe生成Kafka会有所帮助。

附注:Coalesce并不像在工作人员之间进行完整的数据移动那样避免数据移动。但它确实减少了洗牌的次数。我想这就是那本书的意思。

有一个重分区>>合并的用例，即使在@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:-仅用于减少分区数量，没有数据变换，它只是压缩分区

REPARTITION:-用于增加和减少分区的数量，但会发生洗牌

例子:-

val rdd = sc.textFile("path",7)
rdd.repartition(10)
rdd.repartition(2)

两者都很好

但是当我们需要在一个集群中看到输出时，我们通常会选择这两个。

所有的答案都为这个经常被问到的问题增添了一些伟大的知识。

所以根据这个问题的传统时间轴，这里是我的2美分。

我发现在非常具体的情况下，重新分区比合并更快。

在我的应用程序中，当我们估计的文件数量低于某个阈值时，重新分区工作得更快。

这就是我的意思

if(numFiles > 20)
    df.coalesce(numFiles).write.mode(SaveMode.Overwrite).parquet(dest)
else
    df.repartition(numFiles).write.mode(SaveMode.Overwrite).parquet(dest)

在上面的代码片段中，如果我的文件小于20，合并将永远无法完成，而重新分区要快得多，因此上面的代码。

当然，这个数字(20)将取决于工作人员的数量和数据量。

希望这能有所帮助。

基本上，重分区允许您增加或减少分区的数量。重分区重新分配来自所有分区的数据，这导致完全shuffle，这是非常昂贵的操作。

Coalesce是重新分区的优化版本，您只能减少分区的数量。由于我们只能减少分区的数量，它所做的是将一些分区合并为一个分区。通过合并分区，与重新分区相比，跨分区的数据移动更低。所以在Coalesce中是最小的数据移动，但说Coalesce不做数据移动是完全错误的说法。

另一件事是通过提供分区的数量来重新分区，它试图在所有分区上均匀地重新分配数据而在Coalesce的情况下，在某些情况下我们仍然可能有倾斜的数据。

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

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