環境：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。這就是公平的分配方式，在隊列范圍內所有任務享用到的資源都是均分的。