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

从上图中不难发现，事件类型与处理方法都由 DAGScheduler 定义、提供， EventProcessLoop 的主要职责在于提供单线程执行环境、接收 DAGSchedulerEvent、调用对应的 Handler 方法、以循环的方式异步执行处理逻辑。换句话说，做什么（What）、怎么做（How），由戴老板明确示下，贴身秘书 EventProcessLoop 则按照老板的指示全天候、24 小时、马不停蹄地撸起袖子加油干。
然而，尽管有得力干将 EventProcessLoop 分忧，作为全公司的一把手，戴格一方面需要处理好与平级塔斯克和拜肯德之间的关系，另一方面又要事无巨细地摸清公司的“事儿”与“人” 。另外，作为一名空降的领导，戴老板也不得不时不时地亲自“露两手”来赢得平级、下属以及全公司的认可和信任。除了交予 EventProcessLoop 的“活儿” ，还有很多事情需要戴老板亲自跟进：
o DAG 解析、Stage 拆解（参考上一篇《内存计算的由来 —— DAG》）
o 生成 TaskSet ，获取 Tasks 的偏好位置（Preferred Locations）
o 不同 Stage 之间的失败重试与容错
在权力场，老大联合老三打压老二是常见的策略，所谓远交近攻，但是坐第三把交椅的拜肯德对空降老大戴格的态度是：吃冰棍、拉冰棍—— 没话（化）！关于人力资源和任务执行的情况，戴老板拿到的信息都是塔斯克传递的二手信息，拜肯德从来不直接向戴格汇报工作。一句话，在我拜肯德眼里，你戴格是空气般的存在，塔斯克才是斯巴克建筑公司的唯一首领。真真是“江湖你拜哥，人狠话不多” 。
对于戴格的空降，塔斯克更是如鲠在喉—— 我塔斯克为公司服役这么多年，承接、实施了多少建筑工程项目，早已成为全公司事实上的一把手，公司在这个节骨眼把戴格招进来当老大，到底是何用意？面对这样的平级关系，戴格自然是如履薄冰。
不过，元老派也不是铁板一块，组织架构中原本已经固化的阶层关系因为戴格的到来产生了微妙的变化。不仅如此，公司为了进一步制衡两位创始元老，分别招聘了工程进度总监（MapOutputTrackerMaster）和工程监理总监（BlockManagerMaster）来协助戴格更好地开展工作。
MapOutputTrackerMaster 负责维护不同 Stage 间 Shuffle 任务的中间状态，一旦出现 Shuffle 中间结果不可获取的情况， DAGScheduler 便通过 post 方法将 ResubmitFailedStages 事件递交给 EventProcessLoop 从而进行 Stage 之间的失败重试。 BlockManagerMaster 则负责维护所有与数据存储有关的元信息，如 HDFS 数据分片所在地址、Shuffle 中间文件的输出路径等， DAGScheduler 需要调用 BlockManagerMaster 的 getLocations 方法来获取 TaskSet 中 Tasks 的位置偏好。

本文插图
空降派人员构成到此， Spark 调度系统中的主要角色基本都已浮出水面，咱们用一张“航拍”鸟瞰图，来完整地刻画不同角色的派系、立场、职责与定位。

本文插图
Spark 调度系统的权力角色任务提交的代码调用抛开错综复杂的权力纠葛不谈，我们来看看 Spark 调度系统端到端是如何运作的。我们最关心的莫过于开发者在调用 Action 算子、触发任务提交之后， Spark 调度系统如何在分布式环境中进行任务调度、“数据不动代码动”到底是如何实现的？下面的这张代码调用流程图看上去未免过于压力山大，咱们不如像庖丁宰牛那样，一块块地给它分解开来，这样不同的环节看上去也会更明了一些。

本文插图