4.Spark调优

在Spark中，每一个进程包含一个executor对象，一个executor包含一个线程池，每个线程执行一个tasks

• 线程池的好处就在于省去了线程频繁启停的开销
• task并发度的概念
  1.每一个节点可以启动一个或者多个executor进程
  2.每一个executor进程可以有多个core组成，每一个core一次只能执行一个task，core是虚拟出的cpu，人为设定的，每次任务不能超过core数的并发度，也可以理解成线程池的最大线程数

内存划分

20% execution（执行内存）

join，groupby这类算子设计内存，shuffle数据都会缓存在这个内存区，如果内存满，把数据写到磁盘（spill）

60% storage

存储cache，presist，broadcast（广播，数据量不是特别大的时候，类似MapReduce里的-file分发）数据

20% 留给程序自己

版本相关

1.6.0之前

每个类的内存是相互隔离的，导致了executor的内存利用率不高，只能使用者自己调整参数来优化内存

1.6.0以上

execution和storage内存是可以相互借用的，减少了OOM（out of memory）的情况发生

参数调优

num-executors

• 该作业总共需要多少executor进程执行
• 建议：每个作业运行一班设置50-100个左右较合适，设置太少无法充分利用集群资源，设置太多大部分队列可能无法给予充分的资源

executor-memory

• 设置每个executor进程的内存，num-executors * executor-memory代表作业申请的总内存了（尽量不要超过最大总内存的1/3~1/2）
• 建议：设置4G~8G较合适
• executor内存的大小，很多时候直接决定了spark作业的性能，而且跟常见的JVM OOM异常也有直接的关联

executor-cores

• 每个executor进程的CPU core数量，该参数决定每个executor进行并行执行task线程的能力，num-executors * executor-cores代表作业申请总CPU core数，不要超过总CPU core的1/3~1/2
• 建议:设置2~4个较合适
• 每个CPU core同一时间只能执行一个task进程，因为每个executor进程的CPU core数量越多，越能够快速的执行完分配给自己的所有task线程

driver-memory

• 设置Driver进程的内存
• 建议：通常不同设置，一般1G就够了，若出现使用collect算子将RDD数据全部拉取到Driver上处理，就必须确保该值足够大，否则OOM内存溢出

spark.default.parallelism

• 每个stage的默认task数量
• 建议：设置500~1000较合适，默认一个HDFS的block对应一个task，Spark默认值偏少，这样导致不能充分利用资源

spark.storage.memoryFraction

• 设置RDD持久化数据在executor内存中能占的比例，默认0.6，即默认executor 60%内存可以保存持久化RDD数据
• 建议：如有较多的持久化操作，可以设置高些，超出内存的会频繁GC，导致运行缓慢

spark.shuffle.memoryFraction

• 聚合操作占executor内存的比例，默认0.2
• 建议:若持久化操作较少，但shuffle较多时，可以降低持久化内存占比，提高shuffle操作内存占比

spark的作业提交
./bin/spark-submit \
  --master yarn-cluster \
  --num-executors 100 \  #需要多少进程
  --executor-memory 6G \ #每个进程需要多大内存
  --executor-cores 4 \   #每个进程可以并发多少个task
  --driver-memory 1G \   #默认1G，本地上传的时候需要设置，以供上传的数据放入内存，方便使用
  --conf spark.default.parallelism=1000 \ #并发度
  --conf spark.storage.memoryFraction=0.5 \
  --conf spark.shuffle.memoryFraction=0.3 

开发调优原则

1.避免创建重复的RDD

• 对同一份数据，只应该创建一个RDD，不能创建多个RDD来代表同一份数据，极大浪费内存

2.尽可能复用同一个人RDD

• 比如：一个RDD的数据格式是key-value，另一个单独value类型，这两个RDD的value部分完全一样，这样可以复用，达到减少算子执行次数

3.对多次使用的RDD进行持久化处理

• 每次对一个RDD执行一个算子操作时，都会重新从源头处理计算一遍，性能很差
• 对多次使用的RDD进行持久化，将RDD的数据保存在内存或者磁盘中，避免重复劳动
• 借助cache()和persist()方法
  
  

4.避免使用shuffle类算子

• 最消耗性能的地方就是shuffle过程，因为要等待所有数据准备就绪才能执行
• 将分布在集群众多个节点上的同一个key，拉取到同一个节点上，进行聚合和join处理，比如groupByKey，reduceByKey，join等算子，都会触发shuffle

5.使用map-side预聚合的shuffle操作

• 一定要使用shuffle的，无法使用map类算子替代的，尽量使用map-side预聚合的算子
• 思想类似MapReduce中的Combiner（提前计算，减少数据规模）
• 可能的情况下使用reduceByKey或aggregateByKey算子替代groupByKey算子，因为reduceByKey或aggregateByKey算子会使用用户自定义的函数对每个节点本地相同的key进行预聚合，而groupByKey算子不会预聚合