coalesce分区数过小导致 Lost executor

coalesce分区数过小导致 Lost executor

由于之前一套spark代码没有合并小文件，被运维警告说小文件数超过了二十万，遂在落表时重分区，因为实际落表数据最大的只有几十MB，全都改成coalesce(1)，最近由于业务发展，数据量翻倍，有一个逻辑一直执行不过，报如下错误

ERROR YarnScheduler: Lost executor

Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: ResultStage 15 (sql at DataExtractV3.scala:552) has failed the maximum allowable number of times: 4

由于报错太不明显，无法定位，尝试性增大了coalesce分区数，可以正常运行了。

具体原因是由于coalesce(1)只有1个executor在真正读取数据执行，这时候效率是极低的，导致oom，所以coalesce要慎用。

总结

       我们常认为coalesce不产生shuffle会比repartition 产生shuffle效率高，而实际情况往往要根据具体问题具体分析，coalesce效率不一定高，有时还有大坑，大家要慎用。 coalesce 与 repartition 他们两个都是RDD的分区进行重新划分，repartition只是coalesce接口中shuffle为true的实现（假设源RDD有N个分区，需要重新划分成M个分区）

       1）如果N

       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。