Spark 任务调度机制

你的名字 2024-04-20 09:13 95阅读 0赞

# 4.Spark 任务调度机制 #

在工厂环境下，Spark 集群的部署方式一般为 YARN-Cluster 模式，之后的内核

分析内容中我们默认集群的部署方式为 YARN-Cluster 模式。

## 4.1 Spark 任务提交流程 ##

在上一章中我们讲解了 Spark YARN-Cluster 模式下的任务提交流程，

如下图所示：

![1604514-20190710181443356-356826470.png][]

下面的时序图清晰地说明了一个 Spark 应用程序从提交到运行的完整流程：

![1604514-20190710181555811-585416268.png][]

提交一个 Spark 应用程序，首先通过 Client 向 ResourceManager 请求启动一个

Application，同时检查是否有足够的资源满足 Application 的需求，如果资源条件满

足，则准备 ApplicationMaster 的启动上下文，交给 ResourceManager，并循环监控

Application 状态。

当提交的资源队列中有资源时，ResourceManager 会在某个 NodeManager 上启

动 ApplicationMaster 进程，ApplicationMaster 会单独启动 Driver 后台线程，当 Driver

启动后，ApplicationMaster 会通过本地的 RPC 连接 Driver，并开始向 ResourceManager

申请 Container 资源运行 Executor 进程（一个 Executor 对应与一个 Container），当

ResourceManager 返回 Container 资源，ApplicationMaster 则在对应的 Container 上启

动 Executor。

Driver 线程主要是初始化 SparkContext 对象，准备运行所需的上下文，然后一

方面保持与 ApplicationMaster 的 RPC 连接，通过 ApplicationMaster 申请资源，另一

方面根据用户业务逻辑开始调度任务，将任务下发到已有的空闲 Executor 上。

当 ResourceManager 向 ApplicationMaster 返 回 Container 资源时，

ApplicationMaster 就尝试在对应的 Container 上启动 Executor 进程，Executor 进程起

来后，会向 Driver 反向注册，注册成功后保持与 Driver 的心跳，同时等待 Driver

分发任务，当分发的任务执行完毕后，将任务状态上报给 Driver。

从上述时序图可知，Client 只负责提交 Application 并监控 Application 的状态。

对于 Spark 的任务调度主要是集中在两个方面: 资源申请和任务分发，其主要是通

过 ApplicationMaster、Driver 以及 Executor 之间来完成。

## 4.2 Spark 任务调度概述 ##

当 Driver 起来后，Driver 则会根据用户程序逻辑准备任务，并根据 Executor 资

源情况逐步分发任务。在详细阐述任务调度前，首先说明下 Spark 里的几个概念。

一个 Spark 应用程序包括 Job、Stage 以及 Task 三个概念：

 Job 是以 Action 方法为界，遇到一个 Action 方法则触发一个 Job；

 Stage 是 Job 的子集，以 RDD 宽依赖(即 Shuffle)为界，遇到 Shuffle 做一次

划分；

 Task 是 Stage 的子集，以并行度(分区数)来衡量，分区数是多少，则有多少

个 task。

Spark 的任务调度总体来说分两路进行，一路是 Stage 级的调度，一路是 Task

级的调度，总体调度流程如下图所示：

![1604514-20190710181813577-66708854.png][]

Spark RDD 通过其 Transactions 操作，形成了 RDD 血缘关系图，即 DAG，最后

通过 Action 的调用，触发 Job 并调度执行。 DAGScheduler 负责 Stage 级的调度，

主要是将 DAG 切分成若干 Stages，并将每个 Stage 打包成 TaskSet 交给 TaskScheduler

调度。 TaskScheduler 负责 Task 级的调度，将 DAGScheduler 给过来的 TaskSet 按照

指定的调度策略分发到 Executor 上执行，调度过程中 SchedulerBackend 负责提供可

用资源，其中  SchedulerBackend 有多种实现，分别对接不同的资源管理系统。有了

上述感性的认识后，下面这张图描述了 Spark-On-Yarn 模式下在任务调度期间，

ApplicationMaster、Driver 以及 Executor 内部模块的交互过程：

![1604514-20190710181924301-1732909811.png][]

Driver 初始化 SparkContext 过 程 中 ， 会 分 别 初 始 化 DAGScheduler 、

TaskScheduler、SchedulerBackend 以及 HeartbeatReceiver，并启动 SchedulerBackend

以及 HeartbeatReceiver。SchedulerBackend 通过 ApplicationMaster 申请资源，并不

断从 TaskScheduler 中拿到合适的 Task 分发到 Executor 执行。HeartbeatReceiver 负

责接收 Executor 的心跳信息，监控 Executor 的存活状况，并通知到 TaskScheduler。

## 4.3 Spark Stage 级调度 ##

Spark 的任务调度是从 DAG 切割开始，主要是由 DAGScheduler 来完成。当遇

到一个 Action 操作后就会触发一个 Job 的计算，并交给 DAGScheduler 来提交，下

图是涉及到 Job 提交的相关方法调用流程图。

![1604514-20190710182022090-717568927.png][]

Job 由 最 终 的 RDD 和 Action 方 法 封 装 而 成 ， SparkContext 将 Job 交 给

DAGScheduler 提交，它会根据 RDD 的血缘关系构成的 DAG 进行切分，将一个 Job

划分为若干 Stages，具体划分策略是，由最终的 RDD 不断通过依赖回溯判断父依赖

是否是宽依赖，即以 Shuffle 为界，划分 Stage，窄依赖的 RDD 之间被划分到同一个

Stage 中，可以进行 pipeline 式的计算，如上图紫色流程部分。划分的 Stages 分两类，

一类叫做 ResultStage，为 DAG 最下游的 Stage，由 Action 方法决定，另一类叫做

ShuffleMapStage，为下游 Stage 准备数据，下面看一个简单的例子 WordCount。

![1604514-20190710182056487-1906604831.png][]

Job 由 saveAsTextFile 触发，该 Job 由 RDD-3 和 saveAsTextFile 方法组成，根据

RDD 之间的依赖关系从 RDD-3 开始回溯搜索，直到没有依赖的 RDD-0，在回溯搜

索过程中，RDD-3 依赖 RDD-2，并且是宽依赖，所以在 RDD-2 和 RDD-3 之间划分

Stage，RDD-3 被划到最后一个 Stage，即 ResultStage 中，RDD-2 依赖 RDD-1，RDD-1

依赖 RDD-0，这些依赖都是窄依赖，所以将 RDD-0、RDD-1 和 RDD-2 划分到同一

个 Stage，即 ShuffleMapStage 中，实际执行的时候，数据记录会一气呵成地执行

RDD-0 到 RDD-2 的转化。不难看出，其本质上是一个深度优先搜索算法。

一个 Stage 是否被提交，需要判断它的父 Stage 是否执行，只有在父 Stage 执行

完毕才能提交当前 Stage，如果一个 Stage 没有父 Stage，那么从该 Stage 开始提交。

Stage 提交时会将 Task 信息（分区信息以及方法等）序列化并被打包成 TaskSet 交给

TaskScheduler，一个 Partition 对应一个 Task，另一方面 TaskScheduler 会监控 Stage

的运行状态，只有 Executor 丢失或者 Task 由于 Fetch 失败才需要重新提交失败的

Stage 以调度运行失败的任务，其他类型的 Task 失败会在 TaskScheduler 的调度过程

中重试。

相对来说 DAGScheduler 做的事情较为简单，仅仅是在 Stage 层面上划分 DAG，

提交 Stage 并监控相关状态信息。TaskScheduler 则相对较为复杂，下面详细阐述其

细节。

## 4.4 Spark Task 级调度 ##

Spark Task 的调度是由 TaskScheduler 来完成，由前文可知，DAGScheduler 将

Stage 打 包 到 TaskSet 交 给 TaskScheduler， TaskScheduler 会 将 TaskSet 封装为

TaskSetManager 加入到调度队列中，TaskSetManager 结构如下图所示。

![1604514-20190710182210959-2083452062.png][]

TaskSetManager 负责监控管理同一个 Stage 中的 Tasks，TaskScheduler 就是以

TaskSetManager 为单元来调度任务。

前面也提到， TaskScheduler 初始化后会启动 SchedulerBackend，它负责跟外界

打交道，接收 Executor 的注册信息，并维护 Executor 的状态，所以说 SchedulerBackend

是管“粮食”的，同时它在启动后会定期地去“询问”TaskScheduler 有没有任务要运行，

也就是说， 它会定期地 “ 问 ”TaskScheduler“ 我有这么余量，你 要不要啊 ” ，

TaskScheduler 在 SchedulerBackend“问”它的时候，会从调度队列中按照指定的调度

策略选择 TaskSetManager 去调度运行，大致方法调用流程如下图所示：

![1604514-20190710182300621-539162446.png][]

图 3-7 中，将 TaskSetManager 加入 rootPool 调度池中之后，调用 SchedulerBackend

的 riviveOffers 方法给 driverEndpoint 发送 ReviveOffer 消息； driverEndpoint 收到

ReviveOffer 消息后调用 makeOffers 方法，过滤出活跃状态的 Executor（这些 Executor

都是任务启动时反向注册到 Driver 的 Executor），然后将 Executor 封装成 WorkerOffer

对 象 ； 准 备 好 计 算 资 源 （ WorkerOffer ） 后 ， taskScheduler 基 于 这 些 资 源 调 用

resourceOffer 在 Executor 上分配 task。

### 4.4.1 调度策略 ###

前 面 讲 到 ， TaskScheduler 会 先 把 DAGScheduler 给 过 来 的 TaskSet 封装成

TaskSetManager 扔到任务队列里，然后再从任务队列里按照一定的规则把它们取出

来在 SchedulerBackend 给过来的 Executor 上运行。这个调度过程实际上还是比较粗

粒度的，是面向 TaskSetManager 的。

TaskScheduler 是以树的方式来管理任务队列，树中的节点类型为 Schdulable，

叶子节点为 TaskSetManager，非叶子节点为 Pool，下图是它们之间的继承关系。

![1604514-20190710182358014-773018847.png][]

TaskScheduler 支持两种调度策略，一种是 FIFO，也是默认的调度策略，另一种

是 FAIR。在 TaskScheduler 初始化过程中会实例化 rootPool，表示树的根节点，是

Pool 类型。

**　　1. FIFO 调度策略**

如果是采用 FIFO 调度策略，则直接简单地将 TaskSetManager 按照先来先到的

方式入队，出队时直接拿出最先进队的 TaskSetManager，其树结构如下图所示，

TaskSetManager 保存在一个 FIFO 队列中。

![1604514-20190710182443315-99686779.png][]

**　　2. FAIR 调度策略**

FAIR 调度策略的树结构如下图所示：

![1604514-20190710182547461-966533870.png][]

FAIR 模式中有一个 rootPool 和多个子 Pool，各个子 Pool 中存储着所有待分配

的 TaskSetMagager。

在 FAIR 模 式 中 ， 需 要 先 对 子 Pool 进 行 排 序 ， 再 对 子 Pool 里 面 的

TaskSetMagager 进行排序，因为 Pool 和 TaskSetMagager 都继承了 Schedulable 特

质，因此使用相同的排序算法。

排序过程的比较是基于 Fair-share 来比较的，每个要排序的对象包含三个属性:

runningTasks 值（正在运行的 Task 数）、minShare 值、weight 值，比较时会综合考

量 runningTasks 值，minShare 值以及 weight 值。

注意，minShare、weight 的值均在公平调度配置文件 fairscheduler.xml 中被指定，

调度池在构建阶段会读取此文件的相关配置。

1) 如果 A 对象的 runningTasks 大于它的 minShare，B 对象的 runningTasks 小

于它的 minShare，那么 B 排在 A 前面；（ runningTasks 比 minShare 小的先执行）

2) 如果 A、B 对象的 runningTasks 都小于它们的 minShare，那么就比较

runningTasks 与 minShare 的比值（ minShare 使用率），谁小谁排前面；（ minShare

使用率低的先执行）

3) 如果 A、B 对象的 runningTasks 都大于它们的 minShare，那么就比较

runningTasks 与 weight 的比值（ 权重使用率），谁小谁排前面。（ 权重使用率低的

先执行）

4) 如果上述比较均相等，则比较名字。

整体上来说就是通过 minShare 和 weight 这两个参数控制比较过程，可以做到

让 minShare 使用率和权重使用率少（实际运行 task 比例较少）的先运行。

FAIR 模式排序完成后，所有的 TaskSetManager 被放入一个 ArrayBuffer 里，之

后依次被取出并发送给 Executor 执行。

从调度队列中拿到 TaskSetManager 后，由于 TaskSetManager 封装了一个 Stage

的所有 Task，并负责管理调度这些 Task，那么接下来的工作就是 TaskSetManager

按照一定的规则一个个取出 Task 给 TaskScheduler ， TaskScheduler 再交给

SchedulerBackend 去发到 Executor 上执行。

### 4.4.2 本地化调度 ###

DAGScheduler 切割 Job，划分 Stage, 通过调用 submitStage 来提交一个 Stage

对应的 tasks，submitStage 会调用 submitMissingTasks，submitMissingTasks 确定每

个需要计算的 task 的 preferredLocations， 通过调用 getPreferrdeLocations()得到

partition 的优先位置，由于一个 partition 对应一个 task，此 partition 的优先位置就

是 task 的优先位置，对于要提交到 TaskScheduler 的 TaskSet 中的每一个 task，该 task

优先位置与其对应的 partition 对应的优先位置一致。

从调度队列中拿到 TaskSetManager 后，那么接下来的工作就是 TaskSetManager 按照一

定的规则一个个取出 task 给 TaskScheduler，TaskScheduler 再交给 SchedulerBackend 去发到

Executor 上执行。前面也提到，TaskSetManager 封装了一个 Stage 的所有 task，并负责管理

调度这些 task。

根据每个 task 的优先位置，确定 task 的 Locality 级别，Locality 一共有五种，优先级由

高到低顺序：

![1604514-20190710183040086-418887801.png][]

在调度执行时，Spark 调度总是会尽量让每个 task 以最高的本地性级别来启动，

当一个 task 以 X 本地性级别启动，但是该本地性级别对应的所有节点都没有空闲资

源而启动失败，此时并不会马上降低本地性级别启动而是在某个时间长度内再次以

X 本地性级别来启动该 task，若超过限时时间则降级启动，去尝试下一个本地性级

别，依次类推。

可以通过调大每个类别的最大容忍延迟时间，在等待阶段对应的 Executor 可能

就会有相应的资源去执行此 task，这就在在一定程度上提到了运行性能。

### 4.4.3 失败重试与黑名单机制 ###

除了选择合适的 Task 调度运行外，还需要监控 Task 的执行状态，前面也提到，

与外部打交道的是 SchedulerBackend，Task 被提交到 Executor 启动执行后，Executor

会将执行状态上报给 SchedulerBackend，SchedulerBackend 则告诉 TaskScheduler，

TaskScheduler 找到该 Task 对应的 TaskSetManager，并通知到该 TaskSetManager，这

样 TaskSetManager 就知道 Task 的失败与成功状态， 对于失败的 Task，会记录它失

败的次数，如果失败次数还没有超过最大重试次数，那么就把它放回待调度的 Task

池子中，否则整个 Application 失败。

在记录 Task 失败次数过程中，会记录它上一次失败所在的 Executor Id 和 Host，

这样下次再调度这个 Task 时，会使用黑名单机制，避免它被调度到上一次失败的节

点上，起到一定的容错作用。黑名单记录 Task 上一次失败所在的 Executor Id 和 Host，

以及其对应的“拉黑”时间，“拉黑”时间是指这段时间内不要再往这个节点上调

度这个 Task 了。

转载于:https://www.cnblogs.com/LXL616/p/11165826.html

[1604514-20190710181443356-356826470.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/97c528ea6d964f399fce745cc10bde1e.png
[1604514-20190710181555811-585416268.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/93eb9477081e4e9c9c0c5237a7d19514.png
[1604514-20190710181813577-66708854.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/8bb623772d3e43bc905ac19c918c4bed.png
[1604514-20190710181924301-1732909811.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/45e9a55fe72f4e30a19dece4afa4d2ce.png
[1604514-20190710182022090-717568927.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/2bb78adbcb054c08bca385b246c553b3.png
[1604514-20190710182056487-1906604831.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/038ebdbb9c6f42c78fca924181580350.png
[1604514-20190710182210959-2083452062.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/4a9c3ceb24094e4e874abde228f5de7a.png
[1604514-20190710182300621-539162446.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/aa46d3dba69c40319c757804cf189f30.png
[1604514-20190710182358014-773018847.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9c755cb4e02d4111b2b5d88d77b6e279.png
[1604514-20190710182443315-99686779.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/b5402a3dd41149589520d4a156ecc39e.png
[1604514-20190710182547461-966533870.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/935a19fb780249a9843c503868a4e63a.png
[1604514-20190710183040086-418887801.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/91e5b5dc7285499085bc21ab3b5f7c07.png