在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算子不会预聚合
