spark中num-executors，executor-cores，executor-memory调参的艺术_综合

在跑Spark-On-Yarn程序的时候，往往会对几个参数（num-executors，executor-cores，executor-memory等）理解很模糊，从而凭感觉地去指定值，这是不符合有追求程序员信仰的。因此，搞懂它们，很有必要。
本文翻译自https://spoddutur.github.io/spark-notes/distribution_of_executors_cores_and_memory_for_spark_application.html。

译文如下：

是否曾经想要知道如何根据你的集群，配置这些Spark运行参数：--num-executors, --executor-memory and --execuor-cores 呢？

探究思路

理论引导：首先，有必要了解一些重要建议，能帮助我们更好地理解它；
实战：其次，以一个集群为例，推演出该集群的参数的推荐值。

理论引导

当配置参数时，请遵循下表，将其推荐建议牢记于心

Hadoop/Yarn/OS 守护进程：
当利用一个集群管理器（比如YARN）运行spark程序时，存在一些守护进程运行在后台，比如NameNode，Secondary NameNode，DataNode，JobTracker和TaskTracker。因此，当确定num-executor时，我们需要确保有足够的cores（大约每个节点一个core）维持这些守护进程的平稳运行。
Yarn ApplicationMaster (AM)：
ApplicationMaster的职责是：向ResourceManager协商资源，与NodeManager一同执行并监控containner及其资源消耗。如果程序运行在Spark-On-Yarn，我们需要预留一些资源给ApplicationMaster，AM大约需要1024MB的内存和一个Executor。
HDFS吞吐：
HDFS客户端会遇到大量并发线程的问题。据观察，HDFS当达到全写入吞吐量时，需要每个executor执行约5个任务。因此，最好控制每个executor中core的数目低于那个数字。
内存开销：
下图描绘了spark-yarn的内存使用情况：
[图片上传失败...(image-fa6806-1536392056623)]
图中注意两件事情：

       Full memory requested to yarn per executor =spark-executor-memory + spark.yarn.executor.memoryOverheadspark.yarn.executor.memoryOverhead = Max(384MB, 7% of spark.executor-memory)

所以，如果我们申请了每个executor的内存为20G时，对我们而言，AM将实际得到20G+ memoryOverhead = 20 + 7% * 20GB = ～23G内存。

执行拥有太多内存的executor会产生过多的垃圾回收延迟
执行过小的executor（举例而言，一个只有一核和仅仅足够内存跑一个task的executor），将会丢失在单个JVM中运行多任务的好处。

理论够了...开始实战

现在，我们考虑一个10个节点的如下配置的集群，并分析不同参数设置的结果。
集群配置如下：

**集群配置:**
10个节点
每个节点16核
每个节点64G内存

第一种方案：Tiny executors [每个Executor一个Core]

Tiny executors表示一个executor配置一个core。下表描述了该方案下的参数配置。

- '--num-executors' = '该方案下，每个executor配置一个core'= '集群中的core的总数'= '每个节点的core数目 * 集群中的节点数' = 16 x 10 = 160
- '--executor-cores' = 1 (每个executor一个core)
- '--executor-memory' = '每个executor的内存'= '每个节点的内存/每个节点的executor数目'= 64GB/16 = 4GB

分析：当一个executor只有一个core时，正如我们上面分析的，我们可能不能发挥在单个JVM上运行多任务的优势。此外，共享/缓存变量（如广播变量和累加器）将复制到节点的每个core，这里是16次。并且，我们没有为Hadoop / Yarn守护进程留下足够的内存开销，我们也没有计入ApplicationManager。因此，这不是一个好的方案！

第二种方案：Fat executors (每个节点一个Executor)：

Fat executors表示一个executor独占一个节点。下表描述了该方案下的参数配置：

- `--num-executors` = `该方案下，一个executor独占一个节点`= `集群中的节点的数目`= 10
- `--executor-cores` = `一个节点一个executor意味着每个executor独占节点中所 有的cores`= `节点中的core的数目`= 16
- `--executor-memory` = `每个executor的内存`= `节点的内存/节点中executor的数目`= 64GB/1 = 64GB

分析：每个executor独占16个核心，则ApplicationManager和守护程序进程则无法分配到core，并且，HDFS吞吐量会受到影响，导致过多的垃圾结果。同样地，该方案不好！

第三种方案：Balance between Fat (vs) Tiny

根据上面讨论的建议：

基于上述的建议，我们给每个executor分配5个core => -- executor-cores = 5 (保证良好的HDFS吞吐)
每个节点留一个core给Hadoop/Yarn守护进程 => 每个节点可用的core的数目 = 16 - 1
所以，集群中总共可用的core的数目是 15 * 10 = 150
可用的executor的数目 = （总的可用的core的数目 / 每个executor的core的数目）= 150 / 5 = 30
留一个executor给ApplicationManager => --num-executors = 29
每个节点的executor的数目 = 30 / 10 = 3
每个executor的内存 = 64GB / 3 = 21GB
计算堆开销 = 7% * 21GB = 3GB。因此，实际的 --executor-memory = 21 - 3 = 18GB

因此，推荐的配置如下：29 executors, 18GB memory each and 5 cores

each ！
分析：很明显，第三种方案在Fat vs Tiny 两种方案中找到了合适的平衡点。毋庸置疑，它实现了Fat executor的并行性和Tiny executor的最佳吞吐量！

结论：

我们看到：

当为spark程序配置运行参数的时候，应谨记一些推荐事项：
1.为Yarn的Application Manager预留资源
2.我们应该如何为Hadoop / Yarn / OS deamon进程节省一些cores
3.学习关于spark-yarn-memory-usage
另外，检查并分析了配置这些参数的三种不同方法：
1.Tiny Executors - 每个executor配置一个core
2.Fat Executors - 每个executor独占一个节点
3.推荐方案 - 基于建议项的Tiny（Vs）Fat的合适的平衡。

--num-executors, --executor-cores and --executor-memory..这三个参数在spark性能中扮演很重要的角色，他们控制这你的spark程序获得的CPU和内存的资源。对于用户来说，很有必要理解如何去配置它们。希望这篇博客对你有帮助。

---------------------------------------------分割线---------------------------------------------------

本人实践中的一些看法：

在推荐方案 - 基于建议项的Tiny（Vs）Fat的合适的平衡中，理论其实跟实际的企业环境也是有出入的，也许对于整个集群如果只有单个任务在跑，可能推荐方案是最优的选择，但实际上还需要跟现实情况再做个妥协，比如整个集群其实不关是你一个人的业务在跑，其他业务线的业务也都在集群上跑，而遵循局部最优的做法，反而会上整个集群的吞吐量变得不高（毕竟每个executor申请这么大内存，又按整个集群去申请，吃不消啊，别的业务申请不到资源），因此实际操作的时候，可能每个executor的核心数需要缩水，比如是2-3核，内存也会适当的按比例进行缩水。