使用亚马逊的"maximizeResourceAllocation"设置的Spark + EMR不使用所有核心/ vcores

Question

我正在使用亚马逊的具体星火的EMR集群(版本EMR-4.2.0)maximizeResourceAllocation标志作为记录在这里.根据这些文档,"此选项计算核心节点组中节点上执行程序可用的最大计算和内存资源,并使用此信息设置相应的spark-defaults设置".

我正在使用m3.2xlarge实例为工作节点运行集群.我正在为YARN master使用一个m3.xlarge - 我可以运行它的最小m3实例,因为它没有做太多.

情况是这样的:当我运行Spark作业时,每个执行程序所请求的核心数是8.(我在配置之后才得到这个,"yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator"这实际上不在文档中,但我离题了).这似乎是有道理的,因为根据这些文档,m3.2xlarge有8个"vCPU".但是,在实际实例本身中/etc/hadoop/conf/yarn-site.xml,每个节点都配置为yarn.nodemanager.resource.cpu-vcores设置为16.我(猜测)认为这必定是因为超线程或者其他一些硬件的原因.

所以问题在于:当我使用时maximizeResourceAllocation,我获得了亚马逊实例类型具有的"vCPU"数量,这似乎只是YARN在节点上运行的已配置"VCores"数量的一半; 因此,执行程序仅使用实例上实际计算资源的一半.

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

Answer 1

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

• 虽然要求的8个核心和YARN知道的16个核心之间存在差异,但这似乎没有什么区别.YARN没有使用cgroup或任何花哨的东西来实际限制执行程序实际可以使用的CPU数量.
• 执行者的"核心"实际上有点用词不当.实际上,执行者在任何时候都愿意运行多少个并发任务; 实质上归结为每个执行器上有多少线程正在"工作".
• 当maximizeResourceAllocation被设定,当您运行星火计划,它设置属性spark.default.parallelism为实例内核(或"虚拟CPU"),为所有被集群中的非主实例的数量在创建时间. 即使在正常情况下,这可能太小了; 我听说建议将此值设置为运行作业所需的核心数的4倍.这将有助于确保在任何给定阶段有足够的任务可以使CPU在所有执行程序上保持忙碌状态.
• 当您拥有来自不同运行的不同火花程序的数据时,您的数据(以RDD或Parquet格式或其他形式)很可能会以不同数量的分区进行保存.运行Spark程序时,请确保在加载时或特别CPU密集型任务之前重新分区数据.由于您可以spark.default.parallelism在运行时访问该设置,因此这可以是一个方便的数字来重新分区.

TL; DR

1. maximizeResourceAllocation 除了......之外,几乎所有东西都能为你做好
2. 您可能希望spark.default.parallelism在每个"步骤"(在EMR中说话)/"应用程序"(在YARN中)基础上明确设置为您想要作业运行的4x实例核心数,即每次设置它 ...
3. 确保在程序中您的数据被适当地分区(即需要许多分区)以允许Spark正确地并行化它

Answer 2

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

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

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