调优的思路依赖平时工作中不断总结所形成的丰富经验。而这些是很难直接从知识文档中获取的，应当具体问题具体分析，本文对Spark调优进行归纳总结，缩短了你摸爬滚打的时间。
常规调优
- 并行度调节
理想的并行度设置，应该是让并行度与资源相匹配，一般来说，task数量应该设置为Spark作业总CPU core数量的2-3倍，task总数量尽量使并行执行partition上限的3-5倍，可以避免task数量过少，Executor分配过多CPU core所造成的资源浪费。 - 广播变量
如果多个Executor都要使用同一数据，每一个Executor都要去Driver端多次读取会浪费大量资源，此时首先会在自己本地的Executor对应的BlockManager中尝试获取变量，如果本地没有，BlockManager就会从Driver或者其他节点的BlockManager上远程拉取变量的副本，并由本地的BlockManager进行管理；之后此Executor的所有task都会直接从本地的BlockManager中获取变量。 - Kryo序列化
默认情况下，Spark使用Java的序列化机制。Java的序列化机制使用方便，不需要额外的配置，在算子中使用的变量实现Serializable接口即可，但是，Java序列化机制的效率不高，序列化速度慢并且序列化后的数据所占用的空间依然较大。
Kryo序列化机制比Java序列化机制性能提高10倍左右，Spark之所以没有默认使用Kryo作为序列化类库，是因为它不支持所有对象的序列化，同时Kryo需要用户在使用前注册需要序列化的类型，不够方便，但从Spark 2.0.0版本开始，简单类型、简单类型数组、字符串类型的Shuffling RDDs 已经默认使用Kryo序列化方式了。 - 调节本地等待时长
根据Spark的task分配算法，Spark希望task能够运行在它要计算的数据所在的节点上，但是这些节点可用的资源可能已经用尽，此时Spark会等待一段时间，默认3s，如果等待指定时间后仍然无法在指定节点运行，那么会自动降级，尝试将task分配到比较差的本地化级别所对应的节点上，比如将task分配到离它要计算的数据比较近的一个节点，然后进行计算，如果当前级别仍然不行，那么继续降级。 - RDD持久化缓存
算子调优
- mapPartitions/foreachPartition
mapPartitions和foreachPartition算子针对每个分区只进行一次操作，相比map算子对所有数据都要执行一次操作，效率更高，但是如果数据量比较大的时候，一旦内存不足，容易出现OOM，也就是内存溢出。 - filter与coalesce的配合使用
通常filter之后，每个分区内数据不一致，即数据倾斜，如果还按照之前每个partition分配的task数，就会出现运算速度的差异。
这个时候我们可以对数据进行重新分区，如果是分区合并，最好采用coalesce算子；如果是分区分解，采用repartition算子。 - repartition解决SparkSQL低并行度问题
SparkSQL的并行度不允许用户自己指定，所以前面所说的并行度调节对SparkSQL无效，我们可以使用repertition算子，对SparkSQL查询出来的结果重新分区，stage的并行度就等于你手动重新分区之后的值。 - reduceByKey本地聚合
reduceByKey会进行本地的map聚合，效率比groupByKey高，所有我们可以考虑将
groupByKey替换成reduceByKey。
Shuffle调优
- 调节map端缓冲区大小
map端缓冲的默认配置是32KB，导致溢写次数过多，对性能影响比较大，适当增大map端缓冲区。 - 调节reduce端拉取数据缓冲区的大小
Spark Shuffle过程中，shuffle reduce task的buffer缓冲区大小决定了reduce task每次能够缓冲的数据量，也就是每次能够拉取的数据量，适当增加缓冲区大小，可以减
少拉取数据的次数，也就可以减少网络传输的次数，进而提升性能。 - 增加reduce端拉取数据重试次数
Spark Shuffle过程中，reduce task拉取属于自己的数据时，如果因为网络异常等原因导致失败会自动进行重试。建议增加重试最大次数，可以大幅提升稳定性。 - 调节reduce端拉取数据等待间隔
Spark Shuffle过程中，reduce task拉取属于自己的数据时，如果因为网络异常等原因导致失败会自动进行重试，在一次失败后，会等待一定的时间间隔再进行重试，可以通过加大间隔时长，以增加shuffle操作的稳定性。 - 调节SortShuffle排序操作阈值
对于SortShuffleManager，如果shuffle reduce task的数量小于某一阈值则shuffle write过程中不会进行排序操作，而是直接按照未经优化的HashShuffleManager的方式去写数据，但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件，并会创建单独的索引文件。当你使用SortShuffleManager时，如果的确不需要排序操作，那么建议将这个参数调大一些，大于shuffle read task的数量，那么此时map-side就不会进行排序了，减少了排序的性能开销，但是这种方式下，依然会产生大量的磁盘文件，因此shuffle write性能有待提高。
Spark数据倾斜
- 聚合原始数据
如果Spark作业的数据来源于Hive表，那么可以先在Hive表中对数据进行聚合，比如说将同一key对应的所有value用一种特殊的格式拼接到一个字符串里去，这样，一个key就只有一条数据了；之后，对一个key的所有value进行处理时，只需要进行map操作即可，无需再进行任何的shuffle操作。通过上述方式就避免了执行shuffle操作，也就不可能会发生任何的数据倾斜问题。
还可以通过增大粒度的方式，减少key的数量，key之间的数据量差异也有可
能会减少，由此可以减轻数据倾斜的现象和问题。 - 提高shuffle操作中的reduce并行度
增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据，在一定程度上缓解数据倾斜。 - 使用随机key实现双重聚合
通过map算子给每个数据的key添加随机数前缀，将原先一样的key变成不一样的key，然后进行第一次聚合，这样就可以让原本被一个task处理的数据分散到多个task上去做局部聚合；随后，去除掉每个key的前缀，再次进行聚合。 - 将reducejoin转换为mapjoin
将较小RDD中的数据直接通过collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量；接着对另外一个RDD执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，与当前RDD的每一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式连接起来。
