Spark on Yarn 执行单元数、内存、CPU 数的推荐分
是否曾经有过疑问：--num-executors, --executor-memory and --execuor-cores 这些参数该如何配置？
让我们看一些建议以便能够更好的理解
亲自动手，用一些示例集群来推到合适的参数
理论先行
以下是一些配置时的建议内容：
Hadoop/Yarn/OS 守护进程：当我们在 Yarn 一类的集群管理器中运行 Spark 应用时，后台会伴随着守护进程的运行，比如：NameNode，Secondary NameNode，DataNode，JobTracker，以及 TaskTracker。因而，当指定 num-executors 时，我们需要保证留有足够的 CPU 核树（每个节点 1 核）以确保这些守护进程能够顺利运行。
Yarn ApplicationMaster (AM)：ApplicationMaster 会从 ResourceManager 那里申请资源，并通过 NodeManager 执行并监控 Container 及其中的资源消耗。如果在 Yarn 中启动应用，我们需要为 AM 流出所需的资源（ 大约 1024MB 的内存以及 1 个 Executor ）
HDFS 吞吐：HDFS 客户端应对大量的并发线程性能不佳。据观察，当达到每个执行单元 5 个任务时，HDFS 会达到上限的吞吐量。因而，最好保证每个 Executor 的核数低于这个值。
内存开销：下图描述了 Spark on Yarn 的内存占用情况：
从上图中，我们需要注意两件事：
每个 Executor 所申请的内存 = spark-executor-memory + spark.yarn.executor.memoryOverhead
spark.yarn.executor.memoryOverhead = Max( 384MB, 7% * spark.executor-memory )
也就是说，如果我们为每个 Executor 申请 20GB内存，AM 实际上将会申请 20GB + memoryOverhead = 20 + 20 * 7% ~= 23GB。
Executor 中含有过多内存通常会导致过度的 GC 延迟;
Thiy Executor（ 仅含有单核，以及仅仅足够单个 task 运行所需的内存 ）会失去在单个 JVM 中运行多个任务的优势。
动手实践
现在，假设我们有 10 个服务器节点，他们的配置如下：
**服务器配置**节点数：10单个节点核数：16单个节点内存：64GB
让我们考虑一下不同的参数配置：
方法一：Tiny Executor（ 每个 Executor 单核 ）
Tiny Executor 意味着每个 Executor 仅有一个核。下表在这一情况下的参数配置：
- --num-executors = 节点总核数 = 单个节点核数 * 集群的节点个数 = 16 x 10 = 160- --executor-cores = 1 ( 每个 executor 单核 )- --executor-memory = 每个 Executor 的内存数 = 每个节点的内存数 / 每个节点的 Executor 数 = 64GB / 16 = 4GB
分析： 如上述，当每个 Executor 仅有一个核时，我们无法利用同一 JVM 运行多个 task 的优势。同样的，利用 broadcast和 accumulator 进行变量共享/缓存时，需要在每个节点的每个核中进行复制操作。此外，我们也没有为 Hadoop/Yarn 守护进程留有足够的内存资源。这种方法不好。
方法二：Fat Executor（ 每个节点一个 Executor ）
Fat Executor 意味着每个节点一个 Executor，下表展示了相应的 Spark 配置：
---num-executors = 集群节点数= 10---executor-cores = 单节点核数= 16---executor-memory = 单节点内存数 / 每个节点的 Executor 数= 64GB / 1 = 64GB
分析： 当每个 Executor 分配 16 核时，除了 AM 和守护进程没有考虑在内以外，HDFS 的吞吐将会受制，且将会导致国度的 GC。因为，这种方法不好。
方法三：Fat 和 Tiny 之间的平衡方案
根据我们之前的建议：
基于上述建议，让我们为每个 Executor 分配 5 核 => --executor-cores = 5 （ 为了更好地 HDFS 吞吐 ）
在每个节点中，为 Hadoop/Yarn 守护进程留出 1 核 => 单节点的可用核数 = 16 - 1 = 15
因而，总可用核数 = 15 * 10 = 150
可用的 executor 数 = （ 总核数 / 每个 executor 的核数 ）= 150 / 5 30
留出一个 Executor 用于 ApplicationMaster => --num-executors = 29
每个节点的 Executor 数 = 30 / 10 = 3
每个节点的内存数 = 64GB / 3 ~= 21 GB
计算额外开销 = 7% * 21 GB = 3 GB。因而，实际的 --executor-memory = 21 - 3 = 18 GB
因而，推荐的配置为：29 个 Executor，每个 Executor：18 GB 内存及 5 核。
分析：不难看出方法三是如何在 Fat 和 Tiny 之间保持平衡的。其保证了 Fat Executor 的并行度及 Tiny Executor 的吞吐量。
结论
如下：
在对 Spark 应用的配置时记住如下建议：
为 Yarn AM 预留所需的资源；
为 Hadoop/Yarn/OS 守护进程预留资源；
了解 Spark 内存利用模型
此外，分析三种参数配置方法：
Tiny Executors - 单核 Executor
Fat Executor - 每个节点对应一个 Executor
推荐的做法 - 按上述建议在 Fat 和 Tiny 之间保持平衡
--num-executors，--executor-cores and --executor-memory 这三个参数控制了 Spark 应用所能使用的 CPU 数量及内存数，在 Spark 性能上起到至关重要的作用。让用户理解配置的正确方法是至关重要的。希望这篇博客能够帮助你了解这些。
