Spark应用程序提交过程的关键源代码

本节主要分析如何将Spark应用程序提交到YARN上，当Spark的应用程序启动之后，应用内部的交互和Spark Standalone是一致的。

下面从前面的分析中抽取出Spark on YARN模式部署的实例构建信息，如表3-24所示。

表3-24 脚本中的参数与主资源间的对应关系

和Spark Standalone一样，Spark on YARN也存在两种部署模式，包括Client部署模式和Cluster部署模式。在Client的部署模式提交时，直接在提交点运行应用程序，即对应的驱动程序是在当前结点启动的。而在Spark on YARN模式部署下，需要通过ApplicationMas-ter管理用户应用程序，因此在该模式下，Client与Cluster两种部署模式下在不同结点启动驱动程序的差异，也就对应了两种部署模式下在集群中启动的ApplicationMaster的职责差异。

下面解析这两种部署模式下，Spark应用程序提交过程的关键源代码。

1.以Client的部署模式提交应用程序

当以Client的部署模式提交应用程序时，使用YarnScheduler与YarnClientSchedulerBack-end，在SparkContext构建出SparkDeploySchedulerBackend实例后，然后调用该实例的start方法，关键代码如下。

从以上代码中可以看出，关键代码位于“org.apache.spark.deploy.yarn.Client”，该类负责应用程序的提交。

2.以Cluster的部署模式提交应用程序

在集群管理器为YARN、部署模式为Cluster时，childMainClass及对应的mainClass的设置如表3-4所示。

关于内部的一些环境设置等细节，大家可以查看具体的代码实现。

在Cluster部署模式下提交时，封装的主类为＂org.apache.spark.deploy.yarn.Client＂，同时用户提交的应用程序的主类“args.mainClass”作为参数被封装到该主类中。

当主类为＂org.apache.spark.deploy.yarn.Client＂时，执行入口点为该类的main方法，具体代码如下。

结合前面以Client的部署模式提交应用程序，可以看到，使用Client部署模式提交与使用Cluster部署模式提交最终都会实例化一个＂org.apache.spark.deploy.yarn.Client＂实例。

而在调用该实例的run方法时，和Client部署模式一样，也会提交应用程序。具体代码如下。

3.Client与Cluster两种部署模式下调用的submitApplication方法解析

从Client与Cluster两种部署模式的入口源代码分析可得，两种模式下最终都调用了Client实例的submitApplication方法，因此继续分析该方法，具体源代码如下。

(www.xing528.com)

查看第27行中createContainerLaunchContext方法的关键源代码，如下所示。

从第10行与第18行代码可知，在Client模式下，AM的类为ExecutorLauncher，对应用户主类为Nil，而在Cluster模式下，AM的类为＂org.apache.spark.deploy.yarn.ApplicationMaster＂，对应用户主类为用户提交的应用程序的主类，即此时将用户提交的主类封装到了＂org. apache.spark.deploy.yarn.ApplicationMaster＂中。对应在ExecutorLauncher的入口方法中会调用＂org.apache.spark.deploy.yarn.ApplicationMaster＂的入口方法。

＂org.apache.spark.deploy.yarn.ApplicationMaster＂对应的入口方法中的关键代码如下。

在runDriver与runExecutorLauncher方法中，都会构建RPC通信终端，并调用register-AM，最终通过YARN API提供的org.apache.hadoop.yarn.client.api.AMRMClient向RM注册用户的ApplicationMaster。

因此在申请提交应用程序并启动之后，＂org.apache.spark.deploy.yarn.ApplicationMaster＂会在当前提交结点（Client部署模式）或集群分配的某个结点（Cluster部署模式）中的容器内启动。

下面继续分析AM启动之后，启动实际执行的Executor相关代码的源代码解析。

4.Client与Cluster两种部署模式下调用的Executor启动的解析

可以从Executor在集群中的通信接口出发解析源代码，接口的具体代码如下。

Executor所使用的可插拔接口的具体子类包含LocalBackend、MesosExecutorBackend和CoarseGrainedExecutorBackend，分别用于本地通信、Mesos集群模式下的通信和其他模式下的通信。

Spark on YANR集群中使用CoarseGrainedExecutorBackend作为Executor的通信端口，由AM负责向RM申请资源并发送到RM，最终由RM负责启动容器，执行CoarseGrainedExecu-torBackend。

从通信接口出发并查看CoarseGrainedExecutorBackend通信端最终在Spark on YARN集群中创建的位置，可以定位Executor的启动位置。

或者通过逐步源代码分析去查看，即通过注册AM之后的源代码逐步分析。

在Client与Cluster两种模式下，都会注册AM，即调用registerAM，对应的具体代码如下。

Executor通信接口的具体子类为CoarseGrainedExecutorBackend，执行的命令封装在Exec-utorRunnable类。

同样的，Sparkon Mesos的部署模型与Spark on YARN类似，仅仅针对不同的资源管理器Mesos提供的应用注册接口，来接入用户的应用程序。Mesos计算框架是一个集群管理器，提供了有效的、跨分布式应用或框架的资源隔离和共享，可以运行Hadoop、MPI、Hypert-able和Spark。使用ZooKeeper实现容错复制，使用Linux Containers来隔离任务，支持多种资源计划分配。Sparkon Mesos的部署模型与Spark on YARN等其他部署模型相比，主要差异在于Mesos本身的框架，以及对外提供的接入方式等。在此不再赘述。