InfoQ深入浅出Spark（三）：Spark调度系统之“权力的游戏”( 三 )

由此可见， TaskScheduler 是承上启下、上通下达的关键角色，这也是为什么我们将塔斯克视为斯巴克建筑公司元老之一的原因。空降的架构师戴格在两位元老的协助下，可以说工作开展得相当顺利，然而，冰层之下，暗流涌动，表面的祥和与心悦诚服之间还远远画不上等号，空降领导想要获得创始元老的认可，还有很长的路要走。

本文插图
元老派提起塔斯克和拜肯德，公司里无人不知、无人不晓，两位老板一个是管事的头儿，一个是管人的头儿。既然是老板，自然不能什么事情都事必躬亲，塔斯克和拜肯德麾下都有一众小弟来负责具体事务。塔斯克手下有三位举足轻重的直级下属，分别是秘书 SchedulableBuilder、施工副经理 TaskSetManager 和验收员 TaskResultGetter ，三位虽说都是塔斯克的嫡系，早已与塔斯克达成默契，但副经理 TaskSetManager 对于自己老大的位子一直蠢蠢欲动，觊觎已久。
塔斯克作为老大高高在上，看的明明白白，对于三位下属的脾气秉性和利益诉求了然于胸，自然会察觉到 TaskSetManager 日渐突出的“脑后反骨” 。忌惮于 TaskSetManager 的野心，工于权术的塔斯克自然不会无动于衷，为了防患于未然，塔斯克首先通过“分权”来制衡 TaskSetManager 。所谓“分权” ，指的是每一个 TaskSetManager 都和 TaskSet 一一对应、绑定，形象地说，领到砌墙任务的副经理只负责盯着干活的人砌墙，而领到浇筑钢筋混凝土任务的副经理只负责看着工人把钢筋混凝土浇筑牢固，副经理与副经理之间没有半点交集，所有副经理都是直线向上汇报。
教会徒弟、饿死师傅，为了彻底免去后顾之忧，塔斯克决定对于施工副经理 TaskSetManager 的聘用采用外包制度，也即取消常驻施工副经理一职，有活儿（TaskSet）的时候才临时招聘 TaskSetManager 上岗负责实施，一旦工人们把活儿干完了，则立即取消 TaskSetManager 的劳动关系。可以这么说，塔斯克对于 TaskSetManager 是召之即来、挥之即去，说是始乱终弃也不为过。树大招风风撼树，人为名高名丧人，可悲可惜可叹， TaskSetManager 的狼子野心最终葬送了自己的大好前程。
然而， TaskSetManager 的悲惨命运还远未结束，除了受制于老板塔斯克，自己负责的活儿（TaskSet）能不能尽快找到合适的工人（WorkerOffer）施工，还要看老板秘书—— SchedulableBuilder 的脸色。
说起秘书 SchedulableBuilder ，就不得不提 Schedulable ，顾名思义， Schedulable 就是“可调度的（对象）” ，实现为 Scala Trait ，定义了可调度对象接口。 Schedulable 有两个具体实现类，一个就是刚刚提到的施工副经理 TaskSetManager ，另一个是 Pool —— 调度池。每个调度池都维护一个调度队列，这个队列存储的元素是一个个 Schedulable ，可以是 TaskSetManager ，也可以是 Pool 。
显然，调度队列最终构成的是一个层级嵌套结构，这就好比往一个容器里装水，除了装水之外还会放其他容器，而这些容器里除了盛水之外也还可能再容纳另外的容器，以此类推。不过，无论层级多么深、嵌套多么复杂，如果将这种层级嵌套结构展平（Flatten），得到的都是 TaskSetManager 数组。回到刚才容器盛水的类比，如果把所有嵌套的容器都去掉，那么只会留下一种元素—— 水。由此可见， TaskSetManager 是 Spark 调度系统的基本调度单元， Pool 是基于一定规则和策略对 TaskSetManager 进行排列组合的层级嵌套队列。
那么问题来了，对于两个不同的 TaskSetManager ， Spark 如何决定优先调度谁呢？对于有依赖关系的任务集，比如前文书提到的砌墙与浇筑钢筋混凝土， Spark 一定是先执行“砌墙”的任务集，再处理“浇筑钢筋混凝土” 。对于不存在依赖关系的任务集，如“铺地瓷”和“吊顶” ，很明显，两种任务可以互不妨碍地同时进行—— 此时便轮到秘书 SchedulableBuilder 大显身手了。 SchedulableBuilder 也被实现为 Scala Trait ，同时它也有两个具体实现，一个是 FIFOSchedulableBuilder ，另一个是 FairSchedulableBuilder 。两个实现类都需要做两件事情：构建调度池和添加TaskSetManager 。