Spark源码系列-Standalone模式下Client&Cluster模式的资源启动

本文带读者从源码查看，分析Standalone模式下Client&Cluster模式的资源启动流程，分析Client&Cluster究竟有什么不一样

回顾

在xxxx中我们分析了Standalone模式下Master和Worker的启动流程。

image.png

• Master负责集群总资源的管理，包括CPU、内存的分配以及所有Applications的管理、Cluster模式下还有所有的driver的管理。Master启动后会定时清理没有上报心跳的Worker
• Master启动后会向Master注册自己（RegisterWorker），将自己的CPU cores和内存大小上报给Master，并定时发送心跳，更新Master里面属于自己ID的时间戳

资源有了，接下来需要启动我们自己的Application。

SparkSubmit提交代码

image.png

image.png

通过分析spark-submit脚本，我们知道最终启动的是SparkSubmit类，接下来的调用流程如下所示。

image.png

最终通过prepareSumitEnvironment解析出mainClass，最终在SparkApplication start方法中，通过反射调用MainClass的main方法，解析的MainClass如下

image.png

Standalone Client 源码分析

由上可知，最终我们解析的是用户的Class，而最重要的类就是SparkContext，高版本是SparkSession，本质是将SparkContext作为SparkSession的成员变量。

Standalone Client 总架构

image.png

SparkSession

SparkSession将SparkContext作为的自己成员变量

image.png

image.png

SparkContext

createTaskScheduler

重点需要看createTaskScheduler方法，然后调用start

image.png

TaskSchedulerImpl

这里会创建TaskSchedulerImpl和StandaloneSchedulerBackend，并通过initialize将StandaloneSchedulerBackend放入TaskSchedulerImpl中，结合上图，会调用StandaloneSchedulerBackend的start方法

image.png

initialize

将Backend作为自己的成员变量，并通过schedulingMode创建调度是FIFOSchedulableBuilder还是FairSchedulableBuilder，这里是提交task的时候用到的调度方式

image.png

StandaloneSchedulerBackend

start方法第一部分

首先调用super.start，查看super.start方法为CoarseGrainedSchedulerBackend的start方法

image.png

CoarseGrainedSchedulerBackend.start()

image.png

这里调用了createDriverEndpointRef，可以看到关键词driver了，其实driver本质上的类是DriverEndpoint，结合Spark RPC框架，我们可以知道Driver的生命周期方法。

onStart() 和 receive

这里启动一个定时线程，定时给自己发送ReviveOffers，给自己发送case class ReviveOffers

image.png

makeOffers

通过命名方式我们可以知道，这里是在获取可用的executors的资源，将task信息包装成taskDescs，在Executor上启动task

image.png

将task序列化后发送给Executor，但是这里并未真正执行，因为还没有申请到Executor资源，所以onstart里的定时线程将会一直尝试执行，直到申请到executor，就会在上面launchTasks

image.png

Driver

本质上Driver是CoarseGrainedSchedulerBackend里的一个成员变量，负责序列化并通过RPC发送给有资源的Executor执行task，但是在这里并没有执行，因为还没有申请到执行资源Executor。接下来回到我们的StandaloneSchedulerBackend中

image.png

start方法第二部分

第一部分调用了super.start我们知道了Driver的本质和职责接下来，看第二部分

image.png

将需要启动的Executor本质上是org.apache.spark.executor.CoarseGrainedExecutorBackend类以及App所需要的资源cores 、内存等数据，和最重要的，第一部分super.start()启动的DriverEndpoint的driverUrl信息，封装到ApplicationDescription中，并启动StandaloneAppClient，将ApplicationDescription设置为StandaloneAppClient成员变量然后启动

StandaloneAppClient

image.png

ClientEndpoint onStart

向Master注册Application

image.png

image.png

Master接受到后，告诉Client注册成功

image.png

image.png

然后Master通过schedule调度分配Executor， 发送RPC在相应的Worker上启动Executor，实际就是Client发送给Master的org.apache.spark.executor.CoarseGrainedExecutorBackend

image.png

image.png

Worker接收到命令后开始启动Executor，所以下一步就是Excutor（CoarseGrainedExecutorBackend）的main方法

Worker 启动Exeutor

通过线程的方式，通过ExecutorRunner来启动Executor进程

image.png

image.png

Executor 启动

CoarseGrainedExecutorBackend也是一个EndPoint，所以也会走RPC的生命周期方法，一个很重要的点是，Client -> Master->Worker ->Executor将driverUrl的信息传递给Executor，Executor启动后根据driverUrl向driverUrl反向注册自己

image.png

Driver接收到Executor注册后，运算资源已经有了，DriverEndpoint里的开始调度，如果有Task，就开始LaunchTask，到此，StandAlone Client源码分析完毕

image.png

Standalone Cluster 总架构

Cluster与Client不同的是，Client的Driver（分配Task）和Client（申请资源）是在同一个类里面的UserClass里，Cluster模式的Driver（分配Task）和Client（申请资源）不在同一个进程里

image.png

由SparkSubmit图我们可以知道，Cluster模式里，启动的是spark.deploy.ClientApp

spark.deploy.ClientApp

启动ClientEndpoint，注意，此时的ClientEndpoint与Client模式下的不是同一个类，类名一样，包名不一样

image.png

org.apache.spark.deploy.ClientEndpoint

将Driver信息封装到driverDescription，主类是DriverWrapper，向Master注册RequestSubmitDriver(driverDescription)

image.png

Master启动通知Worker启动Driver（DriverWrapper）

image.png

image.png

image.png

Worker启动Driver，和启动Executor使用ExecutorRunner线程启动进程类似 ，Driver使用的是DriverRunner线程启动，主类就是DriverWrapper

DriverWrapper

通过反射调用UserClass，接下来的申请资源，和分配Task的过程与Client没有本质的区别

image.png

Standalone Cluster 总架构

image.png

总结

本文从源码，分析Standalone模式下Client&Cluster模式的资源启动流程，分析Client&Cluster究竟有什么不一样，本质的不一样就是Driver进程是在客户端机器还是在集群的Worker的某台机器上。
本文如果有错误的地方，欢迎指出。