Spark3内核源码与优化

一、Spark内核原理

1、Spark 内核概述

1.1 简介

Spark 内核泛指 Spark 的核心运行机制，包括 Spark 核心组件的运行机制、Spark 任务调度机制、Spark 内存管理机制、Spark 核心功能的运行原理等，熟练掌握 Spark 内核原理，能够帮助我们更好地完成 Spark 代码设计，并能够帮助我们准确锁定项目运行过程中出现的问题的症结所在

1.2 Spark 核心组件

Driver是Spark 驱动器节点，用于执行 Spark 任务中的 main 方法，负责实际代码的执行工作。Driver 在 Spark 作业执行时主要负责：

• 将用户程序转化为作业（Job）
• 在 Executor 之间调度任务（Task）
• 跟踪Executor 的执行情况
• 通过UI 展示查询运行情况

Executor是负责在 Spark 作业中运行具体任务，任务彼此之间相互独立。Spark 应用启动时，ExecutorBackend 节点被同时启动，并且始终伴随着整个 Spark 应用的生命周期而存在。如果有 ExecutorBackend 节点发生了故障或崩溃，Spark 应用也可以继续执行， 会将出错节点上的任务调度到其他Executor 节点上继续运行，Executor 有两个核心功能：

• 负责运行组成 Spark 应用的任务，并将结果返回给驱动器（Driver）
• 它们通过自身的块管理器（Block Manager）为用户程序中要求缓存的 RDD 提供内存式存储。RDD 是直接缓存在 Executor 进程内的，因此任务可以在运行时充分利用缓存

1.3 Spark 通用运行流程概述

• 任务提交后，都会先启动 Driver 程序；
• 随后Driver 向集群管理器注册应用程序；
• 集群管理器根据此任务的配置文件分配Executor 并启动；
• Driver 开始执行 main 函数，Spark 查询为懒执行，当执行到 Action 算子时开始反向推算，根据宽依赖进行 Stage 的划分，随后每一个 Stage 对应一个Taskset，Taskset 中有多个 Task，查找可用资源Executor 进行调度；
• 根据本地化原则，Task 会被分发到指定的 Executor 去执行，在任务执行的过程中，Executor 也会不断与Driver 进行通信，报告任务运行情况

2、Spark 部署模式

2.1 YARN Cluster 模式(重点)

• 执行脚本提交任务，实际是启动一个 SparkSubmit 的 JVM 进程
• SparkSubmit 类中的 main 方法反射调用 YarnClusterApplication 的 main 方法
• YarnClusterApplication 创建 Yarn 客户端，然后向 Yarn 服务器发送执行指令：bin/java ApplicationMaster
• Yarn 框架收到指令后会在指定的 NM 中启动ApplicationMaster
• ApplicationMaster 启动 Driver 线程，执行用户的作业
• AM 向 RM 注册，申请资源
• 获取资源后 AM 向NM 发送指令：bin/java YarnCoarseGrainedExecutorBackend
• CoarseGrainedExecutorBackend 进程会接收消息，跟 Driver 通信，注册已经启动的Executor；然后启动计算对象 Executor 等待接收任务
• Driver 线程继续执行完成作业的调度和任务的执行
• Driver 分配任务并监控任务的执行

注意：SparkSubmit、ApplicationMaster 和CoarseGrainedExecutorBackend 是独立的进程；Driver是独立的线程；Executor 和 YarnClusterApplication 是对象

2.2 YARN Client 模式

• 执行脚本提交任务，实际是启动一个 SparkSubmit 的 JVM 进程
• SparkSubmit 类中的 main 方法反射调用用户代码的main 方法
• 启动Driver 线程，执行用户的作业，并创建 ScheduleBackend
• YarnClientSchedulerBackend 向RM 发送指令：bin/java ExecutorLauncher
• Yarn 框架收到指令后会在指定的 NM 中启动 ExecutorLauncher（实际上还是调用ApplicationMaster 的 main 方法）
• AM 向 RM 注册，申请资源
• 获取资源后 AM 向NM 发送指令：bin/java CoarseGrainedExecutorBackend
• CoarseGrainedExecutorBackend 进程会接收消息，跟 Driver 通信，注册已经启动的Executor；然后启动计算对象 Executor 等待接收任务
• Driver 分配任务并监控任务的执行

注意：SparkSubmit、ApplicationMaster 和 YarnCoarseGrainedExecutorBackend 是独立的进程；Executor 和Driver 是对象

2.3 Standalone Cluster 模式

在 Standalone Cluster 模式下，任务提交后，Master 会找到一个 Worker 启动 Driver。Driver 启动后向 Master 注册应用程序，Master 根据 submit 脚本的资源需求找到内部资源至少可以启动一个Executor 的所有 Worker，然后在这些 Worker 之间分配 Executor，Worker 上的 Executor 启动后会向Driver 反向注册，所有的 Executor 注册完成后，Driver 开始执行 main函数，之后执行到Action 算子时，开始划分Stage，每个 Stage 生成对应的 taskSet，之后将Task 分发到各个 Executor 上执行

2.4 Standalone Client 模式

在 Standalone Client 模式下，Driver 在任务提交的本地机器上运行。Driver 启动后向Master 注册应用程序，Master 根据 submit 脚本的资源需求找到内部资源至少可以启动一个Executor 的所有 Worker，然后在这些 Worker 之间分配 Executor，Worker 上的 Executor 启动后会向 Driver 反向注册，所有的 Executor 注册完成后，Driver 开始执行 main 函数，之后执行到 Action 算子时，开始划分 Stage，每个 Stage 生成对应的 TaskSet，之后将 Task 分发到各个Executor 上执行

3、Spark 通讯架构

3.1 Spark 通信架构概述

• Spark 早期版本中采用 Akka 作为内部通信部件
• Spark1.3 中引入Netty 通信框架，为了解决 Shuffle 的大数据传输问题使用
• Spark1.6 中Akka 和Netty 可以配置使用。Netty 完全实现了 Akka 在 Spark 中的功能
• Spark2 系列中，Spark 抛弃 Akka，使用 Netty。

Spark2.x 版本使用 Netty 通讯框架作为内部通讯组件。Spark 基于 Netty 新的 RPC 框架借

Endpoint（Client/Master/Worker）有 1 个 InBox 和N 个OutBox（N>=1，N 取决于当前 Endpoint与多少其他的Endpoint 进行通信，一个与其通讯的其他Endpoint 对应一个OutBox），Endpoint接收到的消息被写入InBox，发送出去的消息写入 OutBox 并被发送到其他Endpoint 的InBox中

3.2 Spark 通讯架构解析

• RpcEndpoint：RPC 通信终端。Spark 针对每个节点（Client/Master/Worker）都称之为一个 RPC 终端，且都实现 RpcEndpoint 接口，内部根据不同端点的需求，设计不同的消息和不同的业务处理，如果需要发送（询问）则调用Dispatcher。在 Spark 中，所有的终端都存在生命周期：Constructor/onStart/receive*/onStop
• RpcEnv：RPC 上下文环境，每个 RPC 终端运行时依赖的上下文环境称为 RpcEnv；在把当前 Spark 版本中使用的 NettyRpcEnv
• Dispatcher：消息调度（分发）器，针对于 RPC 终端需要发送远程消息或者从远程 RPC 接收到的消息，分发至对应的指令收件箱（发件箱）。如果指令接收方是自己则存入收件箱，如果指令接收方不是自己，则放入发件箱
• Inbox：指令消息收件箱。一个本地RpcEndpoint 对应一个收件箱，Dispatcher 在每次向Inbox 存入消息时，都将对应 EndpointData 加入内部ReceiverQueue 中，另外 Dispatcher创建时会启动一个单独线程进行轮询 ReceiverQueue，进行收件箱消息消费
• RpcEndpointRef：RpcEndpointRef 是对远程 RpcEndpoint 的一个引用。当我们需要向一个具体的RpcEndpoint 发送消息时，一般我们需要获取到该RpcEndpoint 的引用，然后通过该应用发送消息
• OutBox：指令消息发件箱。对于当前 RpcEndpoint 来说，一个目标 RpcEndpoint 对应一个发件箱，如果向多个目标RpcEndpoint 发送信息，则有多个OutBox。当消息放入Outbox 后，紧接着通过 TransportClient 将消息发送出去。消息放入发件箱以及发送过程是在同一个线程中进行
• RpcAddress：表示远程的RpcEndpointRef 的地址，Host + Port
• TransportClient：Netty 通信客户端，一个 OutBox 对应一个TransportClient，TransportClient不断轮询OutBox，根据 OutBox 消息的 receiver 信息，请求对应的远程 TransportServer
• TransportServer：Netty 通信服务端，一个 RpcEndpoint 对应一个TransportServer，接受远程消息后调用 Dispatcher 分发消息至对应收发件箱

4、Spark 任务调度机制

4.1 简介

在生产环境下，Spark 集群的部署方式一般为 YARN-Cluster 模式，之后的内核分析内容中我们默认集群的部署方式为 YARN-Cluster 模式。在上一章中我们讲解了 Spark YARN-Cluster 模式下的任务提交流程，但是我们并没有具体说明 Driver 的工作流程， Driver 线程主要是初始化 SparkContext 对象， 准备运行所需的上下文， 然后一方面保持与ApplicationMaster 的 RPC 连接，通过 ApplicationMaster 申请资源，另一方面根据用户业务逻辑开始调度任务，将任务下发到已有的空闲 Executor 上。

当 ResourceManager 向ApplicationMaster 返回Container 资源时，ApplicationMaster 就尝试在对应的Container 上启动 Executor 进程，Executor 进程起来后，会向Driver 反向注册， 注册成功后保持与 Driver 的心跳，同时等待 Driver 分发任务，当分发的任务执行完毕后， 将任务状态上报给Driver。

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 级的调度，总体调度流程如下图所示

Spark RDD 通过其Transactions 操作，形成了RDD 血缘（依赖）关系图，即 DAG，最后通过 Action 的调用，触发 Job 并调度执行，执行过程中会创建两个调度器：DAGScheduler 和 TaskScheduler

• DAGScheduler 负责 Stage 级的调度，主要是将 job 切分成若干 Stages，并将每个 Stage打包成 TaskSet 交给 TaskScheduler 调度
• TaskScheduler 负责Task 级的调度，将 DAGScheduler 给过来的TaskSet 按照指定的调度策略分发到 Executor 上执行，调度过程中 SchedulerBackend 负责提供可用资源，其中SchedulerBackend 有多种实现，分别对接不同的资源管理系统

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 由最终的 RDD 和 Action 方法封装而成；SparkContext 将 Job 交给 DAGScheduler 提交，它会根据 RDD 的血缘关系构成的 DAG 进行切分，将一个 Job 划分为若干 Stages，具体划分策略是，由最终的 RDD 不断通过依赖回溯判断父依赖是否是宽依赖，即以 Shuffle 为界，划分 Stage，窄依赖的 RDD 之间被划分到同一个 Stage 中，可以进行pipeline 式的计算。划分的 Stages 分两类，一类叫做 ResultStage ，为 DAG 最下游的 Stage ，由 Action 方法决定， 另一类叫做ShuffleMapStage，为下游 Stage 准备数据，下面看一个简单的例子 WordCount

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，形成 pipeline 操作，即ShuffleMapStage 中，实际执行的时候，数据记录会一气呵成地执行 RDD-0 到 RDD-2 的转化。不难看出，其本质上是一个深度优先搜索（Depth First Search）算法

一个 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 并监控相关状态信息

4.4 Spark Task 级调度

Spark Task 的调度是由 TaskScheduler 来完成，由前文可知，DAGScheduler 将 Stage 打包到交给 TaskScheTaskSetduler，TaskScheduler 会将 TaskSet 封装为 TaskSetManager 加入到调度队列中，TaskSetManager 结构如下图所示

TaskSetManager 负责监控管理同一个 Stage 中的 Tasks ， TaskScheduler 就是以TaskSetManager 为单元来调度任务。TaskScheduler 初始化后会启动 SchedulerBackend，它负责跟外界打交道， 接收 Executor 的注册信息，并维护 Executor 的状态，所以说 SchedulerBackend 是管"粮食" 的，同时它在启动后会定期地去"询问"TaskScheduler 有没有任务要运行，也就是说，它会定期地"问"TaskScheduler"我有这么余粮，你要不要啊"，TaskScheduler 在 SchedulerBackend"问"它的时候，会从调度队列中按照指定的调度策略选择 TaskSetManager 去调度运行

1 调度策略

TaskScheduler 支持两种调度策略，一种是 FIFO，也是默认的调度策略，另一种是 FAIR。在 TaskScheduler 初始化过程中会实例化 rootPool，表示树的根节点，是 Pool 类型

如果是采用 FIFO 调度策略，则直接简单地将 TaskSetManager 按照先来先到的方式入队，出队时直接拿出最先进队的 TaskSetManager

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 中被指定，调度池在构建阶段会读取此文件的相关配置

• 如果A 对象的runningTasks大于它的minShare，B 对象的runningTasks 小于它的minShare，那么B 排在 A 前面；（runningTasks 比 minShare 小的先执行）
• 如果 A、B 对象的 runningTasks 都小于它们的 minShare，那么就比较 runningTasks 与minShare 的比值（minShare 使用率），谁小谁排前面；（minShare 使用率低的先执行）
• 如果 A、B 对象的 runningTasks 都大于它们的 minShare，那么就比较 runningTasks 与weight 的比值（权重使用率），谁小谁排前面。（权重使用率低的先执行）
• 如果上述比较均相等，则比较名字。

整体上来说就是通过minShare和weight 这两个参数控制比较过程，可以做到让minShare 使用率和权重使用率少（实际运行 task 比例较少）的先运行。FAIR 模式排序完成后，所有的 TaskSetManager 被放入一个 ArrayBuffer 里，之后依次被取出并发送给Executor 执行。从调度队列中拿到 TaskSetManager 后，由于 TaskSetManager 封装了一个 Stage 的所有Task，并负责管理调度这些 Task，那么接下来的工作就是 TaskSetManager 按照一定的规则一个个取出 Task 给TaskScheduler，TaskScheduler 再交给 SchedulerBackend 去发到 Executor 上执行

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 一共有五种，优先级由高到低顺序

名称	解析
PROCESS_LOCAL	进程本地化，task 和数据在同一个 Executor 中，性能最好
NODE_LOCAL	节点本地化，task 和数据在同一个节点中，但是 task 和数据不在同一个 Executor 中，数据需要在进程间进行传输
RACK_LOCAL	机架本地化，task 和数据在同一个机架的两个节点上，数据需要通过网络在节点之间进行传输
NO_PREF	对于 task 来说，从哪里获取都一样，没有好坏之分
ANY	task 和数据可以在集群的任何地方，而且不在一个机架中，性能最差

在调度执行时，Spark 调度总是会尽量让每个 task 以最高的本地性级别来启动，当一个task 以X 本地性级别启动，但是该本地性级别对应的所有节点都没有空闲资源而启动失败， 此时并不会马上降低本地性级别启动而是在某个时间长度内再次以 X 本地性级别来启动该task，若超过限时时间则降级启动，去尝试下一个本地性级别，依次类推。

可以通过调大每个类别的最大容忍延迟时间，在等待阶段对应的 Executor 可能就会有相应的资源去执行此 task，这就在在一定程度上提到了运行性能

3 失败重试与黑名单机制

除了选择合适的 Task 调度运行外，还需要监控Task 的执行状态，前面也提到，与外部打交道的是 SchedulerBackend，Task 被提交到 Executor 启动执行后，Executor 会