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

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

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

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

所以根据这个问题的传统时间轴，这里是我的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)将取决于工作人员的数量和数据量。

希望这能有所帮助。

重新分区-建议在增加分区数量的同时使用它，因为它涉及到所有数据的洗牌。

Coalesce—建议在使用它的同时减少分区的数量。例如，如果你有3个分区，你想把它减少到2个，coalesce将把第3个分区的数据移动到分区1和分区2。分区1和分区2将保留在同一个容器中。 另一方面，重新分区将打乱所有分区中的数据，因此执行程序之间的网络使用将很高，这将影响性能。

在减少分区数量的同时，Coalesce比重分区的性能更好。

这里需要注意的一点是，Spark RDD的基本原则是不变性。重新分区或合并将创建新的RDD。基本RDD将继续存在其原始分区数量。如果用例要求将RDD持久化在缓存中，则必须对新创建的RDD进行同样的操作。

scala> pairMrkt.repartition(10)
res16: org.apache.spark.rdd.RDD[(String, Array[String])] =MapPartitionsRDD[11] at repartition at <console>:26

scala> res16.partitions.length
res17: Int = 10

scala>  pairMrkt.partitions.length
res20: Int = 2

用一种简单的方式 COALESCE:-仅用于减少分区数量，没有数据变换，它只是压缩分区

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

例子:-

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

两者都很好

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

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

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

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