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


心有灵犀 —— 塔斯克与拜肯德不需言语 , 只要一个眼神、一个动作即可领会彼此的意图 , 塔斯克与拜肯德之间的默契大抵如此 。
在第 7 步 TaskScheduler 通过调用 reviveOffers 来请求计算资源后 , BackendScheduler 随即调动一切可以调动的力量通过 makeOffers 来协调计算资源 。 为了能够快速响应 TaskScheduler 的请求 , 拜老板用一个“小册子”来记录所有可用计算资源的状态 , 这个小册子就是 executorDataMap 。
executorDataMap 是类型为 HashMap[String,ExecutorData] 的数据结构 , 其中类型为 String 的 Key 记录 ExecutorID , 类型为 ExecutorData 的 Value 则记录每一个 Executor 的 Profile , 包括 Executor 的 RPCEndpoint、RPC 地址、主机地址、当前可用 CPU cores、满配 CPU cores 数量 , 等等 。 拜老板正是根据 executorDataMap 中 Executor 的主机地址和可用 CPU cores 来创建 Worker Offer , 并以 Worker Offer 为粒度量化计算资源 。
在第 9 步 , BackendScheduler 将所创建的 Worker Offers 打包并通过 TaskScheduler 的 resourceOffers 方法发送给 TaskScheduler , 尝试获取所有适合在提供的 Worker Offers 上执行的任务集合(Seq[Seq[TaskDescription]]) 。
前文书在塔斯克与 TaskSetManager 的恩怨纠葛中 , 咱们已经介绍过任务集的遴选过程 , 最终 TaskScheduler 在 TaskSetManager 的协助下将满足条件的、包含序列化任务代码的 Seq[Seq[TaskDescription]] 返回给 SchedulerBackend 。
拿到任务描述序列的 SchedulerBackend 随即调用 launchTasks 方法尝试把每一个任务分发到对应的 Executor 上 , 真正开启分布式任务执行的流程 。 对于拿到的每一个 TaskDescription , launchTask 首先获取其对应的 Executor , 然后根据 executorDataMap 获取该 Executor 的 ExecutorBackend , 最后通过向 ExecutorBackend 发送包含序列化任务的 LaunchTask 消息来分发待执行的任务代码 。
InfoQ深入浅出Spark(三):Spark调度系统之“权力的游戏”
本文插图
任务提交代码调用流程图 —— SchedulerBackend 内部调用
到第 14 步为止 , Spark 调度系统对于任务提交阶段的支持基本告一段落 , 我们来回顾一下从第 7 步到第 14 步 , 主要经历了哪些重要环节:

  • TaskScheduler 请求分布式计算资源
  • SchedulerBackend 搜集可用计算资源 , 并以 Worker Offers 的形式反馈给 TaskScheduler
  • TaskScheduler 根据获得的 Worker Offers , 根据调度规则(FIFO 或 Fair)和本地性的限制 , 搜集适合调度的任务集合 , 并以 TaskDescriptions 的形式反馈给 SchedulerBackend
  • 对于获取到的 TaskDescriptions , SchedulerBackend 将其中封装的任务代码分发到对应的 Executors 上 , 开启分布式任务执行流程
这 4 个环节的拆解更加直观地阐释了分布式计算中“数据不动代码动”的计算模式 , 在这种计算模式下 , 我们倾向于让数据“待在”它本来存储的地方、尽量保持不动 , 同时为了完成分布式计算 , 我们尽可能地把代码(任务)通过网络分发到它应该去的地方 , 而“它应该去的地方”正是有需要它处理的数据的地方 。 “数据不动代码动”的初衷之一在于从计算模式上减少数据的分发 , 降低分布式网络 I/O 开销从而在整体上提升执行性能 。 毕竟 , 分发代码的成本要比分发数据的代价低的多得多 。
追随者众 —— 拜老板的小弟们严格来说 , 从第 14 步往后已经超出了分布式系统调度的范畴 , 不过 , 为了还原一个分布式系统调度与执行的全貌 , 咱们接着往下说 。
前文书咱们说到 , 拜老板有一众忠心追随的小弟们—— ExecutorBackend , ExecutorBackend 作为驻扎在分公司的“人力资源经理” , 时刻搜集 Executor 的可用资源状态并随时向老板拜肯德汇报 , 拜老板正是基于这些小弟掌握的信息来从上帝视角更新、维护手里的“小册子”—— executorDataMap , 并根据 executorDataMap 中记录的信息来快速响应塔斯克他老人家的用人需求 。