![](/img/trans.png)
[英]How do I enable Snappy codec support in a Spark cluster launched with Google Cloud Dataproc?
[英]How do I get a spark job to use all available resources on a Google Cloud DataProc cluster?
例如,我目前有一个DataProc集群,由一个主服务器和4个工作器组成,每台机器有8个vCPU和30GB内存。
每当我向集群提交作业时,集群总共最多承诺11GB,并且仅使用2个工作节点来完成工作,并且在这些节点上仅使用2个vCPU资源。 这使得一项只需几分钟的工作需要花费近一个小时才能完成。
我已经尝试在主节点上编辑spark-defaults.conf
文件,并尝试使用参数运行我的spark-submit
命令--executor-cores 4 --executor-memory 20g --num-executors 4
但是都没有任何影响。
这些集群只会被分离以执行单个任务,然后将被拆除,因此不需要为任何其他作业保留资源。
我设法通过将调度程序更改为FIFO
而不是FAIR
来解决我的问题,使用下面的create
命令结束:
--properties spark:spark.scheduler.mode=FIFO
您可能想知道您所查看的内容是否与Dataproc设置的每个执行器容器的vcores数量相关 - 已知YARN报告的使用中的vcores数量不正确,但它只是一个外观缺陷。 在具有8核计算机的Dataproc群集上,默认配置已经为每个执行程序设置了4个核心; 如果你点击YARN到Spark appmaster,你会发现Spark确实能够为每个执行程序打包4个并发任务。
该部分解释了每个节点可能看起来“仅使用2个vCPU”。
这个工作只涉及两个工作节点的事实暗示了它还有更多的东西; 您获得的并行度与数据分区的好坏程度有关。 如果您有像无法拆分的gzip文件这样的输入文件,那么遗憾的是,增加输入并行性并不是一种简单的方法。 但是,至少在以后的管道阶段或者如果你有可拆分文件,你可以增加并行性,在读取时指定Spark分区的数量,或者在代码中调用repartition
。 根据您的输入大小,您还可以尝试减少fs.gs.block.size
; 默认为134217728
(128MB),但您可以通过在群集创建时设置它来设置为其中一半或四分之一或其中的一半:
--properties core:fs.gs.block.size=67108864
或在工作提交时间:
--properties spark.hadoop.fs.gs.block.size=67108864
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.