Spark源码系列-Standalone模式下Client&Cl
本文带读者从源码查看，分析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的某台机器上。
本文如果有错误的地方，欢迎指出。
