我正在使用特定于亚马逊的maximizeResourceAllocation标记运行适用于Spark的EMR集群（版本emr-4.2.0）here。根据这些文档，＆＃34;此选项计算核心节点组中节点上执行程序可用的最大计算和内存资源，并使用此信息设置相应的spark-defaults设置＆＃34;。
我使用m3.2xlarge实例为工作节点运行集群。我使用单个m3.xlarge作为YARN master - 我可以运行的最小的m3实例，因为它没有做太多。
情况是这样的：当我运行Spark作业时，每个执行程序请求的核心数是8.（我只是在配置"yarn.scheduler.capacity.resource-calculator": "org.apache.hadoop.yarn.util.resource.DominantResourceCalculator"之后才得到这个，但实际上并不是在文档中，但是我离题了）。这似乎是有道理的，因为根据these docs m3.2xlarge有8＆＃34; vCPU＆＃34;。但是，对于实际实例本身，在/etc/hadoop/conf/yarn-site.xml中，每个节点都配置为将yarn.nodemanager.resource.cpu-vcores设置为16。我（猜测）认为这必定是因为超线程或者其他一些硬件的原因。
所以问题是这样的：当我使用maximizeResourceAllocation时，我得到了＆＃34; vCPU＆＃34;亚马逊实例类型具有的，这似乎只是配置的＆＃34; VCores＆＃34;的数量的一半。 YARN已在节点上运行;因此，执行程序仅使用实例上实际计算资源的一半。
这是Amazon EMR中的错误吗？其他人是否遇到同样的问题？是否还有一些我缺少的其他魔法无证配置？
答案 0 :(得分：36)
好的，经过大量的实验，我能够找到问题所在。我将在这里报告我的发现，以帮助人们避免将来感到沮丧。
maximizeResourceAllocation时，运行Spark程序时，会将属性spark.default.parallelism设置为所有非主实例的实例核心数（或“vCPU”）。在创建时的群集中。即使在正常情况下，这可能太小了;我听说建议将此值设置为运行作业所需的核心数的4倍。这将有助于确保在任何给定阶段有足够的任务可以保持CPU在所有执行器上忙碌。spark.default.parallelism设置，因此这可以是一个方便的号码来重新分配。<强> TL; DR
maximizeResourceAllocation几乎可以为你做任何事情，除了...... spark.default.parallelism显式设置为您想要在每个“步骤”（在EMR中说话）/“应用程序”（在YARN中说话）的基础上运行作业的4x实例核心数，即每次都设置和... 答案 1 :(得分：2)
使用此设置，每个实例（主设备除外）应该有1个执行程序，每个实例有8个内核和大约30GB的RAM。
Spark UI是否为http：//：8088 /未显示该分配？
我不确定与该页面上提到的另一个“启用执行程序的动态分配”相比，该设置确实很有价值。这将让Spark管理它自己的工作实例数量，如果你为每个执行器启动一个具有2个CPU内核和3G RAM的任务，那么对于EMR的实例大小，你将获得相当高的CPU与内存比率。
答案 2 :(得分：0)
它由shell脚本使用：maximize-spark-default-config，在同一个仓库中，您可以看看它们是如何实现的。
也许在新的EMR版本4中，这个参考表在某种程度上是错误的......我相信你可以在EMR的EC2实例中找到所有这个AWS脚本，应该位于 / usr / lib / spark < / em>或 / opt / aws 或类似的东西。
无论如何，至少，您可以在EMR 4中为此编写自己的bootstrap action脚本，并使用正确的参考表，类似于EMR 3.x中的实现
此外，由于我们将使用 STUPS 基础架构，值得一看 STUPS设备的Spark ：https://github.com/zalando/spark-appliance
您可以在部署spark群集时通过设置senza参数DefaultCores来明确指定核心数
与EMR相比，此设备的一些亮点是：
能够使用甚至t2实例类型，基于其他STUPS设备等角色自动扩展等。
您可以使用zookeeper 在 HA模式下轻松部署群集，因此主节点上没有SPOF，EMR中的HA模式目前仍然无法实现，我相信EMR主要是为“大型”设计的临时用于临时分析作业的集群“，而不是”永久打开的专用集群“，因此在EMR附近将无法实现HA模式。