动态调配：
OS（操作系统预留） 1 core 1G
core 并发能力 <=5
executor AM预留1个executor 余executor=总executor-1
memory 预留每个executor0.07比例
MemoryOverhead max(384M, 0.07 × spark.executor.memory)
ExecutorMemory (总m-1G(OS))/nodes_num-MemoryOverhead
例子1硬件资源： 6 节点，每个节点16 cores, 64 GB 内存
每个节点在计算资源时候，给操作系统和Hadoop的过程预留1core，1GB，所以每个节点剩下15个core和63GB
内存。
core的个数，决定一个executor可能并发工作的个数。所以通常认为，一个executor越多的并发工作可能失去更好的性能，但有钻研显示一个利用并发工作超过5，导致更差的性能。所以core的个数暂设置为5个。
5个core是表明executor并发工作的能力，并不是说一个零碎有多少个core，即便咱们一个CPU有32个core，也设置5个core不变。
executor个数，接下来，一个executor调配 5 core,一个node有15 core，从而咱们计算一个node上会有3 executor（15 / 5），而后通过每个node的executor个数失去整个工作能够调配的executors个数。
咱们有6个节点，每个节点3个executor，6 × 3 = 18个executors，额定预留1个executor给AM，最终要配置17个executors。
最初spark-submit启动脚本中配置 –num-executors = 17
memory，配置每个executor的内存，一个node，3 executor， 63G内存可用，所以每个executor可配置内存为63 / 3 = 21G
从Spark的内存模型角度，Executor占用的内存分为两局部：ExecutorMemory和MemoryOverhead，预留出MemoryOverhead的内存量之后，才是ExecutorMemory的内存。
MemoryOverhead的计算公式： max(384M, 0.07 × spark.executor.memory)
因而 MemoryOverhead值为0.07 × 21G = 1.47G > 384M
最终executor的内存配置值为 21G – 1.47 ≈ 19 GB
至此， Cores = 5, Executors= 17, Executor Memory = 19 GB
动态分配
如果采纳动态分配策略，executer的个数下限是无穷大。这就意味着Spark工作在须要资源的状况下，会占用到集群左右资源，集群中会有其余利用也须要资源运行，所以咱们须要在集群层面上对core进行调配管制。
这就意味着咱们在基于用户拜访根底上，在基于YARN的工作中进行调配core，咱们创立一个spark_user，调配min max的core个数，这些core从YARN中剥离，区别于其余基于YARN调度利用（例如Hadoop等）
为了了解动静资源分配，首先须要理解一些属性配置项：
spark.dynamicAllocation.enabled ： 设置为true，意味着咱们不关怀executor的个数，思考用到动静资源分配策略，在stage阶段会有一下区别：
以多少个executor启动Spark工作？
spark.dynamicAllocation.initialExecutors：初始化executor个数
怎么动态控制executor的个数？
咱们通过spark-submit的形式初始化executor个数，依据负载状况，工作在min(
spark.dynamicAllocation.minExecutors)和max(
spark.dynamicAllocation.maxExecutors)之间决定executor个数。
什么时候获取一个新的executor和放弃一个executor
spark.dynamicAllocation.schedulerBacklogTimeout ：依附这个参数，决定咱们什么时候获取一个新的executor，每轮工作executor个数较前一轮将逞指数增长，比方第一轮1个executor，后续增加2，4，8个executor的形式，在某些特定场景下，将应用max（spark.dynamicAllocation.maxExecutors）个executor。
spark.dynamicAllocation.executorIdleTimeout ：executor闲暇的工夫，超时之后，将executor移除