一、代码调优
1、避免创建重复的RDD：对于同一份数据，只应该创建一个RDD，不能创建多个RDD来代表同一份数据。
一些Spark初学者在刚开始开发Spark作业时，或者是有经验的工程师在开发RDD lineage极其冗长的Spark作业时，可能会忘了自己之前对于某一份数据已经创建过一个RDD了，从而导致对于同一份数据，创建了多个RDD。这就意味着，我们的Spark作业会进行多次重复计算来创建多个代表相同数据的RDD，进而增加了作业的性能开销。
// 需要对名为“hello.txt”的HDFS文件进行一次map操作，再进行一次reduce操作。也就是说，需要对一份数据执行两次算子操作。
// 错误的做法：对于同一份数据执行多次算子操作时，创建多个RDD。
// 这里执行了两次textFile方法，针对同一个HDFS文件，创建了两个RDD出来，然后分别对每个RDD都执行了一个算子操作。
// 这种情况下，Spark需要从HDFS上两次加载hello.txt文件的内容，并创建两个单独的RDD；第二次加载HDFS文件以及创建RDD的性能开销，很明显是白白浪费掉的。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd1.map(...)
val rdd2 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd2.reduce(...)
// 正确的用法：对于一份数据执行多次算子操作时，只使用一个RDD。
// 这种写法很明显比上一种写法要好多了，因为我们对于同一份数据只创建了一个RDD，然后对这一个RDD执行了多次算子操作。
// 但是要注意到这里为止优化还没有结束，由于rdd1被执行了两次算子操作，第二次执行reduce操作的时候，还会再次从源头处重新计算一次rdd1的数据，因此还是会有重复计算的性能开销。
// 要彻底解决这个问题，必须结合“原则三：对多次使用的RDD进行持久化”，才能保证一个RDD被多次使用时只被计算一次。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt")
rdd1.map(...)
rdd1.reduce(...)
2、尽可能复用同一个RDD：对不同的数据执行算子操作时还要尽可能地复用一个RDD。比如说，有一个RDD的数据格式是key-value类型的，另一个是单value类型的，这两个RDD的value数据是完全一样的。那么此时我们可以只使用key-value类型的那个RDD，因为其中已经包含了另一个的数据。对于类似这种多个RDD的数据有重叠或者包含的情况，我们应该尽量复用一个RDD，这样可以尽可能地减少RDD的数量，从而尽可能减少算子执行的次数。
// 错误的做法。
// 有一个<Long, String>格式的RDD，即rdd1。
// 接着由于业务需要，对rdd1执行了一个map操作，创建了一个rdd2，而rdd2中的数据仅仅是rdd1中的value值而已，也就是说，rdd2是rdd1的子集。
JavaPairRDD<Long, String> rdd1 = ...
JavaRDD<String> rdd2 = rdd1.map(...)
// 分别对rdd1和rdd2执行了不同的算子操作。
rdd1.reduceByKey(...)
rdd2.map(...)
// 正确的做法。
// 上面这个case中，其实rdd1和rdd2的区别无非就是数据格式不同而已，rdd2的数据完全就是rdd1的子集而已，却创建了两个rdd，并对两个rdd都执行了一次算子操作。
// 此时会因为对rdd1执行map算子来创建rdd2，而多执行一次算子操作，进而增加性能开销。
// 其实在这种情况下完全可以复用同一个RDD。
// 我们可以使用rdd1，既做reduceByKey操作，也做map操作。
// 在进行第二个map操作时，只使用每个数据的tuple._2，也就是rdd1中的value值，即可。
JavaPairRDD<Long, String> rdd1 = ...
rdd1.reduceByKey(...)
rdd1.map(tuple._2...)
// 第二种方式相较于第一种方式而言，很明显减少了一次rdd2的计算开销。
// 但是到这里为止，优化还没有结束，对rdd1我们还是执行了两次算子操作，rdd1实际上还是会被计算两次。
// 因此还需要配合“原则三：对多次使用的RDD进行持久化”进行使用，才能保证一个RDD被多次使用时只被计算一次。
3、对多次使用的RDD进行持久化：
尽可能复用RDD的基础上，需要进行第二步优化，也就是要保证对一个RDD执行多次算子操作时，这个RDD本身仅仅被计算一次。
Spark中对于一个RDD执行多次算子的默认原理是这样的：每次对一个RDD执行一个算子操作时，都会重新从源头处计算一遍，计算出那个RDD来，然后再对这个RDD执行你的算子操作。这种方式的性能是很差的。
因此对于这种情况，我们的建议是：对多次使用的RDD进行持久化。此时Spark就会根据持久化策略，将RDD中的数据保存到内存或者磁盘中。以后每次对这个RDD进行算子操作时，都会直接从内存或磁盘中提取持久化的RDD数据，然后执行算子，而不会从源头处重新计算一遍这个RDD，再执行算子操作。
持久化操作有：cache()、persist()、checkpoint()
// 如果要对一个RDD进行持久化，只要对这个RDD调用cache()和persist()即可。
// 正确的做法。
// cache()方法表示：使用非序列化的方式将RDD中的数据全部尝试持久化到内存中。
// 此时再对rdd1执行两次算子操作时，只有在第一次执行map算子时，才会将这个rdd1从源头处计算一次。
// 第二次执行reduce算子时，就会直接从内存中提取数据进行计算，不会重复计算一个rdd。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt").cache()
rdd1.map(...)
rdd1.reduce(...)
// persist()方法表示：手动选择持久化级别，并使用指定的方式进行持久化。
// 比如说，StorageLevel.MEMORY_AND_DISK_SER表示，内存充足时优先持久化到内存中，内存不充足时持久化到磁盘文件中。
// 而且其中的_SER后缀表示，使用序列化的方式来保存RDD数据，此时RDD中的每个partition都会序列化成一个大的字节数组，然后再持久化到内存或磁盘中。
// 序列化的方式可以减少持久化的数据对内存/磁盘的占用量，进而避免内存被持久化数据占用过多，从而发生频繁GC。
val rdd1 = sc.textFile("hdfs://192.168.0.1:9000/hello.txt").persist(StorageLevel.MEMORY_AND_DISK_SER)
rdd1.map(...)
rdd1.reduce(...)
4、尽量避免使用shuffle类的算子：要尽量避免使用shuffle类算子。因为Spark作业运行过程中，最消耗性能的地方就是shuffle过程。shuffle过程，简单来说，就是将分布在集群中多个节点上的同一个key，拉取到同一个节点上，进行聚合或join等操作。比如reduceByKey、join等算子，都会触发shuffle操作。
shuffle过程中，各个节点上的相同key都会先写入本地磁盘文件中，然后其他节点需要通过网络传输拉取各个节点上的磁盘文件中的相同key。而且相同key都拉取到同一个节点进行聚合操作时，还有可能会因为一个节点上处理的key过多，导致内存不够存放，进而溢写到磁盘文件中。因此在shuffle过程中，可能会发生大量的磁盘文件读写的IO操作，以及数据的网络传输操作。磁盘IO和网络数据传输也是shuffle性能较差的主要原因。
因此在我们的开发过程中，能避免则尽可能避免使用reduceByKey、join、distinct、repartition等会进行shuffle的算子，尽量使用map类的非shuffle算子。这样的话，没有shuffle操作或者仅有较少shuffle操作的Spark作业，可以大大减少性能开销。
典型的解决：广播变量+map类的transformation类算子代替join
// 传统的join操作会导致shuffle操作。
// 因为两个RDD中，相同的key都需要通过网络拉取到一个节点上，由一个task进行join操作。
val rdd3 = rdd1.join(rdd2)
// Broadcast+map的join操作，不会导致shuffle操作。
// 使用Broadcast将一个数据量较小的RDD作为广播变量。
val rdd2Data = rdd2.collect()
val rdd2DataBroadcast = sc.broadcast(rdd2Data)
// 在rdd1.map算子中，可以从rdd2DataBroadcast中，获取rdd2的所有数据。
// 然后进行遍历，如果发现rdd2中某条数据的key与rdd1的当前数据的key是相同的，那么就判定可以进行join。
// 此时就可以根据自己需要的方式，将rdd1当前数据与rdd2中可以连接的数据，拼接在一起（String或Tuple）。
val rdd3 = rdd1.map(rdd2DataBroadcast...)
// 注意，以上操作，建议仅仅在rdd2的数据量比较少（比如几百M，或者一两G）的情况下使用。
// 因为每个Executor的内存中，都会驻留一份rdd2的全量数据。
5、使用map-side预聚合的shuffle操作：尽量使用map端有预聚合的算子
如果因为业务需要，一定要使用shuffle操作，无法用map类的算子来替代，那么尽量使用可以map-side预聚合的算子。
所谓的map-side预聚合，就是在每个节点本地对相同的key进行一次聚合操作，类似于MapReduce中的本地combiner。map-side预聚合之后，每个节点本地就只会有一条相同的key，因为多条相同的key都被聚合起来了。其他节点在拉取所有节点上的相同key时，就会大大减少需要拉取的数据数量，从而也就减少了磁盘IO以及网络传输开销。
通常来说，在可能的情况下，建议使用reduceByKey或者aggregateByKey算子来替代掉groupByKey算子。因为reduceByKey和aggregateByKey算子都会使用用户自定义的函数对每个节点本地的相同key进行预聚合。而groupByKey算子是不会进行预聚合的，全量的数据会在集群的各个节点之间分发和传输，性能相对来说比较差。
常见的带有map端预聚合的算子有：reduceByKey，combineByKey，aggregateByKey
比如如下两幅图，就是典型的例子，分别基于reduceByKey和groupByKey进行单词计数。其中第一张图是groupByKey的原理图，可以看到，没有进行任何本地聚合时，所有数据都会在集群节点之间传输；第二张图是reduceByKey的原理图，可以看到，每个节点本地的相同key数据，都进行了预聚合，然后才传输到其他节点上进行全局聚合。
6 使用高性能的算子：
（1）reduceByKey 代替 groupByKey：前者有map端预聚合，减少shuffle网络传输。
（2）mapPartitions 代替 map：
mapPartitions类的算子，一次函数调用会处理一个partition所有的数据，而不是一次函数调用处理一条，性能相对来说会高一些。但是有的时候，使用mapPartitions会出现OOM（内存溢出）的问题。因为单次函数调用就要处理掉一个partition所有的数据，如果内存不够，垃圾回收时是无法回收掉太多对象的，很可能出现OOM异常。所以使用这类操作时要慎重！
如果是普通的 map，比如一个 partition 中有 1 万条数据；ok，那么你的 function 要执行 和计算 1 万次。但是，使用 MapPartitions 操作之后，一个 task 仅仅会执行一次 function，function 一次接收所有的 partition 数据。只要执行一次就可以了，性能比较高。
MapPartitions 操作的缺点：
如果是普通的 map 操作，一次 function 的执行就处理一条数据；那么如果内存不够用 的情况下，比如处理了 1 千条数据了，那么这个时候内存不够了，那么就可以将已经处理完 的 1 千条数据从内存里面垃圾回收掉，或者用其他方法，腾出空间来吧。 但是 MapPartitions 操作，对于大量数据来说，比如甚至一个 partition，100 万数据，一 次传入一个 function 以后，那么可能一下子内存不够，但是又没有办法去腾出内存空间来， 可能就 OOM，内存溢出。
注意： 在项目中，自己先去估算一下 RDD 的数据量，以及每个 partition 的量，还有自己分配 给每个 executor 的内存资源。看看一下子内存容纳所有的 partition 数据，行不行。如果行， 可以试一下，能跑通就好。性能肯定是有提升的。 但是试了一下以后，发现，不行，OOM 了，那就放弃吧
（3）foreachPartition 代替 foreach：
原理类似于“使用mapPartitions替代map”，也是一次函数调用处理一个partition的所有数据，而不是一次函数调用处理一条数据。在实践中发现，foreachPartitions类的算子，对性能的提升还是很有帮助的。比如在foreach函数中，将RDD中所有数据写MySQL，那么如果是普通的foreach算子，就会一条数据一条数据地写，每次函数调用可能就会创建一个数据库连接，此时就势必会频繁地创建和销毁数据库连接，性能是非常低下；但是如果用foreachPartitions算子一次性处理一个partition的数据，那么对于每个partition，只要创建一个数据库连接即可，然后执行批量插入操作，此时性能是比较高的。实践中发现，对于1万条左右的数据量写MySQL，性能可以提升30%以上。
在实际生产环境中，清一色，都是使用 foreachPartition 操作；但是有个问题，跟 mapPartitions 操作一样，如果一个 partition 的数量真的特别特别大，比如真的是 100 万，那基本上就不太 靠谱了。（一下子进来，很有可能会发生 OOM，内存溢出的问题）
此外，foreachPartition也可以解决程序中的序列化问题，若在调用某个类的方法的时候，这个类没有实现序列化接口，或者这个类里面依赖的类没法实现序列化接口。就可以将new操作放在foreachpartion里面，将对象的创建过程推迟到excutor内，而不是driver端。若在driver端创建对象，就需要将对象传输到excutor里，所以需要序列化。
// 每个小时的数据分布情况统计
baseData.map(t => ("B-" + t._2, t._3)).reduceByKey((list1, list2) => {
//根据小时进行聚合
(list1 zip list2) map (x => x._1 + x._2)
}).foreachPartition(itr => {
val client = JedisUtils.getJedisClient()
itr.foreach(tp => {
// B-2017111816
client.hincrBy(tp._1, "total", tp._2(0).toLong)//计算充值总量
client.hincrBy(tp._1, "succ", tp._2(1).toLong)//计算充值成功量
client.expire(tp._1, 60 * 60 * 24 * 2)
})
client.close()
})
（4）filter 对大量数据过滤之后使用 coalesce 减少分区
通常对一个RDD执行filter算子过滤掉RDD中较多数据后（比如30%以上的数据），建议使用coalesce算子，手动减少RDD的partition数量，将RDD中的数据压缩到更少的partition中去。因为filter之后，RDD的每个partition中都会有很多数据被过滤掉，此时如果照常进行后续的计算，其实每个task处理的partition中的数据量并不是很多，有一点资源浪费，而且此时处理的task越多，可能速度反而越慢。因此用coalesce减少partition数量，将RDD中的数据压缩到更少的partition之后，只要使用更少的task即可处理完所有的partition。在某些场景下，对于性能的提升会有一定的帮助。
默认情况下，经过了这种 filter 之后，RDD 中的每个 partition 的数据量，可能都不太一样了。 （原本每个 partition 的数据量可能是差不多的）
问题：
1、每个 partition 数据量变少了，但是在后面进行处理的时候，还是要跟 partition 数量一样 数量的 task，来进行处理；有点浪费 task 计算资源。
2、每个 partition 的数据量不一样，会导致后面的每个 task 处理每个 partition 的时候，每个 task 要处理的数据量就不同，这个时候很容易发生数据倾斜。。。。
比如说，第二个 partition 的数据量才 100；但是第三个 partition 的数据量是 900；那么在后 面的 task 处理逻辑一样的情况下，不同的 task 要处理的数据量可能差别达到了 9 倍，甚至 10 倍以上；同样也就导致了速度的差别在 9 倍，甚至 10 倍以上。
解决：
1、针对第一个问题，我们希望可以进行 partition 的压缩吧，因为数据量变少了，那么 partition 其实也完全可以对应的变少。比如原来是 4 个 partition，现在完全可以变成 2 个 partition。 那么就只要用后面的 2 个 task 来处理即可。就不会造成 task 计算资源的浪费。
2、针对第二个问题，其实解决方案跟第一个问题是一样的；也是去压缩 partition，尽量让 每个 partition 的数据量差不多。那么这样的话，后面的 task 分配到的 partition 的数据量也就 差不多。不会造成有的 task 运行速度特别慢，有的 task 运行速度特别快。避免了数据倾斜 的问题。
coalesce 算子 主要就是用于在 filter 操作之后，针对每个 partition 的数据量各不相同的情况，来压缩 partition 的数量。减少 partition 的数量，而且让每个 partition 的数据量都尽量均匀紧凑。
（5）repartitionAndSortWithinPartitions 替代 repartition 与 sort 类操作
repartitionAndSortWithinPartitions 是Spark 官网推荐的一个算子，官方建议，如果需要在 repartition 重分区之后，还要进行排序，建议直接使用 repartitionAndSortWithinPartitions 算子。因为该算子可以一边进行重分区的 shuffle 操作，一边进行排序。shuffle与sort两个操作同时进行，比先shuffle再sort来说，性能可能是要高的。
7、广播大变量
有时在开发过程中，会遇到需要在算子函数中使用外部变量的场景（尤其是大变量，比如100M以上的大集合），那么此时就应该使用Spark的广播（Broadcast）功能来提升性能。
在算子函数中使用到外部变量时，默认情况下，Spark会将该变量复制多个副本，通过网络传输到task中，此时每个task都有一个变量副本。如果变量本身比较大的话（比如100M，甚至1G），那么大量的变量副本在网络中传输的性能开销，以及在各个节点的Executor中占用过多内存导致的频繁GC，都会极大地影响性能。
因此对于上述情况，如果使用的外部变量比较大，建议使用Spark的广播功能，对该变量进行广播。广播后的变量，会保证每个Executor的内存中，只驻留一份变量副本，而Executor中的task执行时共享该Executor中的那份变量副本。这样的话，可以大大减少变量副本的数量，从而减少网络传输的性能开销，并减少对Executor内存的占用开销，降低GC的频率。
// 以下代码在算子函数中，使用了外部的变量。
// 此时没有做任何特殊操作，每个task都会有一份list1的副本。
val list1 = ...
rdd1.map(list1...)
// 以下代码将list1封装成了Broadcast类型的广播变量。
// 在算子函数中，使用广播变量时，首先会判断当前task所在Executor内存中，是否有变量副本。
// 如果有则直接使用；如果没有则从Driver或者其他Executor节点上远程拉取一份放到本地Executor内存中。
// 每个Executor内存中，就只会驻留一份广播变量副本。
val list1 = ...
val list1Broadcast = sc.broadcast(list1)
rdd1.map(list1Broadcast...)
8、使用Kryo优化序列化性能
在Spark中，主要有三个地方涉及到了序列化：
- 在算子函数中使用到外部变量时，该变量会被序列化后进行网络传输（见“原则七：广播大变量”中的讲解）。
- 将自定义的类型作为RDD的泛型类型时（比如JavaRDD，Student是自定义类型），所有自定义类型对象，都会进行序列化。因此这种情况下，也要求自定义的类必须实现Serializable接口。
- 使用可序列化的持久化策略时（比如MEMORY_ONLY_SER），Spark会将RDD中的每个partition都序列化成一个大的字节数组。
对于这三种出现序列化的地方，我们都可以通过使用Kryo序列化类库，来优化序列化和反序列化的性能。Spark默认使用的是Java的序列化机制，也就是ObjectOutputStream/ObjectInputStream API来进行序列化和反序列化。但是Spark同时支持使用Kryo序列化库，Kryo序列化类库的性能比Java序列化类库的性能要高很多。官方介绍，Kryo序列化机制比Java序列化机制，性能高10倍左右。Spark之所以默认没有使用Kryo作为序列化类库，是因为Kryo要求最好要注册所有需要进行序列化的自定义类型，因此对于开发者来说，这种方式比较麻烦。
以下是使用Kryo的代码示例，我们只要设置序列化类，再注册要序列化的自定义类型即可（比如算子函数中使用到的外部变量类型、作为RDD泛型类型的自定义类型等）：
// 创建SparkConf对象。
val conf = new SparkConf().setMaster(...).setAppName(...)
// 设置序列化器为KryoSerializer。
conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
// 注册要序列化的自定义类型。
conf.registerKryoClasses(Array(classOf[MyClass1], classOf[MyClass2]))
9、优化数据结构
Java中，有三种类型比较耗费内存：
- 对象，每个Java对象都有对象头、引用等额外的信息，因此比较占用内存空间。
- 字符串，每个字符串内部都有一个字符数组以及长度等额外信息。
- 集合类型，比如HashMap、LinkedList等，因为集合类型内部通常会使用一些内部类来封装集合元素，比如Map.Entry。
因此Spark官方建议，在Spark编码实现中，特别是对于算子函数中的代码，尽量不要使用上述三种数据结构，尽量使用字符串替代对象，使用原始类型（比如Int、Long）替代字符串，使用数组替代集合类型，这样尽可能地减少内存占用，从而降低GC频率，提升性能。
但是在笔者的编码实践中发现，要做到该原则其实并不容易。因为我们同时要考虑到代码的可维护性，如果一个代码中，完全没有任何对象抽象，全部是字符串拼接的方式，那么对于后续的代码维护和修改，无疑是一场巨大的灾难。同理，如果所有操作都基于数组实现，而不使用HashMap、LinkedList等集合类型，那么对于我们的编码难度以及代码可维护性，也是一个极大的挑战。因此笔者建议，在可能以及合适的情况下，使用占用内存较少的数据结构，但是前提是要保证代码的可维护性。
10、使用高性能的库 fastutil：
fastutil 是扩展了 Java 标准集合框架（Map、List、Set；HashMap、ArrayList、HashSet）的类库，提供了特殊类型的 map、set、list 和 queue；
fastutil 能够提供更小的内存占用，更快的存取速度；我们使用 fastutil 提供的集合类，来替代自己平时使用的 JDK 的原生的 Map、List、Set，好处在于，fastutil集合类，可以减小内存的占用，并且在进行集合的遍历、根据索引（或者 key）获取元素的值和设置元素的值的时候，提供更快的存取速度；
fastutil 也提供了 64 位的 array、set 和 list，以及高性能快速的，以及实用的 IO类，来处理二进制和文本类型的文件；
fastutil 的每一种集合类型，都实现了对应的 Java 中的标准接口（比如 fastutil 的map，实现了 Java 的 Map 接口），因此可以直接放入已有系统的任何代码中。
fastutil 还提供了一些 JDK 标准类库中没有的额外功能（比如双向迭代器）。
fastutil 除了对象和原始类型为元素的集合，fastutil 也提供引用类型的支持，但是对引用类型是使用等于号（=）进行比较的，而不是 equals()方法。
fastutil 尽量提供了在任何场景下都是速度最快的集合类库。
Spark 中应用 fastutil 的场景：
1 、如果算子函数使用了外部变量；那么第一，你可以使用 Broadcast 广播变量优化；第二，可以使用 Kryo 序列化类库，提升序列化性能和效率；第三，如果外部变量是某种比较大的集合，那么可以考虑使用 fastutil 改写外部变量，首先从源头上就减少内存的占用，通过广播变量进一步减少内存占用，再通过 Kryo 序列化类库进一步减少内存占用。
2 、在你的算子函数里，也就是 task 要执行的计算逻辑里面，如果有逻辑中出现要创建比较大的 Map、List 等集合，可能会占用较大的内存空间，而且可能涉及到消耗性能的遍历、存取等集合操作；那么此时，可以考虑将这些集合类型使用 fastutil 类库重写，使用了 fastutil 集合类以后，就可以在一定程度上，减少task 创建出来的集合类型的内存占用。避免 executor 内存频繁占满，频繁唤起GC，导致性能下降。
fastutil 的使用：
第一步：在 pom.xml 中引用 fastutil 的包
<dependency> <groupId>fastutil</groupId> <artifactId>fastutil</artifactId> <version>5.0.9</version> </dependency>
List<Integer> => IntList