本文基于Spark2.1.0版本
我們知道，使用yarn作為cluster manager時，spark（以client模式為例）用spark-submit提交應用程序（或者是spark-shell交互操作）不加任何資源參數時，會使用如下幾個默認配置來向yarn的resourcemanager申請container資源：
spark.executor.memory ? ? 1g
spark.executor.cores ? ? ? ? ?1
spark.executor.instances ? 2
spark.yarn.am.memory ? ? ?512m
spark.yarn.am.cores ? ? ? ? ? 1
按照參數的默認值，yarn將會生成3個containers，第一個是container0，用來執行applicationmaster功能，另外兩個container，就是分配給spark程序的CoarseGrainedExecutorBackend.
結合上面這些默認值，我們認為將會占用集群的3個vcores，3.5G memory。
看下圖(yarn web ui)，第一個問題來了，為什么memory使用的數量不是想象中的3.5g呢？
原來，yarn對于應用程序所要申請的內存資源，有兩個參數來影響實際申請到內存容量：
第一個是yarn.scheduler.minimum-allocation-mb：最小可申請內存量，默認是1024。
第二個是規整化因子（FIFO和Capacity Scheduler時，規整化因子等于最小可申請資源量，不可單獨配置；Fair Scheduler時，規整化因子通過參數yarn.scheduler.increment-allocation-mb設置，默認是1024），其作用是應用程序申請的資源如果不是該因子的整數倍，則將被修改為最小的整數倍對應的值。
由于每個容器都會占用一些額外的內存，所以導致CoarseGrainedExecutorBackend的每個容器實際使用的內存數 > 申請的1G，在規整化因子的作用下，這些容器實際申請的內存，就會是2G；而applicationmaster所在的容器，因為申請內存不到1G，則在最小可申請內存的作用下，實際申請的內存就會是1G。
這下申請的內存數就和圖中的對上號了吧（5G）！
ok，繼續往下說。
如果使用默認的2個executor，且每個executor只有1個vcore，畢竟執行任務的并發性太差。我們可以給每個executor多分配幾個vcore來提高并發性。在提交應用程序時，增加 --executor-cores 4 配置。
那么，問題來了，為什么vcore的顯示的不是我們配置的9呢（4+4+1）？依然是3，難道沒有生效嗎？
其實使用spark的driver ui觀察，這里面的顯示是準確的，說明我們想給每個executor使用4個core是生效了的。
可為什么yarn的web ui顯示的不準確呢？
通過查資料發現，因為我們的capacity schedule使用的是DefaultResourceCalculator，那么DefaultResourceCalculator它在加載Container時其實僅僅只會考慮內存而不考慮cores。將capacity-scheduler.xml中的：
yarn.scheduler.capacity.resource-calculator
org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator
修改為：
yarn.scheduler.capacity.resource-calculator
org.apache.hadoop.yarn.util.resource.DominantResourceCalculator
（請注意每個節點的配置文件都需要修改，并且重啟hadoop）
這時再提交spark應用程序，發現申請的vcores 的數目就對了吧（4+4+1）。
歡迎指正，轉載請標明作者和出處，謝謝。
