EMR-5.32.0 上的 Spark 不产生请求的执行程序

thi*_*vdp 4 configuration amazon-emr apache-spark pyspark spark-submit

我在 EMR(版本 5.32.0)上的 (Py)Spark 中遇到了一些问题。大约一年前,我在 EMR 集群上运行了相同的程序(我认为该版本一定是 5.29.0)。然后我能够spark-submit正确地使用参数配置我的 PySpark 程序。但是,现在我正在运行相同/相似的代码,但spark-submit参数似乎没有任何效果。

我的集群配置:

  • 主节点:8 vCore,32 GiB 内存,仅 EBS 存储 EBS 存储:128 GiB
  • 从节点:10 x 16 vCore,64 GiB 内存,仅 EBS 存储 EBS 存储:256 GiB

我使用以下spark-submit参数运行程序:

spark-submit --master yarn --conf "spark.executor.cores=3" --conf "spark.executor.instances=40" --conf "spark.executor.memory=8g" --conf "spark.driver.memory=8g" --conf "spark.driver.maxResultSize=8g" --conf "spark.dynamicAllocation.enabled=false" --conf "spark.default.parallelism=480" update_from_text_context.py
Run Code Online (Sandbox Code Playgroud)

我没有更改集群上的默认配置中的任何内容。

在 Spark UI 的屏幕截图下方,它仅指示 10 个执行程序,而我希望有 40 个执行程序可用...

在此处输入图片说明

我尝试了不同的spark-submit参数以确保错误与Apache Spark无关:设置 executor 实例不会更改 executors。我尝试了很多东西,似乎没有任何帮助。

我在这里有点迷茫,有人可以帮忙吗?

更新: 我在 EMR 版本标签 5.29.0 上运行了相同的代码,spark-submit参数中的 conf 设置似乎有效:

在此处输入图片说明

为什么会这样?

Jon*_*lly 5

很抱歉造成混乱,但这是故意的。在 emr-5.32.0 上,Spark+YARN 会将落在同一节点上的多个执行器请求合并到一个更大的执行器容器中。请注意,即使您的 executor 比您预期的要少,它们中的每一个都有更多您指定的内存和内核。(不过,这里有一个星号,我将在下面解释。)

此功能旨在在大多数情况下默认提供更好的性能。如果您真的希望保留以前的行为,您可以通过设置 spark.yarn.heterogeneousExecutors.enabled=false 来禁用此新功能,尽管我们(我在 EMR 团队中)想听听您为什么会出现以前的行为是可取的。

但是,对我来说没有意义的一件事是,您最终应该拥有与没有此功能时相同的执行程序内核总数,但是对于您共享的示例似乎没有发生这种情况. 您要求 40 个执行器,每个执行器具有 3 个核心,但随后得到了 10 个执行器,每个执行器具有 15 个核心,这总数多一点。这可能与您请求的 8g spark.executor.memory 划分为您选择的实例类型的可用内存的方式有关,我猜这可能是 m5.4xlarge。可以帮助您的一件事是删除 spark.executor.memory/cores/instances 的所有覆盖并仅使用默认值。我们希望默认设置在大多数情况下都能提供最佳性能。如果没有,就像我上面说的,请告诉我们,以便我们进一步改进!


thi*_*vdp 0

好的,如果有人面临同样的问题。作为解决方法,您可以恢复到之前版本的 EMR。在我的示例中,我恢复到 EMR 版本标签 5.29.0,这解决了我的所有问题。突然我能够再次配置 Spark 作业了!

我仍然不确定为什么它在 EMR 发行标签 5.32.0 中不起作用。因此,如果有人有建议,请告诉我!