apache-spark - 使用 Amazon 的 "maximizeResourceAllocation"设置的 Spark + EMR 不使用所有核心/vcore

Question

我正在使用 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 在节点上运行的已配置“VCores”数量的一半；结果，执行程序仅使用实例上实际计算资源的一半。

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

Answer 1

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

虽然要求的 8 个内核与 YARN 知道的 16 个 VCore 之间存在差异，但这似乎并没有什么区别。 YARN 没有使用 cgroups 或任何花哨的东西来实际限制执行程序实际可以使用的 CPU 数量。

执行器上的“核心”实际上有点用词不当。它实际上是执行者在任何时候愿意运行多少并发任务；本质上归结为每个执行程序上有多少线程在做“工作”。

当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 正确并行化它