spark - Performance Optimization Guide (Basic)

Refer to Meituan's technical blog https://tech.meituan.com/spark-tuning-basic.html to sort out spark optimization knowledge points.

 

1. Create as few RDDs as possible

• Avoid creating duplicate RDDs (eg: a file is read multiple times, corresponding to multiple RDDs)
• Reuse RDD as much as possible (for example: rdd1 completely contains the information of rdd2, just use rdd1 directly, no need to create rdd2)
• Persist RDDs that are used multiple times (for example, call rdd.map first, and then call rdd.reduce for the second time. Every time you perform an operator operation on an RDD, it will be recalculated from the source and calculated again. out that RDD, and then perform your operator operations on this RDD. The performance of this method is very poor. )

 

Spark's persistence level: 

 

Persistence strategy selection:

• By default, the highest performance is of course MEMORY_ONLY, but the premise is that your memory must be large enough to store all the data of the entire RDD. Because the serialization and deserialization operations are not performed, the performance overhead of this part is avoided; the subsequent operator operations on this RDD are all operations based on data in pure memory, and there is no need to read data from disk files. The performance is also high; and there is no need to make a copy of the data and transmit it remotely to other nodes. However, it must be noted here that in the actual production environment, there are probably limited scenarios where this strategy can be used directly. If there is a large amount of data in the RDD (such as billions), using this persistence level directly will result in Causes the JVM's OOM out of memory exception.

• If memory overflow occurs when using the MEMORY_ONLY level, then it is recommended to try the MEMORY_ONLY_SER level. This level will serialize the RDD data and then save it in memory. At this time, each partition is just a byte array, which greatly reduces the number of objects and memory usage. This level has more performance overhead than MEMORY_ONLY, mainly the overhead of serialization and deserialization. However, subsequent operators can operate based on pure memory, so the overall performance is still relatively high. In addition, the possible problems are the same as above. If the amount of data in the RDD is too large, it may cause an exception of OOM memory overflow.

• If the pure memory level is not available, it is recommended to use the MEMORY_AND_DISK_SER strategy instead of the MEMORY_AND_DISK strategy. Because since this step has been reached, it means that the amount of data in the RDD is very large, and the memory cannot be completely put down. The serialized data is relatively small, which can save memory and disk space overhead. At the same time, the strategy will try to cache the data in memory first, and will write to disk when the memory cache is not enough.

• It is generally not recommended to use DISK_ONLY and the level suffixed with _2: because data reading and writing is completely based on disk files, it will lead to a sharp decrease in performance, and sometimes it is better to recalculate all RDDs once. At the level with the suffix _2, all data must be replicated and sent to other nodes. Data replication and network transmission will cause a large performance overhead. Unless the high availability of the job is required, it is not recommended.

2. Try to avoid using shuffle operators

(1) What is shuffle?

    If possible, try to avoid using shuffle-like operators. Because the most performance-consuming part of the Spark job running process is the shuffle process. The shuffle process, in simple terms, is to pull the same key distributed on multiple nodes in the cluster to the same node, and perform operations such as aggregation or join. For example, operators such as reduceByKey and join will trigger shuffle operations.

 

(2) Problems caused by shuffle?

    During the shuffle process, the same key on each node will be written to the local disk file first, and then other nodes need to pull the same key in the disk file on each node through network transmission. Moreover, when the same key is pulled to the same node for aggregation operation, there may be too many keys processed on one node, resulting in insufficient memory storage, and then overflowing to the disk file. Therefore, during the shuffle process, a large number of IO operations of reading and writing disk files and network transmission operations of data may occur. Disk IO and network data transfer are also the main reasons for poor shuffle performance.

 

(3) Conclusion: try to avoid using

    因此在我们的开发过程中，能避免则尽可能避免使用reduceByKey、join、distinct、repartition等会进行shuffle的算子，尽量使用map类的非shuffle算子。这样的话，没有shuffle操作或者仅有较少shuffle操作的Spark作业，可以大大减少性能开销。

 

（4）一个优化demo：

    借助BroadCast + map 替代 直接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的全量数据。

 

 

3.使用map-side预聚合的shuffle操作 （针对一定使用shuffle，找不到替代方案的情况）

（1）预聚合做了什么？

    预聚合，类似于haodop中的Combiner。map-side预聚合之后，每个节点本地就只会有一条相同的key，因为多条相同的key都被聚合起来了。其他节点在拉取所有节点上的相同key时，就会大大减少需要拉取的数据数量，从而也就减少了磁盘IO以及网络传输开销

 

（2）用带预聚合的算子 替代 无预聚合的算子

    在可能的情况下，建议使用reduceByKey或者aggregateByKey算子来替代掉groupByKey算子。因为reduceByKey和aggregateByKey算子都会使用用户自定义的函数对每个节点本地的相同key进行预聚合。而groupByKey算子是不会进行预聚合的，全量的数据会在集群的各个节点之间分发和传输，性能相对来说比较差。

 

（3）图解 groupByKey （图1）和 reduceByKey（图2）

 

 

4.使用高性能算子

（1）常用的高性能算子

 

（2）filter之后进行coalesce操作（小文件问题）

    filter之后，RDD的每个partition中都会有很多数据被过滤掉，使用coalesce手动减少RDD的partition数量

 

（3）repartitionAndSortWithinPartitions替代repartition与sort类操作

    如果需要在repartition重分区之后，还要进行排序，建议直接使用repartitionAndSortWithinPartitions算子。因为该算子可以一边进行重分区的shuffle操作，一边进行排序。shuffle与sort两个操作同时进行，比先shuffle再sort来说，性能可能是要高的。

 

5.广播大变量

    广播后的变量，会保证每个Executor的内存中，只驻留一份变量副本，而Executor中的task执行时共享该Executor中的那份变量副本。这样的话，可以大大减少变量副本的数量，从而减少网络传输的性能开销，并减少对Executor内存的占用开销，降低GC的频率

 

6.使用kryo序列化

（1）使用到序列化的一些场景

• 广播变量
• RDD[自定义类型]
• 使用带序列化的持久化策略

 

（2）kryo序列化和java序列化对比

• java序列化：spark的默认选用，ObjectOutputStream/ObjectInputStream API来进行序列化和反序列化
• kryo序列化：性能比java的高处10倍左右，必须要注册，相对比较麻烦

    例如：

// 创建SparkConf对象。
val conf = new SparkConf().setMaster(...).setAppName(...)
// 设置序列化器为KryoSerializer。
conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
// 注册要序列化的自定义类型。
conf.registerKryoClasses(Array(classOf[MyClass1], classOf[MyClass2]))

 

 

 7.优化数据结构 （在保证可维护性前提下）

    （1）在保证代码可维护性的前提下，使用占用内存较少的数据结构

• 对象：每个Java对象都有对象头、引用等额外的信息，因此比较占用内存空间。
• 字符串：每个字符串内部都有一个字符数组以及长度等额外信息。
• 集合类型：比如HashMap、LinkedList等，因为集合类型内部通常会使用一些内部类来封装集合元素，比如Map.Entry。

 

    因此Spark官方建议，在Spark编码实现中，特别是对于算子函数中的代码，尽量不要使用上述三种数据结构，尽量使用字符串替代对象，使用原始类型（比如Int、Long）替代字符串，使用数组替代集合类型，这样尽可能地减少内存占用，从而降低GC频率，提升性能。

 

8.资源调优

（1）Spark作业基本运行原理

 

    详细原理见上图。我们使用spark-submit提交一个Spark作业之后，这个作业就会启动一个对应的Driver进程。根据你使用的部署模式（deploy-mode）不同，Driver进程可能在本地启动，也可能在集群中某个工作节点上启动。Driver进程本身会根据我们设置的参数，占有一定数量的内存和CPU core。而Driver进程要做的第一件事情，就是向集群管理器（可以是Spark Standalone集群，也可以是其他的资源管理集群，美团•大众点评使用的是YARN作为资源管理集群）申请运行Spark作业需要使用的资源，这里的资源指的就是Executor进程。YARN集群管理器会根据我们为Spark作业设置的资源参数，在各个工作节点上，启动一定数量的Executor进程，每个Executor进程都占有一定数量的内存和CPU core。

 

    在申请到了作业执行所需的资源之后，Driver进程就会开始调度和执行我们编写的作业代码了。Driver进程会将我们编写的Spark作业代码分拆为多个stage，每个stage执行一部分代码片段，并为每个stage创建一批task，然后将这些task分配到各个Executor进程中执行。task是最小的计算单元，负责执行一模一样的计算逻辑（也就是我们自己编写的某个代码片段），只是每个task处理的数据不同而已。一个stage的所有task都执行完毕之后，会在各个节点本地的磁盘文件中写入计算中间结果，然后Driver就会调度运行下一个stage。下一个stage的task的输入数据就是上一个stage输出的中间结果。如此循环往复，直到将我们自己编写的代码逻辑全部执行完，并且计算完所有的数据，得到我们想要的结果为止。

 

    Spark是根据shuffle类算子来进行stage的划分。如果我们的代码中执行了某个shuffle类算子（比如reduceByKey、join等），那么就会在该算子处，划分出一个stage界限来。可以大致理解为，shuffle算子执行之前的代码会被划分为一个stage，shuffle算子执行以及之后的代码会被划分为下一个stage。因此一个stage刚开始执行的时候，它的每个task可能都会从上一个stage的task所在的节点，去通过网络传输拉取需要自己处理的所有key，然后对拉取到的所有相同的key使用我们自己编写的算子函数执行聚合操作（比如reduceByKey()算子接收的函数）。这个过程就是shuffle。

 

    当我们在代码中执行了cache/persist等持久化操作时，根据我们选择的持久化级别的不同，每个task计算出来的数据也会保存到Executor进程的内存或者所在节点的磁盘文件中。

 

    因此Executor的内存主要分为三块：第一块是让task执行我们自己编写的代码时使用，默认是占Executor总内存的20%；第二块是让task通过shuffle过程拉取了上一个stage的task的输出后，进行聚合等操作时使用，默认也是占Executor总内存的20%；第三块是让RDD持久化时使用，默认占Executor总内存的60%。

 

    task的执行速度是跟每个Executor进程的CPU core数量有直接关系的。一个CPU core同一时间只能执行一个线程。而每个Executor进程上分配到的多个task，都是以每个task一条线程的方式，多线程并发运行的。如果CPU core数量比较充足，而且分配到的task数量比较合理，那么通常来说，可以比较快速和高效地执行完这些task线程。

 

（2）资源参数调优

    了解完了Spark作业运行的基本原理之后，对资源相关的参数就容易理解了。所谓的Spark资源参数调优，其实主要就是对Spark运行过程中各个使用资源的地方，通过调节各种参数，来优化资源使用的效率，从而提升Spark作业的执行性能。以下参数就是Spark中主要的资源参数，每个参数都对应着作业运行原理中的某个部分，我们同时也给出了一个调优的参考值。

 

 

• num-executors

    参数说明：该参数用于设置Spark作业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时，YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上，启动相应数量的Executor进程。这个参数非常之重要，如果不设置的话，默认只会给你启动少量的Executor进程，此时你的Spark作业的运行速度是非常慢的。

    参数调优建议：每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适，设置太少或太多的Executor进程都不好。设置的太少，无法充分利用集群资源；设置的太多的话，大部分队列可能无法给予充分的资源。

 

 

• executor-memory

    参数说明：该参数用于设置每个Executor进程的内存。Executor内存的大小，很多时候直接决定了Spark作业的性能，而且跟常见的JVM OOM异常，也有直接的关联。

    参数调优建议：每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值，具体的设置还是得根据不同部门的资源队列来定。可以看看自己团队的资源队列的最大内存限制是多少，num-executors乘以executor-memory，是不能超过队列的最大内存量的。此外，如果你是跟团队里其他人共享这个资源队列，那么申请的内存量最好不要超过资源队列最大总内存的1/3~1/2，避免你自己的Spark作业占用了队列所有的资源，导致别的同学的作业无法运行。

 

• executor-cores

    参数说明：该参数用于设置每个Executor进程的CPU core数量。这个参数决定了每个Executor进程并行执行task线程的能力。因为每个CPU core同一时间只能执行一个task线程，因此每个Executor进程的CPU core数量越多，越能够快速地执行完分配给自己的所有task线程。

    参数调优建议：Executor的CPU core数量设置为2~4个较为合适。同样得根据不同部门的资源队列来定，可以看看自己的资源队列的最大CPU core限制是多少，再依据设置的Executor数量，来决定每个Executor进程可以分配到几个CPU core。同样建议，如果是跟他人共享这个队列，那么num-executors * executor-cores不要超过队列总CPU core的1/3~1/2左右比较合适，也是避免影响其他同学的作业运行。

 

• driver-memory

    参数说明：该参数用于设置Driver进程的内存。

    参数调优建议：Driver的内存通常来说不设置，或者设置1G左右应该就够了。唯一需要注意的一点是，如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理，那么必须确保Driver的内存足够大，否则会出现OOM内存溢出的问题。

 

• spark.default.parallelism

    参数说明：该参数用于设置每个stage的默认task数量。这个参数极为重要，如果不设置可能会直接影响你的Spark作业性能。

    参数调优建议：Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数，那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量，默认是一个HDFS block对应一个task。通常来说，Spark默认设置的数量是偏少的（比如就几十个task），如果task数量偏少的话，就会导致你前面设置好的Executor的参数都前功尽弃。试想一下，无论你的Executor进程有多少个，内存和CPU有多大，但是task只有1个或者10个，那么90%的Executor进程可能根本就没有task执行，也就是白白浪费了资源！因此Spark官网建议的设置原则是，设置该参数为num-executors * executor-cores的2~3倍较为合适，比如Executor的总CPU core数量为300个，那么设置1000个task是可以的，此时可以充分地利用Spark集群的资源。

 

• spark.storage.memoryFraction

    参数说明：该参数用于设置RDD持久化数据在Executor内存中能占的比例，默认是0.6。也就是说，默认Executor 60%的内存，可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略，如果内存不够时，可能数据就不会持久化，或者数据会写入磁盘。

    参数调优建议：如果Spark作业中，有较多的RDD持久化操作，该参数的值可以适当提高一些，保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据，导致数据只能写入磁盘中，降低了性能。但是如果Spark作业中的shuffle类操作比较多，而持久化操作比较少，那么这个参数的值适当降低一些比较合适。此外，如果发现作业由于频繁的gc导致运行缓慢（通过spark web ui可以观察到作业的gc耗时），意味着task执行用户代码的内存不够用，那么同样建议调低这个参数的值。

 

• spark.shuffle.memoryFraction

    参数说明：该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后，进行聚合操作时能够使用的Executor内存的比例，默认是0.2。也就是说，Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时，如果发现使用的内存超出了这个20%的限制，那么多余的数据就会溢写到磁盘文件中去，此时就会极大地降低性能。

    参数调优建议：如果Spark作业中的RDD持久化操作较少，shuffle操作较多时，建议降低持久化操作的内存占比，提高shuffle操作的内存占比比例，避免shuffle过程中数据过多时内存不够用，必须溢写到磁盘上，降低了性能。此外，如果发现作业由于频繁的gc导致运行缓慢，意味着task执行用户代码的内存不够用，那么同样建议调低这个参数的值。

    资源参数的调优，没有一个固定的值，需要同学们根据自己的实际情况（包括Spark作业中的shuffle操作数量、RDD持久化操作数量以及spark web ui中显示的作业gc情况），同时参考本篇文章中给出的原理以及调优建议，合理地设置上述参数。

 

资源参数参考示例

以下是一份spark-submit命令的示例，大家可以参考一下，并根据自己的实际情况进行调节：

./bin/spark-submit \

  --master yarn-cluster \

  --num-executors 100 \

  --executor-memory 6G \

  --executor-cores 4 \

  --driver-memory 1G \

  --conf spark.default.parallelism=1000 \

  --conf spark.storage.memoryFraction=0.5 \

  --conf spark.shuffle.memoryFraction=0.3 \

 

总结：根据实践经验来看，大部分Spark作业经过本次基础篇所讲解的开发调优与资源调优之后，一般都能以较高的性能运行了，足以满足我们的需求