例如，我目前有一个 DataProc 集群，由一个 master 和 4 个 worker 组成，每台机器有 8 个 vCPU 和 30GB 内存。
每当我向集群提交作业时，集群总共最多提交 11GB，并且只使用 2 个工作节点来完成工作，并且在这些节点上只使用 2 个 vCPU 资源。这使得原本应该只需要几分钟的工作需要近一个小时才能执行。
我尝试在主节点上编辑spark-defaults.conf 文件，并尝试使用参数--executor-cores 4 --executor-memory 20g --num-executors 4 运行我的spark-submit 命令，但都没有任何效果。
这些集群只会被启动以执行单个任务，然后会被拆除，因此不需要为任何其他作业保留资源。
【问题讨论】：
标签： apache-spark google-cloud-platform google-cloud-dataproc
我设法通过在create 命令末尾使用以下内容将调度程序更改为FIFO 而不是FAIR 来解决我的问题：
--properties spark:spark.scheduler.mode=FIFO
【讨论】：
您可能想看看您正在查看的内容是否与 Dataproc set number of vcores per executor container 相关 - YARN 报告的正在使用的 vcore 数量已知不正确，但这只是外观缺陷。在具有 8 核机器的 Dataproc 集群上，默认配置已经为每个执行程序设置了 4 个内核；如果您通过 YARN 单击到 Spark 应用程序管理员，您应该会看到 Spark 确实能够为每个执行程序打包 4 个并发任务。
这部分解释了每个节点“仅使用 2 个 vCPU”的情况。
该作业仅涉及两个工作节点这一事实暗示了它还有更多内容；您获得的并行度与how well the data is partitioned 有关。如果您有无法拆分的 gzip 文件等输入文件，那么不幸的是，没有一种简单的方法可以增加输入并行度。但是，至少在后续管道阶段或者如果您确实有可拆分文件，您可以通过在读取时指定 Spark 分区的数量或在代码中调用 repartition 来增加并行度。根据您的输入大小，您还可以尝试减小fs.gs.block.size；默认为134217728 (128MB)，但您可以通过在集群创建时设置为一半或四分之一或其他值：
--properties core:fs.gs.block.size=67108864
或在作业提交时：
--properties spark.hadoop.fs.gs.block.size=67108864
【讨论】：