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 性能上起到相当重要的做用。让用户理解配置的正确方法是相当重要的。但愿这篇博客可以帮助你了解这些。