使用 Amazon 的“maximizeResourceAllocation”设置的 Spark + EMR 不使用所有核心/vcore答案

【问题标题】：Spark + EMR using Amazon's "maximizeResourceAllocation" setting does not use all cores/vcores使用 Amazon 的“maximizeResourceAllocation”设置的 Spark + EMR 不使用所有核心/vcore
【发布时间】：2016-03-04 09:26:19
【问题描述】：

我正在使用 Amazon 特定的 maximizeResourceAllocation 标志为 Spark 运行 EMR 集群（版本 emr-4.2.0），如记录的 here 所示。根据这些文档，“此选项计算核心节点组中节点上的执行程序可用的最大计算和内存资源，并使用此信息设置相应的 spark-defaults 设置”。

我正在使用工作节点的 m3.2xlarge 实例运行集群。我正在为 YARN 主服务器使用单个 m3.xlarge - 我可以让它运行的最小 m3 实例，因为它没有太多作用。

情况是这样的：当我运行 Spark 作业时，每个执行程序请求的内核数为 8。（我在配置 "yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator" 后才得到这个，这实际上不在文档中，但我离题了）。这似乎是有道理的，因为根据these docs，一个 m3.2xlarge 有 8 个“vCPU”。但是，在实际实例本身上，在/etc/hadoop/conf/yarn-site.xml 中，每个节点都配置为将yarn.nodemanager.resource.cpu-vcores 设置为16。我会（猜测）认为这一定是由于超线程或其他一些硬件的幻想。

所以问题是这样的：当我使用 maximizeResourceAllocation 时，我得到了 Amazon Instance 类型具有的“vCPU”数量，这似乎只是 YARN 运行的已配置“VCore”数量的一半节点；结果，执行程序只使用了实例上实际计算资源的一半。

这是 Amazon EMR 中的错误吗？其他人是否遇到同样的问题？我还缺少其他一些神奇的无证配置吗？

【问题讨论】：

标签： apache-spark hadoop-yarn emr amazon-emr elastic-map-reduce

【解决方案1】：

使用此设置，您应该在每个实例（主实例除外）上获得 1 个执行程序，每个实例有 8 个内核和大约 30GB 的 RAM。

http://:8088/ 上的 Spark UI 是否没有显示该分配？

与该页面上提到的另一个设置“启用执行器的动态分配”相比，我不确定该设置是否真的很有价值。这将让 Spark 管理它自己的作业实例数量，如果您启动具有 2 个 CPU 内核和每个执行程序 3G RAM 的任务，您将获得相当好的 EMR 实例大小的 CPU 与内存比率。

【讨论】：

它确实表明了这一点；但问题是那些“8”核实际上只是 YARN 分配的 16 个“VCore”中的 8 个；机器上一半的实际 CPU 资源处于空闲状态。由于我正在尝试运行 CPU 密集型作业，因此这是对 CPU 的浪费（显然还有钱！）
核心只是实例类型本身的抽象。内核没有实际的绑定，因此无论应用程序请求多少 CPU，执行程序都会使用。将 DominantResourceCalculator 用于调度程序时，唯一的绑定出现。需要注意的一点是，对于这种实例类型 EMR 默认配置，将告诉 yarn 的 vcore 值加倍，以帮助提高 MapReduce 的 CPU 利用率。 MaximizeResourceAllocation 正在查看实例类型核心定义。

【解决方案2】：

好的，经过大量实验，我能够找到问题所在。我将在这里报告我的发现，以帮助人们避免将来感到沮丧。

虽然请求的 8 个内核与 YARN 知道的 16 个 VCore 之间存在差异，但这似乎没有什么区别。 YARN 没有使用 cgroups 或任何花哨的东西来实际限制执行程序实际可以使用的 CPU 数量。
executor 上的“Cores”实际上有点用词不当。它实际上是执行者在任何时候愿意运行多少并发任务；本质上归结为每个执行程序上有多少线程在“工作”。
当设置maximizeResourceAllocation 时，当您运行 Spark 程序时，它会将属性spark.default.parallelism 设置为集群中所有非主实例的实例核心数（或“vCPU”）在创建时。即使在正常情况下，这也可能太小了；我听说建议将其设置为运行作业所需内核数的 4 倍。这将有助于确保在任何给定阶段都有足够的任务可用，以使所有执行程序的 CPU 保持忙碌。
当您拥有来自不同 Spark 程序的不同运行的数据时，您的数据（RDD 或 Parquet 格式或其他格式）很可能以不同数量的分区保存。运行 Spark 程序时，请确保在加载时或在执行特别 CPU 密集型任务之前重新分区数据。由于您可以在运行时访问 spark.default.parallelism 设置，因此可以方便地重新分区。

TL;DR

maximizeResourceAllocation 会为你做几乎所有事情，除了...
您可能希望将spark.default.parallelism 显式设置为您希望作业在每个“步骤”（EMR 语言）/“应用程序”（YARN 语言）基础上运行的实例核心数的 4 倍，即 每次都设置然后...
确保在您的程序中您的数据已适当分区（即需要多个分区）以允许 Spark 正确并行化它

【讨论】：

我要补充一点，在这里也可以使用 Spark 的动态资源计算 (docs.aws.amazon.com/ElasticMapReduce/latest/ReleaseGuide/…)。此外，用户可以为实例类型增加 vcore，以实现每个执行程序的每个任务与实际 CPU 使用率的良好平衡。
在 EMR 5.x 中，maximizeResourceAllocation 将 spark.default.parallelism 设置为可用 CPU 内核总数的两倍 emr-spark-maximizeresourceallocation
@retnuH 您能否举一个示例：“您希望作业在每个“步骤”（在 EMR 中）/“应用程序”（在 YARN 中）基础上运行的实例核心数为 4 倍“？我不明白这到底是什么意思。
@lightbox142 我已经很久没有接触过这个了，所以事情已经过时了，但大致来说，从原始帖子中的（相当旧的）信息继续 - 说我想要一份工作使用 4 个 m3.2xlarge 上的所有内核——每个内核都有 8 个“vCPU”——即 32 个内核/vCPU——我想在每个作业中将 spark.default.parallelism 设置为 128 (32 x 4)。我还要确保我的程序在适当的点重新分区数据，以便有至少 128 个分区可以处理。但这可能不再需要，这是在 EMR 4.2.0 上，在 5.x+ 中可能没问题，请参阅上面@donghyun208 的评论。
@retnuH 谢谢！你建议如何设置spark.sql.shuffle.partitions？您是否建议将spark.sql.shuffle.partitions 设置为与spark.default.parallelism 相同的值？

【解决方案3】：

在 EMR 版本 3.x 中，此 MaximizeResourceAllocation 是通过引用表实现的：https://github.com/awslabs/emr-bootstrap-actions/blob/master/spark/vcorereference.tsv

它被一个shell脚本使用：maximize-spark-default-config，在同一个repo中，你可以看看他们是如何实现的。

也许在新的 EMR 版本 4 中，这个参考表有些错误......我相信你可以在你的 EMR 的 EC2 实例中找到所有这些 AWS 脚本，应该位于 /usr/lib/spark 或 /opt/aws 或类似的东西。

无论如何，至少，您可以在 EMR 4 中为此编写自己的 bootstrap action 脚本，并使用正确的引用表，类似于 EMR 3.x 中的实现

此外，由于我们将使用 STUPS 基础架构，因此值得一看 STUPS 设备 for Spark：https://github.com/zalando/spark-appliance

您可以在部署 Spark 集群时通过设置 senza 参数 DefaultCores 来明确指定核心数

与 EMR 相比，此设备的一些亮点是：

甚至可以将它与 t2 实例类型一起使用，可根据其他 STUPS 设备等角色自动扩展。

并且你可以很容易地在使用zookeeper的HA模式下部署你的集群，所以master节点上没有SPOF，目前EMR中的HA模式仍然是不可能的，我相信EMR主要是为“大型临时集群用于临时分析作业”，而不是“永久开启的专用集群”，因此使用 EMR 将无法使用 HA 模式。

【讨论】：