- repartition只是coalesce接口中shuffle为true的实现。
- 不经过 shuffle，也就是coaleasce shuffle为false，是无法增加RDD的分区数的，比如你源RDD 100个分区，想要变成200个分区，只能使用repartition，也就是coaleasce shuffle为true。
- 如果上游为Partition个数为N，下游想要变成M个Partition。
- N > M , 比如N=100 M=60, 可以使用coaleasce shuffle为false。
- 但是如果N远大于M，比如N=100, M=1, 分区有一个激烈的变化时，此时如果用coalesce就只有一个task处理数据，资源利用不够，Executor空跑，这时repartition是一个比较好的选择，虽然有shuffle但是和只有1个Task处理任务比起来效率还是较高。
- N < M , coaleasce shuffle为false 不能增加分区，只能用repartition。
一、spark 分区 partition的理解
spark中是以vcore级别调度task
如果读取的是hdfs，那么有多少个block，就有多少个partition
举例来说：sparksql 要读表T, 如果表T有1w个小文件，那么就有1w个partition
这时候读取效率会较低。假设设置资源为 --executor-memory 2g --executor-cores 2 --num-executors 5。
步骤是：
- 拿出1-10号10个小文件（也就是10个partition） 分别给5个executor读取（spark调度会以vcore为单位，实际就是5个executor，10个task读10个partition）
- 如果5个executor执行速度相同，再拿11-20号文件 依次给这5个executor读取
- 而实际执行速度不会完全相同，那就是哪个task先执行完，哪个task领取下一个partition读取执行，以此类推。这样往往读取文件的调度时间大于读取文件本身，而且会频繁打开关闭文件句柄，浪费较为宝贵的io资源，执行效率也大大降低。
二、coalesce 与 repartition的区别（我们下面说的coalesce都默认shuffle参数为false的情况）
repartition(numPartitions:Int):RDDT和coalesce(numPartitions:Int，shuffle:Boolean=false):RDDT
repartition只是coalesce接口中shuffle为true的实现
我们还拿上面的例子说：
有1w的小文件，资源也为--executor-memory 2g --executor-cores 2 --num-executors 5。
- repartition(4)：产生shuffle。这时会启动5个executor像之前介绍的那样依次读取1w个分区的文件，然后按照某个规则%4,写到4个文件中，这样分区的4个文件基本毫无规律，比较均匀。
- coalesce(4)：这个coalesce不会产生shuffle。那启动5个executor在不发生shuffle的时候是如何生成4个文件呢，其实会有1个或2个或3个甚至更多的executor在空跑（具体几个executor空跑与spark调度有关，与数据本地性有关，与spark集群负载有关），他并没有读取任何数据！
PS：
- 如果结果产生的文件数要比源RDD partition少，用coalesce是实现不了的，例如有4个小文件（4个partition），你要生成5个文件用coalesce实现不了，也就是说不产生shuffle，无法实现文件数变多。
- 如果你只有1个executor（1个core），源RDD partition有5个，你要用coalesce产生2个文件。那么他是预分partition到executor上的，例如0-2号分区在先executor上执行完毕，3-4号分区再次在同一个executor执行。其实都是同一个executor但是前后要串行读不同数据。与用repartition(2)在读partition上有较大不同（串行依次读0-4号partition 做%2处理）。
三、实例
T表有10G数据 有100个partition 资源也为--executor-memory 2g --executor-cores 2 --num-executors 5。我们想要结果文件只有一个
- 如果用coalesce：sql(select * from T).coalesce(1)
5个executor 有4个在空跑，只有1个在真正读取数据执行，这时候效率是极低的。所以coalesce要慎用，而且它还用产出oom问题，这个我们以后再说。
- 如果用repartition：sql(select * from T).repartition(1)
这样效率就会高很多，并行5个executor在跑（10个task）,然后shuffle到同一节点，最后写到一个文件中。
那么如果我不想产生一个文件了，我想产生10个文件会怎样，是不是coalesce 又变得比 repartition高效了呢。(因为coalesce无shuffle，相当于每个executor的 task认领 10个 partition)
那么如果我又不想产生10个文件呢？其实一旦要产生的文件数大于executor x vcore数，coalesce效率就更高(一般是这样，不绝对)。
四、总结
我们常认为coalesce不产生shuffle会比repartition 产生shuffle效率高，而实际情况往往要根据具体问题具体分析，coalesce效率不一定高，有时还有大坑，大家要慎用。
coalesce 与 repartition 他们两个都是RDD的分区进行重新划分，repartition只是coalesce接口中shuffle为true的实现（假设源RDD有N个分区，需要重新划分成M个分区）
1）如果N<M。一般情况下N个分区有数据分布不均匀的状况，利用HashPartitioner函数将数据重新分区为M个，这时需要将shuffle设置为true(repartition实现,coalesce也实现不了)。
2）如果N>M并且N和M相差不多，(假如N是1000，M是100)那么就可以将N个分区中的若干个分区合并成一个新的分区，最终合并为M个分区，这时可以将shuff设置为false（coalesce实现），如果M>N时，coalesce是无效的，不进行shuffle过程，父RDD和子RDD之间是窄依赖关系，无法使文件数(partiton)变多。
总之如果shuffle为false时，如果传入的参数大于现有的分区数目，RDD的分区数不变，也就是说不经过shuffle，是无法将RDD的分区数变多的
3）如果N>M并且两者相差悬殊，这时你要看executor数与要生成的partition关系，如果executor数 <= 要生成partition数，coalesce效率高，反之如果用coalesce会导致(executor数-要生成partiton数)个excutor空跑从而降低效率。如果在M为1的时候，为了使coalesce之前的操作有更好的并行度，可以将shuffle设置为true。