本文带读者从源码查看，分析Yarn模式下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
Yarn Client 源码分析
由上可知，最终我们解析的是用户的Class，而最重要的类就是SparkContext，高版本是SparkSession，本质是将SparkContext作为SparkSession的成员变量。
Yarn Client 总架构
SparkSession
SparkSession将SparkContext作为的自己成员变量
image.png
image.png
SparkContext
createTaskScheduler
重点需要看createTaskScheduler方法，然后调用start
image.png
TaskSchedulerImpl
这里会创建TaskSchedulerImpl和StandaloneSchedulerBackend，并通过initialize将StandaloneSchedulerBackend放入TaskSchedulerImpl中，结合上图，会调用StandaloneSchedulerBackend的start方法
image.png
image.png
image.png
这里的cm(clusterManager)是 YarnClusterManager,scheduler是YarnScheduler, backend是YarnClientSchedulerBackend
YarnClusterManager.initialize() 方法
YarnClusterManager继承TaskSchedulerImpl,
将Backend作为自己的成员变量，并通过schedulingMode创建调度是FIFOSchedulableBuilder还是FairSchedulableBuilder，这里是提交task的时候用到的调度方式
image.png
YarnClientSchedulerBackend
YarnClientSchedulerBackend继承YarnSchedulerBackend,YarnSchedulerBackend 继承CoarseGrainedSchedulerBackend
image.png
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。接下来回到我们的YarnSchedulerBackend中
image.png
start方法第二部分
第一部分调用了super.start我们知道了Driver的本质和职责接下来，看第二部分
image.png
org.apache.spark.deploy.yarn.Client
Client中有一个yarnClient成员变量,与yarn集群做RPC通信,提交Application使用
image.png
org.apache.spark.deploy.yarn.Client. submitApplication
image.png
createContainerLaunchContext中会申请ApplicationMaster的启动信息,并指定启动类,
- cluster模式: org.apache.spark.deploy.yarn.ApplicationMaster
-
client模式:org.apache.spark.deploy.yarn.ExecutorLauncher
image.png
ExecutorLauncher
什么也没有做,就是调用了ApplicationMaster的main方法
image.png
org.apache.spark.deploy.yarn.ApplicationMaster
会根据运行模式(client or cluster), 这里是client模式,所以执行runExecutorLauncher
image.png
image.png
image.png
image.png
image.png
通过ExecutorRunnable来启动Executor
image.png
ExecutorRunnable中有nmClient, 就是NodeManagerClient, 通过nmClient与NodeManager RPC通信, 启动Executor
image.png
prepareCommand会指定Executor所启动的类
image.png
这个类就是CoarseGrainedExecutorBackend, 并且会传入driver url,
image.png
Executor 启动
CoarseGrainedExecutorBackend也是一个EndPoint，所以也会走RPC的生命周期方法，一个很重要的点是，Client -> Master->Worker ->Executor将driverUrl的信息传递给Executor，Executor启动后根据driverUrl向driverUrl反向注册自己
image.png
Driver接收到Executor注册后，运算资源已经有了，DriverEndpoint里的开始调度，如果有Task，就开始LaunchTask，到此，Spark On Yarn Client源码分析完毕
image.png
接下来分析 Yarn Cluster模式
Yarn Cluster 总架构
Cluster与Client不同的是，Client的Driver（分配Task）和ApplicationMaster（申请资源）是不在同一个进程里面的，Cluster模式的Driver（分配Task）和ApplicationMaster（申请资源）不同一个进程里
image.png
由SparkSubmit图我们可以知道，Cluster模式里，启动的是YarnClusterApplication
YarnClusterApplication
image.png
org.apache.spark.deploy.yarn.Client
这个是和 client 模式中使用同样的Client类,不同的是,cluster启动的是org.apache.spark.deploy.yarn.ApplicationMaster, 前面我们分析知道client模式中org.apache.spark.deploy.yarn.ExecutorLauncher 其实就是调用了ApplicationMaster.main(), 还有一点是cluster模式中,需要启动driver
image.png
ApplicationMaster
image.png
runDriver
在ApplicationMaster进程中,通过反射调用userClass, userClass中就会启动SparkSession, SparkContext等.
image.png
image.png
分析源码可以得到下面这个图,本质上还是用的CoarseGrainedExecutorBackend里的driver
image.png
ApplicationMaster里的资源申请(启动Executor)
逻辑和client分析过程一样的,就是通过ExecutorRunnable启动CoarseGrainedExecutorBackend
image.png
Yarn Cluster 总架构
image.png
总结
本文从源码，分析Yarn模式下Client&Cluster模式的资源启动流程，分析Client&Cluster究竟有什么不一样，本质的不一样就是Driver和ApplicationMaster在不在同一进程里。
本文如果有错误的地方，欢迎指出。
网友评论