spark 优化总结(面试必问)

spark优化总结:

一、spark 代码优化

六大代码优化:
避免创建重复的RDD 
尽可能复用同一个RDD 
对多次使用的RDD进行持久化 
尽量避免使用shuffle类算子 
使用map-side预聚合的shuffle操作 
使用高性能的算子 
广播大变量
使用Kryo优化序列化性能 
优化数据结构
使用高性能的库fastutil 

1. 对多次使用的RDD进行持久化

同常内存够的时候建议使用:MEMORY_ONLY

如果内存不够的时候使用通常建议使用:MEMORY_AND_DISK_SER策略，而不是 MEMORY_AND_DISK策略。

如何选择一种最合适的持久化策略 1 
默认情况下，性能最高的当然是MEMORY_ONLY，但前提是你的内存必须足够足够大， 可以绰绰有余地存放下整个RDD的所有数据。因为不进行序列化与反序列化操作，就避 免了这部分的性能开销;对这个RDD的后续算子操作，
都是基于纯内存中的数据的操作 ，不需要从磁盘文件中读取数据，性能也很高;而且不需要复制一份数据副本，并远程传 送到其他节点上。但是这里必须要注意的是，在实际的生产环境中，恐怕能够直接用这种 策略的场景还是有限的，
如果RDD中数据比较多时(比如几十亿)，直接用这种持久化 级别，会导致JVM的OOM内存溢出异常。 

如果使用MEMORY_ONLY级别时发生了内存溢出，那么建议尝试使用 MEMORY_ONLY_SER级别。该级别会将RDD数据序列化后再保存在内存中，此时每个 partition仅仅是一个字节数组而已，大大减少了对象数量，并降低了内存占用。
这种级别 比MEMORY_ONLY多出来的性能开销，主要就是序列化与反序列化的开销。但是后续算 子可以基于纯内存进行操作，因此性能总体还是比较高的。此外，可能发生的问题同上， 如果RDD中的数据量过多的话，
还是可能会导致OOM内存溢出的异常。 

如何选择一种最合适的持久化策略 2
如果纯内存的级别都无法使用，那么建议使用MEMORY_AND_DISK_SER策略，而不是 MEMORY_AND_DISK策略。因为既然到了这一步，就说明RDD的数据量很大，内存无 法完全放下。序列化后的数据比较少，
可以节省内存和磁盘的空间开销。同时该策略会优 先尽量尝试将数据缓存在内存中，内存缓存不下才会写入磁盘。 

通常不建议使用DISK_ONLY和后缀为_2的级别:因为完全基于磁盘文件进行数据的读写 ，会导致性能急剧降低，有时还不如重新计算一次所有RDD。后缀为_2的级别，必须将 所有数据都复制一份副本，并发送到其他节点上，
数据复制以及网络传输会导致较大的性 能开销，除非是要求作业的高可用性，否则不建议使用。 

 

2. 使用高性能的算子

使用reduceByKey/aggregateByKey替代groupByKey 

使用mapPartitions替代普通map Transformation算子 

使用foreachPartitions替代foreach Action算子 

使用filter之后进行coalesce操作 

使用repartitionAndSortWithinPartitions替代repartition与sort类操作代码

repartition:coalesce(numPartitions，true) 增多分区使用这个 

coalesce(numPartitions，false) 减少分区 没有shuffle只是合并 partition 

3. 广播大变量

1. 开发过程中，会遇到需要在算子函数中使用外部变量的场景(尤其是大变量，比如 100M以上的大集合)，那么此时就应该使用Spark的广播(Broadcast)功能来提 升性能 

2. 函数中使用到外部变量时，默认情况下，Spark会将该变量复制多个副本，通过网络 传输到task中，此时每个task都有一个变量副本。如果变量本身比较大的话(比如 100M，甚至1G)，
　　那么大量的变量副本在网络中传输的性能开销，以及在各个节 点的Executor中占用过多内存导致的频繁GC（垃圾回收），都会极大地影响性能 

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

4. 广播大变量发送方式:Executor一开始并没有广播变量，而是task运行需要用到广 播变量，会找executor的blockManager要，bloackManager找Driver里面的 blockManagerMaster要。 

 

4. 使用Kryo优化序列化性能

在Spark中，主要有三个地方涉及到了序列化: 

在算子函数中使用到外部变量时，该变量会被序列化后进行网络传输 

将自定义的类型作为RDD的泛型类型时(比如JavaRDD，SXT是自定义类型)，所有自 定义类型对象，都会进行序列化。因此这种情况下，也要求自定义的类必须实现 Serializable接口。 

使用可序列化的持久化策略时(比如MEMORY_ONLY_SER)，Spark会将RDD中的每个 partition都序列化成一个大的字节数组。 

Kryo序列化器介绍: Spark支持使用Kryo序列化机制。Kryo序列化机制，比默认的Java序列化机制，速度要快 ，序列化后的数据要更小，大概是Java序列化机制的1/10。所以Kryo序列化优化以后，可 以让网络传输的数据变少;在集群中耗费的内存资源大大减少。 对于这三种出现序列化的地方，我们都可以通过使用Kryo序列化类库，来优化序列化和 反序列化的性能。Spark默认使用的是Java的序列化机制，也就是 ObjectOutputStream/ObjectInputStream API来进行序列化和反序列化。但是Spark同 时支持使用Kryo序列化库，Kryo序列化类库的性能比Java序列化类库的性能要高很多。 官方介绍，Kryo序列化机制比Java序列化机制，性能高10倍左右。Spark之所以默认没有 使用Kryo作为序列化类库，是因为Kryo要求最好要注册所有需要进行序列化的自定义类 型，因此对于开发者来说，这种方式比较麻烦

5. 优化数据结构

Java中，有三种类型比较耗费内存: 

对象，每个Java对象都有对象头、引用等额外的信息，因此比较占用内存空间。 

字符串，每个字符串内部都有一个字符数组以及长度等额外信息。 

集合类型，比如HashMap、LinkedList等，因为集合类型内部通常会使用一些内部类来 封装集合元素，比如Map.Entry。 

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

6. 使用高性能的库fastutil

fastutil介绍: 
fastutil是扩展了Java标准集合框架(Map、List、Set;HashMap、ArrayList、 HashSet)的类库，提供了特殊类型的map、set、list和queue; 
fastutil能够提供更小的内存占用，更快的存取速度;我们使用fastutil提供的集合类，来 替代自己平时使用的JDK的原生的Map、List、Set，好处在于，
fastutil集合类，可以减 小内存的占用，并且在进行集合的遍历、根据索引(或者key)获取元素的值和设置元素 的值的时候，提供更快的存取速度; 
fastutil最新版本要求Java 7以及以上版本; 
fastutil的每一种集合类型，都实现了对应的Java中的标准接口(比如fastutil的map，实 现了Java的Map接口)，因此可以直接放入已有系统的任何代码中。 
fastutil的每一种集合类型，都实现了对应的Java中的标准接口(比如fastutil的 map，实现了Java的Map接口)，因此可以直接放入已有系统的任何代码中。
使用? 

IDEA中导入依赖

<!-- https://mvnrepository.com/artifact/fastutil/fastutil -->
<dependency>
<groupId>fastutil</groupId>
<artifactId>fastutil</artifactId>
<version>5.0.9</version>
</dependency>

 

二、spark 参数调优

--num-executors executor的数量
--executor-memory 每一个executor的内存
--executor-cores 每一个executor的核心数
--driver-memory Driver的内存1G-2G(保存广播变量)
--spark.storage.memoryFraction 用于缓存的内存占比默认时0.6,如果代码中没有用到缓存 可以将内存分配给shuffle
--spark.shuffle.memoryFraction 用户shuffle的内存占比默认0.2

总的内存=num-executors*executor-memory
总的核数=num-executors*executor-cores

spark on yarn 资源设置标准

1、单个任务总的内存和总的核数一般做多在yarn总资源的1/3到1/2之间
比如公司集群有10太服务器
单台服务器内存是128G,核数是40
yarn总的内存=10*128G=1280G*0.8=960G 需要预留一般分内存给系统进程
yarn总的核数=40*10=400

提交单个spark任务资源上线
总的内存=960G *(1/3| 1/2) = 300G-500G
总的核数=400 * (1/3| 1/2) = 120 - 200

2、在上线内再按照需要处理的数据量来合理指定资源 -- 最理想的情况是一个task对应一个core

2.1、数据量比较小 - 10G
10G = 80个block = rdd80分区 = 80个task
- 最理想资源指定 -- 剩余资源充足
--num-executors=40
--executor-memory=4G
--executor-cores=2
- 资源里面最优的方式 -- 剩余资源不是很充足时
--num-executors=20
--executor-memory=4G
--executor-cores=2

2.2、数据量比较大时 - 80G
80G = 640block = 640分区 = 640task
- 最理想资源指定 -- 剩余资源充足, 如果剩余资源不够，还需要减少指定的资源
--num-executors=100
--executor-memory=4G
--executor-cores=2

-- spark.locality.wait: spark task 再executor中执行前的等待时间 默认3秒
spark.yarn.executor.memoryOverhead : 堆外内存 默认等于堆内存的10%
spark.network.timeout spark网络链接的超时时间 默认120s

提高数据本地化优先级别

附录:参数调优详解

1参数调优
1.1num-executors
　　参数说明：该参数用于设置Spark作业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时，YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上，启动相应数量的Executor进程。
这个参数非常之重要，如果不设置的话，默认只会给你启动少量的Executor进程，此时你的Spark作业的运行速度是非常慢的。
　　参数调优建议：每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适，设置太少或太多的Executor进程都不好。设置的太少，无法充分利用集群资源；设置的太多的话，大部分队列可能无法给予充分的资源。
1.2executor-memory
　　参数说明：该参数用于设置每个Executor进程的内存。Executor内存的大小，很多时候直接决定了Spark作业的性能，而且跟常见的JVM OOM异常，也有直接的关联。
　　参数调优建议：每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值，具体的设置还是得根据不同部门的资源队列来定。可以看看自己团队的资源队列的最大内存限制是多少，
num-executors乘以executor-memory，就代表了你的Spark作业申请到的总内存量（也就是所有Executor进程的内存总和），这个量是不能超过队列的最大内存量的。此外，如果你是跟团队里其他人共享这个资源队列，
那么申请的总内存量最好不要超过资源队列最大总内存的1/3~1/2，避免你自己的Spark作业占用了队列所有的资源，导致别的同学的作业无法运行。
1.3executor-cores    可以用total-executor-cores总的核数
executor-cores = total-executor-cores / num-executors
　　参数说明：该参数用于设置每个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左右比较合适，也是避免影响其他同学的作业运行。
1.4driver-memory
　　参数说明：该参数用于设置Driver进程的内存。
　　参数调优建议：Driver的内存通常来说不设置，或者设置1G左右应该就够了。唯一需要注意的一点是，如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理，那么必须确保Driver的内存足够大，
否则会出现OOM内存溢出的问题。
1.5spark.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集群的资源。
1.6spark.storage.memoryFraction
　　参数说明：该参数用于设置RDD持久化数据在Executor内存中能占的比例，默认是0.6。也就是说，默认Executor 60%的内存，可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略，如果内存不够时，
可能数据就不会持久化，或者数据会写入磁盘。
　　参数调优建议：如果Spark作业中，有较多的RDD持久化操作，该参数的值可以适当提高一些，保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据，导致数据只能写入磁盘中，降低了性能。
但是如果Spark作业中的shuffle类操作比较多，而持久化操作比较少，那么这个参数的值适当降低一些比较合适。此外，如果发现作业由于频繁的gc导致运行缓慢（通过spark web ui可以观察到作业的gc耗时），
意味着task执行用户代码的内存不够用，那么同样建议调低这个参数的值。
1.7spark.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任务提交参数设置模板(企业中)

spark-submit
--master yarn-cluster
--num-executors = 50
--executor-memory = 4G
--executor-cores = 2
--driver-memory = 2G
--conf spark.storage.memoryFraction=0.4
--conf spark.shuffle.memoryFraction=0.4
--conf spark.locality.wait=10s
--conf spark.shuffle.file.buffer=64kb
--conf spark.yarn.executor.memoryOverhead=1024
--conf spark.network.timeout=200s

 

三、spark 数据倾斜

1、使用Hive ETL预处理数据

方案适用场景:如果导致数据倾斜的是Hive表。如果该Hive表中的数据本身很不均匀(比如某个 key对应了100万数据，其他key才对应了10条数据)，而且业务场景需要频繁使用Spark对Hive表 执行某个分析操作，
那么比较适合使用这种技术方案。 

方案实现思路:此时可以评估一下，是否可以通过Hive来进行数据预处理(即通过Hive ETL预先对 数据按照key进行聚合，或者是预先和其他表进行join)，然后在Spark作业中针对的数据源就不是 原来的Hive表了，
而是预处理后的Hive表。此时由于数据已经预先进行过聚合或join操作了，那么 在Spark作业中也就不需要使用原先的shuffle类算子执行这类操作了。 

方案实现原理:这种方案从根源上解决了数据倾斜，因为彻底避免了在Spark中执行shuffle类算子 ，那么肯定就不会有数据倾斜的问题了。但是这里也要提醒一下大家，这种方式属于治标不治本。 
因为毕竟数据本身就存在分布不均匀的问题，所以Hive ETL中进行group by或者join等shuffle操作 时，还是会出现数据倾斜，导致Hive ETL的速度很慢。我们只是把数据倾斜的发生提前到了Hive ETL中，
避免Spark程序发生数据倾斜而已。 

2、过滤少数导致倾斜的key

方案适用场景:如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很 适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导 致了数据倾斜。 

方案实现思路:如果我们判断那少数几个数据量特别多的key，对作业的执行和计算结果不是特别 重要的话，那么干脆就直接过滤掉那少数几个key。比如，在Spark SQL中可以使用where子句过滤掉这些key或者在Spark Core中
对RDD执行filter算子过滤掉这些key。如果需要每次作业执行时， 动态判定哪些key的数据量最多然后再进行过滤，那么可以使用sample算子对RDD进行采样，然后 计算出每个key的数量，取数据量最多的key过滤掉即可。 

方案实现原理:将导致数据倾斜的key给过滤掉之后，这些key就不会参与计算了，自然不可能产生 数据倾斜。 

3、提高shuffle操作的并行度

方案实现思路:在对RDD执行shuffle算子时，给shuffle算子传入一个参数，比如 reduceByKey(1000)，该参数就设置了这个shuffle算子执行时shuffle read task的数量。对于 Spark SQL中的shuffle类语句，
比如group by、join等，需要设置一个参数，即 spark.sql.shuffle.partitions，该参数代表了shuffle read task的并行度，该值默认是200，对于很 多场景来说都有点过小。 

方案实现原理:增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个 task，从而让每个task处理比原来更少的数据。举例来说，如果原本有5个key，每个key对应10条 数据，
这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时 间都会变短了。具体原理如下图所示。 

4、双重聚合join

方案适用场景:对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by 语句进行分组聚合时，比较适用这种方案。 

方案实现思路:这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合，先给每个key 都打上一个随机数，比如10以内的随机数，此时原先一样的key就变成不一样的了，
比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。接着 对打上随机数后的数据，执行reduceByKey等聚合操作，
进行局部聚合，那么局部聚合结果，就会 变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉，就会变成(hello,2)(hello,2)，再次 进行全局聚合操作，就可以得到最终结果了，比如(hello, 4)。 

方案实现原理:将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被 一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。 接着去除掉随机前缀，
再次进行全局聚合，就可以得到最终的结果 

5、将reduce join转为map join

方案适用场景:在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中 的一个RDD或表的数据量比较小(比如几百M或者一两G)，比较适用此方案。 

方案实现思路:不使用join算子进行连接操作，而使用Broadcast变量与map类算子实现join操作， 进而完全规避掉shuffle类的操作，彻底避免数据倾斜的发生和出现。
将较小RDD中的数据直接通过 collect算子拉取到Driver端的内存中来，然后对其创建一个Broadcast变量;接着对另外一个RDD 执行map类算子，在算子函数内，从Broadcast变量中获取较小RDD的全量数据，
与当前RDD的每 一条数据按照连接key进行比对，如果连接key相同的话，那么就将两个RDD的数据用你需要的方式 连接起来。 

方案实现原理:普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉 取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的， 
则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不 会发生shuffle操作，也就不会发生数据倾斜 

 

6、采样倾斜key并分拆join操作

方案适用场景:两个RDD/Hive表进行join的时候，如果数据量都比较大，无法采用“解决方案五 ”，那么此时可以看一下两个RDD/Hive表中的key分布情况。如果出现数据倾斜，
是因为其中某一 个RDD/Hive表中的少数几个key的数据量过大，而另一个RDD/Hive表中的所有key都分布比较均 匀，那么采用这个解决方案是比较合适的。

方案实现思路: 
对包含少数几个数据量过大的key的那个RDD，通过sample算子采样出一份样本来，然后统计一下每个 key的数量，计算出来数据量最大的是哪几个key。 
然后将这几个key对应的数据从原来的RDD中拆分出来，形成一个单独的RDD，并给每个key都打上n以 内的随机数作为前缀，而不会导致倾斜的大部分key形成另外一个RDD。 
接着将需要join的另一个RDD，也过滤出来那几个倾斜key对应的数据并形成一个单独的RDD，将每条数 据膨胀成n条数据，这n条数据都按顺序附加一个0~n的前缀，不会导致倾斜的大部分key也形成另外一个 RDD。 
再将附加了随机前缀的独立RDD与另一个膨胀n倍的独立RDD进行join，此时就可以将原先相同的key打 散成n份，分散到多个task中去进行join了。 
而另外两个普通的RDD就照常join即可。 
最后将两次join的结果使用union算子合并起来即可，就是最终的join结果。 

7、使用随机前缀和扩容RDD进行join

方案适用场景:如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没 什么意义，此时就只能使用最后一种方案来解决问题了。 

方案实现思路: 
该方案的实现思路基本和“解决方案六”类似，首先查看RDD/Hive表中的数据分布情况，找到那个造成 数据倾斜的RDD/Hive表，比如有多个key都对应了超过1万条数据。 
然后将该RDD的每条数据都打上一个n以内的随机前缀。 
同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一 个0~n的前缀。 
最后将两个处理后的RDD进行join即可。 

方案实现原理:将原先一样的key通过附加随机前缀变成不一样的key，然后就可以将这些处理后的 “不同key”分散到多个task中去处理，而不是让一个task处理大量的相同key。该方案与“解决方 案六”的不同之处就在于，上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处 理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大;而这一种方案是针对有大 量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对 内存资源要求很高。