本篇文章将以问答的方式对Executor的启动进行分析。
新app的加入和集群资源的变动将调用到Master的schedule方法, 这个时候会进行startExecutorsOnWorkers()进行executor的调度和启动。 (资源申请的是在 appclient 的 registerApplication 消息中)
--executor-cores
为 Executor 指定了 cores 的时候,
一个 worker 可以启动多个 Executor,
否则一个 worker 只会为 app 启动一个 executor,
但是会为这个 executor 尽可能多的分配 cpu cores。(理解为全部的core也是没错的)首先会寻找可用的 Worker 节点来启动 Executor , 所谓可用就是前面提到的 Executor在worker上启动的条件
Worker 节点资源分配是按照如下规则进行的:
--executor-cores
,
以及内存,即你指定的--executor-memory
,spark.deploy.spreadOut
指定为true
,在进行一次分配后将继续分配下一个可用的work。
否则,会继续在该 work 上进行资源分配,直到该work资源全部分配完。
才会继续去寻找下一个可用work1 到 3
.直到满足该任务需要的资源,或者集群资源消耗完。在某一集群中有4 个 Worker 节点,每个节点拥有16个 CPU 核数,
其中设置了 spark.cores.max = 48
和 spark.executor.cores = 16
,
如果spark.deploy.spreadOut = true
,按照每次分配 1 个CPU 核数,
则每个 Worker 节点的 Executor 将分配到 12 个 CPU 核数,
就达到了应用限制的最大核数48,
但却没有满足executor启动的最小cores 16,
所以将没有 Executor 能够启动,参见 SPARK -8881问题说明。
而在后续版本中,每次分配 CPU 核数为 Executor 指定的 CPU 核数,
如果没有指定默认情况为1,这样在前面的例子中,
按照该分配方式将在3 个 Worker 节点中的 Executor 分配16个 CPU 核数,
这样就能够正常启动 Executor 。
通过以上几个问题,大概也能了解到 executor 在worker端启动的整个流程了, 本文主要是从源码角度挖掘的信息,如有不对的地方,麻烦指出,谢谢!