在你的情况下,你可能想忽略该警告;它实际上只是一个无害的警告,你的驱动程序确实在同一个群集上正确排队;当多个驱动程序在同一个主机(dataproc主机)上运行时,端口只是bound to successive port numbers starting at 4040。请注意,这是而不是意思是后面的提交主动等待第一个完成;作业提交尝试尽可能多地同时运行资源。在Dataproc中,如果你提交了100个作业,你应该会看到其中的10个(根据机器大小,簇大小等而变化)立即在YARN中排队,其中几个(或全部)将成功获取足够多的YARN容器开始运行,而另一些容器则保持在YARN中。完成后,随着资源可用,Dataproc将逐渐递增剩余的90个工作给YARN。
目前有纱队列没有特殊的支持,但它如果你想在集群创建时间来定制你的YARN队列使用支持的功能:
gcloud dataproc clusters create --properties \
^;^yarn:yarn.scheduler.capacity.root.queues=foo,bar,default;spark:other.config=baz
(与;
更换gcloud delimiter穿过在教程概述像this one逗号分隔的列表)和/或附加yarn-site.xml
CONFIGS,然后您指定的队列:
gcloud dataproc jobs submit spark --properties spark.yarn.queue=foo
虽然不会改变你对端口4040警告的看法。这是因为默认设置是对Spark使用yarn-client
模式,这意味着驱动程序在主节点上运行,并且驱动程序提交不受YARN排队。
您可以使用yarn-cluster
模式如下:
gcloud dataproc jobs submit spark --properties \
spark.master=yarn-cluster,spark.yarn.queue=foo
然后,它会使用foo
纱队列,如果你定义它,以及使驱动程序在运行使用yarn-cluster
模式YARN容器。在这种情况下,您不再会遇到任何端口4040警告,但在yarn-cluster
模式下,您也无法再在Dataproc UI中看到驱动程序的stdout/stderr
。
谢谢你的解释。你介意在将来某个时候更新dataproc的文档吗? ;-) – Frank
http://spark.apache.org/docs/latest/job-scheduling.html#configuring-pool-properties - 我想我会尝试你的建议和游泳池配置一般到YARN。应该工作,但?! – Frank
它现在就像你自己描述的那样工作。非常感谢你。有没有办法从SparkContext /正在运行的作业中的dataproc获取jobId?我想保存结果以引用ApplicationId和JobId来涵盖YARN和dataproc上下文。 – Frank