spark yarn 提交_Spark系列--提交任务流程

1.Spark基于StandaLone的任务提交模式

StandaLone提交任务有两种模式，一种是基于客户端Client提交任务，另一种是集群cluster提交任务。

首先来看基于客户端提交任务：

提交命令为：

./spark-submit --master spark://node1:7077 --deploy-mode client --class jar包

它执行的流程大致如下：

1.当有了客户端后，就会有了相应的master与worker节点，并且当集群启动的时候，worker会向master汇报资源(核，内存等)，然后master就会掌握了worker的资源。

2.这时，当客户端提交Spark application时，Driver会首先在客户端启动，Driver启动之后，客户端会向Master申请资源。

3.Master会找到满足客户端请求资源的Worker节点，并且会去启动一个executor，executor就相当于Hadoop里面的Container，就是申请一批container来执行task任务，而Executor是一个进程，它会准备一个线程池，就是pool task，也是是去执行任务的。当executor启动成功后，会向driver反向注册，也就是告诉driver，我已经准备好了，你可以向我发送task任务了。

4.Driver直接向Executor发送task，并且监控task，将executor执行的结果给回收回来。

但是这种模式是有问题得的：

首先driver是在客户端启动的，每提交一个spark任务后，每个apllication都会启动一个driver，每一个任务都会有一个独立的Driver，Driver与集群中的worker会有很多的通信，如果在客户端提交大量的application，有可能会造成客户端网卡流量激增的问题，可以在客户端看到task的执行与结果，这种模式可以用于平时的测试状态。

standalone还有基于集群的提交模式

该模式的命令为：

./spark-submit --master spark://node1:7077 --deploy-mode cluster --class jar包

该模式的执行流程为：

1.当集群启动的时候，worker会向master汇报资源，然后master就会掌握worker的集群信息。

2.客户端会提交Spark Application，这时客户端会向Master申请启动Driver。

3.Master会随机找到一个满足资源的Worker节点启动diver，这时当driver启动后，driver会向master申请资源用于application启动。

4.Master收到请求后会找到满足资源的节点去启动executor，每个executor里面会有线程池threadpool。

5.executor启动会向driver注册，driver向executor发送task，并且回收处理的解果。

Driver进程是在集群某一台Worker上启动的，在客户端是无法查看task的执行情况的。假设要提交100个application到集群运行,每次Driver会随机在集群中某一台Worker上启动，那么这100次网卡流量暴增的问题就散布在集群上。这种模式适合于生产环境，运行的状态要在web UI上面查看详细的信息。

2.Spark基于Yarn提交任务模式

它也有两种方式，一种是client客户端，另一种是cluster集群方式

提交任务的命令是：

./spark-submit --master yarn --class jar包

执行任务的流程大致是这样的：

因为Yarn有自己资源管理的模式，所以在这种模式下，由resourceManager来掌握集群的资源，

1.当启动后，nodeManager会向resourcemanager汇报资源，而RM会掌握NM的资源。

2.当在客户端提交SparkApplication时，Driver会在客户端启动，客户端会向RM申请启动ApplicationMaster(在hadoop2.0后，负责任务调度)。

3.RM 收到请求会向随机找一个满足资源的NM启动Application Master，AM启动后，会向RM申请资源用于启动executor，RM会返回一批NM节点给AM，AM收到返回结果后，会真正的向NM中去启动executor，每个executor中会有线程池。

4.executor启动后会向Driver注册，Driver会向executor发送task，并且监控task执行，收回task执行的结果。

它的问题在于：因为Driver运行在本地，Driver会与yarn集群中的Executor进行大量的通信，会造成客户机网卡流量的大量增加，可以在客户端看到task的执行和结果.Yarn-client模式同样是适用于测试。

ApplicationMaster的作用：

1. 为当前的Application申请资源

2. 给NameNode发送消息启动Executor。

注意：ApplicationMaster有launchExecutor和申请资源的功能，并没有作业调度的功能。

2.第二种模式时基于Yarn cluster模式执行的。

它的命令如下：

./spark-submit --master yarn --deploy-mode cluster --class jar包

它的执行流程是这样的：

1.启动集群后，NM会向RM汇报资源，而RM就掌握了集群的资源。

2.当客户端提交Spark Appliction。会向RM申请启动ApplictaionMaster，而RM会随机找到一个满足资源的NM去启动AM。

3.当AM启动之后它负责任务调度，所以这里就不启动Driver，而AM就相当于Driver一样的功能存在。

http://4.AM启动后会向RM申请启动Executor，每个Executor会由线程池，RM会返回一批满足资源的NM节点。

http://5.AM接收到返回结果会找到相应的NM，启动Executor，executor启动后会向AM注册，而AM会将task发送到executor去执行，并且监控task，回收task'处理的结果。

Yarn-Cluster主要用于生产环境中，因为Driver运行在Yarn集群中某一台nodeManager中，每次提交任务的Driver所在的机器都是随机的，不会产生某一台机器网卡流量激增的现象，缺点是任务提交后不能看到日志。只能通过yarn查看日志。

ApplicationMaster的作用：

1. 为当前的Application申请资源

2. 给NameNode发送消息启动Excutor。

3. 任务调度。

停止集群任务命令：yarn application -kill applicationID

有兴趣的童鞋可以关注公众号一起讨论学习进步。