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

作者 | 吴磊策划 | 陈思专题介绍：2009 年， Spark 诞生于加州大学伯克利分校的 AMP 实验室（the Algorithms, Machines and People lab），并于 2010 年开源。 2013 年， Spark 捐献给阿帕奇软件基金会（Apache Software Foundation），并于 2014 年成为 Apache 顶级项目。如今，十年光景已过， Spark 成为了大大小小企业与研究机构的常用工具之一，依旧深受不少开发人员的喜爱。如果你是初入江湖且希望了解、学习 Spark 的“小虾米” ，那么 InfoQ 与 FreeWheel 技术专家吴磊合作的专题系列文章——《深入浅出 Spark：原理详解与开发实践》一定适合你！本文系专题系列第三篇。
感谢各位看官在百忙之中来听我说书，真是太给面子啦！前文书《内存计算的由来 ——DAG》咱们说到 DAGScheduler 以首尾倒置的方式从后向前回溯 DAG 计算图，沿途以 Shuffle 为边界划分 Stages 。那么，这些 Stages 划分出来之后有什么用呢？DAGScheduler 如何将 DAG 划分出的 Stages 转化为可执行的分布式任务？本期“权力的游戏”将带您走进 Spark 调度系统，笔者将竭尽全力与您一起揭开 Spark 调度系统的神秘面纱。
在本段书正式开始之前，咱们先得铺垫铺垫，毕竟保不齐有刚入座的看官头一次来咱们书棚，咱们都得照顾到不是。在讲 Spark 调度系统之前，咱们先来简单回顾一下 Spark 分布式系统架构和重要概念。
Spark 是典型的主从型（M/S ， Master/Slave）架构，从系统的角度来看， Spark 分布式系统的核心进程只有两种：Driver 和 Executor ，分别对应主从架构的 Master 和 Slave 。显而易见，在 Spark 分布式系统中， Driver 只有一个，而 Executor 可以有多个。 Driver 提供 SparkContext（SparkSession）上下文环境，而上下文环境提供了 Spark 分布式系统所有的核心组件，如 RPC 系统、调度系统、存储系统、内存管理、Shuffle 管理等。 Driver 正是通过这些核心组件来对分布式任务进行拆解、调度、分发、追踪与维护，俗称“指挥的” 。相比 Driver ， Executor 进程要简单的多，主要负责分布式任务的执行和状态反馈，俗称“干活儿的” 。
那么问题来了，这两种核心进程分别运行在哪里呢？既然是分布式系统，我们就绕不开部署模式， Driver 和 Executor 运行在哪里，取决于我们采用哪种分布式部署模式。到目前为止， Spark 支持三种部署模式，每种部署模式对应着不同的资源管理器（Cluster Manager ，即 Spark 内置的 Standalone、HadoopYARN 和 Mesos），资源管理器用于管理、协调集群中的硬件资源。我们以 Standalone 模式为例，来看看 Driver 和 Executor 的运行时部署。

本文插图
Standalone 模式与进程部署如上图所示，在 Spark 内置的 Standalone 资源管理器中，物理节点的角色被划分为 Master 和 Worker ， Driver 进程运行于 Master 节点，而 Executor 则运行在 Worker 节点中。在 Standalone 模式下，计算资源以 Executor 为粒度用于任务调度，一个 Executor 包含若干 CPU core 和计算内存，一般来说， CPU core 的数量限定了 Executor 内的任务并行度。在 Spark 源码实现中， Executor 有个别名，唤作 Worker Offer ，听上去简单直接：“Worker 节点提供的用于任务计算的硬件资源 Offer” 。再说回 Driver ， Driver 进程中的 SparkContext（SparkSession）就像是潘多拉的盒子，一旦开启，宛如三十六天罡临凡、七十二地煞降世，牛鬼蛇神各显神通，我们的故事便是从这里开始。

本文插图