【Spark调优】：结合业务场景，优选高性能算子
-
聚合操作使用reduceByKey/aggregateByKey替代groupByKey
参见我的这篇博客说明 【Spark调优】：如果实在要shuffle，使用map侧预聚合的算子
-
内存充足前提下使用mapPartitions替代普通map
mapPartitions类的算子，一次函数调用会处理一个partition所有的数据，而不是一次函数调用处理一条，性能相对来说会高一些。但是有的时候，使用mapPartitions会出现OOM（内存溢出）问题。因为单次函数调用就要处理掉一个partition所有的数据，如果内存不够，垃圾回收时是无法回收掉太多对象的，很可能出现OOM异常。所以使用这类操作时要提前做好计算。
-
内存充足前提下使用foreachPartitions替代foreach
原理类似于上述“使用mapPartitions替代map”，也是一次函数调用处理一个partition的所有数据，而不是一次函数调用处理一条数据，对性能的提升很有帮助。比如在foreach函数中，将RDD中所有数据写MySQL，那么如果是普通的foreach算子，就会一条数据一条数据地写，每次函数调用可能就会创建一个数据库连接，此时就势必会频繁地创建和销毁数据库连接，性能是非常低下；但是如果用foreachPartitions算子一次性处理一个partition的数据，那么对于每个partition，只要创建一个数据库连接即可，然后执行批量插入操作，此时性能是比较高的。
-
filter之后考虑接coalesce操作
通常对一个RDD执行filter算子过滤掉RDD中较多数据后（例如30%以上数据），考虑使用coalesce算子，手动减少RDD的partition数量，将RDD中的数据压缩到更少的partition中去，从而也同步降低了处理的task数量。因为filter之后，RDD的每个partition中都会有很多数据被过滤掉，此时如果照常进行后续的计算，其实每个task处理的partition中的数据量并不是很多，有一点资源浪费，而且此时处理的task越多，可能速度反而越慢。因此用coalesce减少partition数量，将RDD中的数据压缩到更少的partition之后，只要使用更少的task即可处理完所有的partition。在某些场景下，对于性能的提升会有一定的帮助。
-
重分区+排序使用repartitionAndSortWithinPartitions替代repartition+sort操作
repartitionAndSortWithinPartitions是Spark官网推荐的一个算子，官方建议：如果需要在repartition重分区之后，还要进行排序，建议直接使用repartitionAndSortWithinPartitions算子。因为该算子可以一边进行重分区的shuffle操作，一边进行排序。shuffle与sort两个操作同时进行，一般比先shuffle再sort性能高。
