**
YARN全局调度
**
本文将对 https://issues.apache.org/jira/browse/YARN-5139 这个yarn前瞻性功能，全局调度的思想进行深入分析。
首先了解一下全局调度和现有的调度模式有何区别，以及社区为什么要对全局调度进行研究开发工作，相比于现在的调度模式有何优势。
- 现有的调度模式：
现有的调度模式是基于NM（NodeManager）的心跳的方式进行调度的（不考虑持续调度模式），进行调度时，一次只考虑一个节点，这很容易造成非最优的调度。举个例子，一个请求要到第100个节点的心跳过来才是他最合适的节点，那么很可能到中间某一次心跳就分给他资源了，不是他最满意的节点。
其大概逻辑如下：
for node in allNodes:
Go to parentQueue
Go to leafQueue
for application in leafQueue.applications:
for resource-request in application.resource-requests
try to schedule on node首先收到NM的心跳，如有空闲Container则进行调度，调度的层次是从父队列到子队列，再到对应的app，最终把应该调度的资源请求在该心跳的节点上进行资源分配。
考虑未来可能的复杂需求：
1.比如申请需要的节点限制：a&&b||c ，必须要在满足a节点 和 b节点的情况下,或者满足c节点进行资源分配。
2.或者有对立的需求，例如HBASE的regionsevers和Storm workers不能分配在同一个节点上。
所以社区考虑把YARN的调度器像全局调度发展。
和现有的调度模式不同，全局调度需要能实现调度的时候，可以对更多的节点进行考虑，找到与应用程序需求最匹配的那些节点。
全局调度的调度逻辑为（提出候选节点的概念，不再是只考虑心跳的节点）：
Go to parentQueue
Go to leafQueue
for application in leafQueue.applications:
for resource-request in application.resource-requests
for node in nodes (node candidates sorted according to resource-request)
try to schedule on node主要committer Wangda Tan 的评论：
Because only application knows which node is best for its pending resource requests, so we can sort and filter node candidates based on application’s resource-requests.（因为只有application 知道哪一个节点最适合pending的资源，所以我们可以根据应用的资源请求来对候选节点进行排序）
