第 1 章 Spark 性能调优
问：spark 优化
第一句：我们可以从性能，算子，shuffle 过程以及 jvm 四个方面展开优化。
1 常规性能调优
1.1 常规性能调优一：最优资源配置
Spark 性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。
资源的分配在使用脚本提交 Spark 任务时进行指定，标准的 Spark 任务提交脚本如下所示：
bin/spark-submit \
--class com.bigdata.spark.Analysis \
--master yarn
--deploy-mode cluster
--num-executors 80 \
--driver-memory 6g \
--executor-memory 6g \
--executor-核s 3 \
/usr/opt/modules/spark/jar/spark.jar \结合项目，每一个任务都需要分配资源，这个时候可以适当说的少一些，对于比较大的指标，可以适当增加一些。知道什么是 driver 什么是executor。
可以进行分配的资源如表所示：
| 名称 | 说明 |
| --num-executors | 配置 Executor 的数量 |
| --driver-memory | 配置 Driver 内存（ 影响不大） |
| --executor-memory | 配置每个 Executor 的内存大小 |
| --executor-核s | 配置每个 Executor 的 CPU 核 数量 |
调节原则：尽量将任务分配的资源调节到可以使用的资源的最大限度。对于具体资源的分配，我们分别讨论 Spark 的两种Cluster 运行模式：
- 第一种是 Spark Standalone 模式，你在提交任务前，一定知道或者可以从运维部门获取到你可以使用的资源情况，在编写 submit 脚本的时候，就根据可用的资源情况进行资源的分配，比如说集群有 15 台机器，每台机器为 8G 内存，2 个 CPU 核，那么就指定 15 个 Executor，每个 Executor 分配 8G 内存，2 个 CPU 核。
- 第二种是 Spark Yarn 模式，由于 Yarn 使用资源队列进行资源的分配和调度，在编写submit 脚本的时候，就根据Spark 作业要提交到的资源队列，进行资源的分配，比如资源队列有 400G 内存，100 个 CPU 核，那么指定 50 个 Executor，每个 Executor 分配8G 内存，2 个 CPU 核。
对各项资源进行了调节后，得到的性能提升会有如下表现：
| 名称 | 解析 |
| 增加 Executor·个数 | 在资源允许的情况下，增加 Executor 的个数可以提高执行 task（任务） 的并行度。比如有 4 个Executor，每个 Executor 有 2 个 CPU 核，那么可以并行执行 8 个 task（任务），如果将 Executor 的个数增加到 8 个（ 资源允许的情况下）， 那么可以并行执行 16 个 task（任务）， 此时的并行能力提升了一倍。 |
| 增加每个 Executor 的 CPU 核 个数 | 在资源允许的情况下，增加每个 Executor 的Cpu 核 个数， 可以提高执行 task（任务） 的并行度。比如有 4 个 Executor，每个 Executor 有 2 个CPU 核，那么可以并行执行 8 个 task（任务），如果将每个 Executor 的 CPU 核 个数增加到 4 个（ 资源允许的情况下），那么可以并行执行 16个 task（任务）， 此时的并行能力提升了一倍。 |
| 增加每个 Executor 的内存量 | 在资源允许的情况下，增加每个 Executor 的内存量以后， 对性能的提升有三点：
|
补充：生产环境 Spark submit 脚本配置
bin/spark-submit \
--class com.bigdata.spark.WordCount \
--master yarn\
--deploy-mode cluster\
--num-executors 80 \
--driver-memory 6g \
--executor-memory 6g \
--executor-核s 3 \
--queue root.default \
--conf spark.yarn.executor.memoryOverhead=2048 \
--conf spark.核.connection.ack.wait.timeout=300 \
/usr/local/spark/spark.jar参数配置参考值：
-
- --num-executors：50~100
- --driver-memory：1G~5G
- --executor-memory：6G~10G
- --executor-核s：3
- --master：实际生产环境一定使用 yarn
1.2 常规性能调优二：RDD 优化
RDD 复用
在对RDD 进行算子时，要避免相同的算子和计算逻辑之下对RDD 进行重复的计算
对上图中的 RDD 计算架构进行修改， 得到如下图所示的优化结果：
RDD 持久化
在 Spark 中，当多次对同一个 RDD 执行算子操作时，每一次都会对这个 RDD 以之前的父 RDD 重新计算一次，这种情况是必须要避免的，对同一个 RDD 的重复计算是对资源的极大浪费，因此，必须对多次使用的 RDD 进行持久化，通过持久化将公共 RDD 的数据缓存到内存/磁盘中，之后对于公共RDD 的计算都会从内存/磁盘中直接获取 RDD 数据。对于RDD 的持久化，有两点需要说明：
- RDD 的持久化是可以进行序列化的，当内存无法将 RDD 的数据完整的进行存放的时候，可以考虑使用序列化的方式减小数据体积，将数据完整存储在内存中。
- 如果对于数据的可靠性要求很高，并且内存充足，可以使用副本机制，对 RDD 数据进行持久化。当持久化启用了复本机制时，对于持久化的每个数据单元都存储一个副本， 放在其他节点上面，由此实现数据的容错，一旦一个副本数据丢失，不需要重新计算，还可以使用另外一个副本。
你们公司的 rdd 持久化使用的哪种方案？九种选两种
RDD 尽可能早的 filter 操作
获取到初始 RDD 后，应该考虑尽早地过滤掉不需要的数据，进而减少对内存的占用， 从而提升 Spark 作业的运行效率。
1.3 常规性能调优三：并行度调节
Spark 作业中的并行度指各个 stage（阶段） 的 task（任务） 的数量。
如果并行度设置不合理而导致并行度过低，会导致资源的极大浪费，例如，20 个Executor，每个Executor 分配 3 个CPU 核，而 Spark 作业有 40 个 task（任务），这样每个 Executor 分配到的 task（任务） 个数是 2 个，这就使得每个 Executor 有一个CPU 核 空闲，导致资源的浪费。
理想的并行度设置，应该是让并行度与资源相匹配，简单来说就是在资源允许的前提下， 并行度要设置的尽可能大，达到可以充分利用集群资源。合理的设置并行度，可以提升整个Spark 作业的性能和运行速度。
一个Job由多个Stage构成，每个Stage都会转换成为一个 TaskSet【Task集合】集合，每个TaskSet中可以包含多个Task。
read --> map -->flatmap--reduceByKey-->foreach 等
整体是一个 job,分为两个 stage, (read-->map-->flatmap) 这是一个，剩余是另一个，因为遇到了 shuffle 算子。
read-->map-->flatmap 假如并行度是 3，有 3 个 task 任务，
剩余部分是另外的 task 任务，将来这些 task 任务会在 executor 中运行。你的 executor 有可能有好多个，每一个又有好多核数。
并行度如果不设置，是多少呢？默认官方说是 200 个，不要和 flink 的并行度混淆。
Spark 官方推荐，task（任务） 数量应该设置为 Spark 作业总CPU 核 数量的 2~3 倍。之所以没有推荐task（任务） 数量与CPU 核 总数相等，是因为 task（任务） 的执行时间不同，有的task（任务） 执行速度快而有的 task（任务） 执行速度慢，如果 task（任务） 数量与CPU 核 总数相等，那么执行快的 task（任务） 执行完成后，会出现 CPU 核 空闲的情况。如果 task（任务） 数量设置为CPU 核 总数的 2~3 倍，那么一个task（任务） 执行完毕后，CPU 核
