Spark on Yarn 执行单元数、内存、CPU 数的推荐分配

本文翻译自：Managing Relations Inside Elasticsearch | Elastic

是否曾经有过疑问：--num-executors, --executor-memory and --execuor-cores 这些参数该如何配置？

1. 让我们看一些建议以便能够更好的理解
2. 亲自动手，用一些示例集群来推到合适的参数

理论先行

以下是一些配置时的建议内容：

• 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 的内存占用情况：

从上图中，我们需要注意两件事：

1. 每个 Executor 所申请的内存 = spark-executor-memory + spark.yarn.executor.memoryOverhead
2. 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 内存利用模型

此外，分析三种参数配置方法：

1. Tiny Executors - 单核 Executor
2. Fat Executor - 每个节点对应一个 Executor
3. 推荐的做法 - 按上述建议在 Fat 和 Tiny 之间保持平衡

--num-executors，--executor-cores and --executor-memory 这三个参数控制了 Spark 应用所能使用的 CPU 数量及内存数，在 Spark 性能上起到至关重要的作用。让用户理解配置的正确方法是至关重要的。希望这篇博客能够帮助你了解这些。