我正在构建一个将在Dataproc上运行的spark应用程序。我计划使用临时集群，并为应用程序的每次执行增加一个新集群。因此，我基本上希望我的工作尽可能多地消耗集群资源，并且我对要求有很好的了解。
我一直在尝试关闭动态分配，并自行设置执行程序实例和核心。目前，我正在使用6个实例和30个核心。
也许这更像是一个毛线问题，但是我发现容器vCores和我的spark executor内核之间的关系有些混乱。在YARN应用程序管理器UI中，我看到产生了7个容器（1个驱动程序和6个执行程序），每个容器使用1个vCore。但是，在spark中，我看到执行程序本身正在使用我指定的30个内核。
所以我很好奇执行者是否试图在本质上是1个核心盒子上并行执行30个任务。还是AM gui中显示的vCore是错误的？
如果是前者，则想知道设置此应用程序的最佳方法是什么，因此我最终在每个工作节点上只有一个执行程序，并且使用了所有CPU。
答案 0 :(得分：1)
在YARN GUI中显示的vCore是错误的；这是一个记录不充分的文件，但是capacity-scheduler的一个已知问题，这是Dataproc的默认问题。值得注意的是，使用Dataproc的默认设置，YARN仅基于内存而不是CPU进行资源箱打包。好处是，此功能对于按工作量按期望的程度超额预订CPU（尤其是在受IO约束的情况下）不同程度的用途更广泛，但是缺点是YARN不会以固定的方式减少CPU的使用量。
有关更改为fair-scheduler的讨论，请参见https://stackoverflow.com/a/43302303/3777211，以查看YARN中准确表示的vcore分配。但是，对于您而言，这样做可能没有任何好处。使YARN在两个维度上都进行装箱打包更多是“共享多租户群集”问题，只会使调度问题复杂化。
对于您来说，设置应用程序的最佳方法就是忽略YARN关于vcore的说法；如果每个工作节点只需要一个执行者，则将执行者的内存大小设置为每个节点的YARN中可以容纳的最大值，并使每个执行者的核心数等于每个节点的核心总数。