重分区算法对数据进行完全洗牌，并创建大小相等的数据分区。Coalesce结合现有分区以避免完全洗牌。

Coalesce可以很好地使用一个具有大量分区的RDD，并将单个工作节点上的分区组合在一起，以生成一个具有较少分区的最终RDD。

重新分区将重新洗牌RDD中的数据，以产生您请求的最终分区数量。 DataFrames的分区看起来像是一个应该由框架管理的低级实现细节，但事实并非如此。当将大的dataframe过滤成小的dataframe时，你应该总是对数据进行重新分区。 你可能会经常把大的数据帧过滤成小的数据帧，所以要习惯重新分区。

如果你想了解更多细节，请阅读这篇博客文章。

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

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

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

对于那些从PySpark (AWS EMR)生成单个csv文件并将其保存在s3上的问题，使用重新分区会有所帮助。原因是，合并不能进行完全洗牌，但重新分区可以。从本质上讲，您可以使用重分区增加或减少分区的数量，但使用合并只能减少分区的数量(而不是1)。以下是为试图从AWS EMR写入csv到s3的任何人编写的代码:

df.repartition(1).write.format('csv')\
.option("path", "s3a://my.bucket.name/location")\
.save(header = 'true')

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

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

例子:-

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

两者都很好

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

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

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

这里需要注意的一点是，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