spark on yarn container分配极端倾斜

环境：CDH5.13.3  spark2.3

在提交任务之后，发现executor运行少量几台nodemanager，而其他nodemanager没有executor分配。

测试环境通过spark-shell模拟如下：

第一次尝试分配6个exeutor,具体如下

spark2-shell \
--driver-memory 1G \
--executor-memory 2G \
--num-executors 6 \
--executor-cores 3

结果：container全部分布在同一个节点上，其他节点没有。

第二次尝试分配20个executor，具体如下

spark2-shell \
--driver-memory 1G \
--executor-memory 2G \
--num-executors 20 \
--executor-cores 3

结果：container分布在其中两个节点上，其中一个节点上有11个，另外一个有9个。

spark on yarn实际的资源调度是由yarn来实现的，与standalone不同，目前环境yarn调度策略为公平调度，即FairScheduler，而这种情况是由公平调度中的一个参数有关：

<property>
<name>yarn.scheduler.fair.assignmultiple</name>
<value>true</value>
<discription>whether to allow multiple container assignments in one heratbeat defaults to false</discription>
</property>
在一次心跳请求中，是否分配多个container,CDH5.13.3默认设置为true。原生hadoop默认是false

<property>
<name>yarn.scheduler.fair.max.assign</name>
<value>-1</value>
</property>
如果上面设置的允许一次分配多个container,那么最多分配多少个，默认无限制。根据实际资源情况

将yarn.scheduler.fair.assignmultiple设置为false，再测试如下：

spark2-shell \
--driver-memory 1G \
--executor-memory 2G \
--num-executors 6 \
--executor-cores 3

如果在生产环境下，spark任务的executor数量和内存都相对要高很多，所以这种情况会相对有所缓解，具体根据实际情况确定是否需要调整。

---

Yarn 的三种资源分配方式

FIFO Scheduler

如果没有配置策略的话，所有的任务都提交到一个 default 队列，根据它们的提交顺序执行。富裕资源就执行任务，若资源不富裕就等待前面的任务执行完毕后释放资源，这就是 FIFO Scheduler 先入先出的分配方式。

如图所示，在 Job1 提交时占用了所有的资源，不久后 Job2提交了，但是此时系统中已经没有资源可以分配给它了。加入 Job1 是一个大任务，那么 Job2 就只能等待一段很长的时间才能获得执行的资源。所以先入先出的分配方式存在一个问题就是大任务会占用很多资源，造成后面的小任务等待时间太长而饿死，因此一般不使用这个默认配置。

Capacity Scheduler

Capacity Scheduler 是一种多租户、弹性的分配方式。每个租户一个队列，每个队列可以配置能使用的资源上限与下限（譬如 50%，达到这个上限后即使其他的资源空置着，也不可使用），通过配置可以令队列至少有资源下限配置的资源可使用

图中队列 A 和队列 B 分配了相互独立的资源。Job1 提交给队列 A 执行，它只能使用队列 A 的资源。接着 Job2 提交给了队列B 就不必等待 Job1 释放资源了。这样就可以将大任务和小任务分配在两个队列中，这两个队列的资源相互独立，就不会造成小任务饿死的情况了。

Fair Scheduler

Fair Scheduler 是一种公平的分配方式，所谓的公平就是集群会尽可能地按配置的比例分配资源给队列。

图中 Job1 提交给队列 A，它占用了集群的所有资源。接着 Job2 提交给了队列 B，这时 Job1 就需要释放它的一半的资源给队列 A 中的 Job2 使用。接着 Job3 也提交给了队列 B，这个时候 Job2 如果还未执行完毕的话也必须释放一半的资源给 Job3。这就是公平的分配方式，在队列范围内所有任务享用到的资源都是均分的。