本文详细介绍了Spark在Standalone和Yarn模式下的任务提交方式，包括client和cluster模式的区别，以及这两种模式下的执行流程。同时，文章还提到了Spark任务执行中的关键概念，如Driver、Executor和ApplicationMaster，以及资源调度和任务调度的流程。
一、Spark任务执行
上一篇有提到Spark任务的运行模式包括Standalone和Yarn，这里谈谈两种模式的区别。
1.1、Standalone模式（两种提交）
1.1.1、Standalone-client提交任务方式
提交命令：
./spark-submit --master spark://node1:7077 --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 1000
或
./spark-submit --master spark://node1:7077 --deploy-mode client --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 100
执行原理图解:
执行流程：
1、client模式提交任务后，会在客户端启动Driver进程。
2、Driver会向Master申请启动Application启动的资源。
3、资源申请成功，Driver端将task发送到worker端执行。
4、Worker端将task执行结果返回到Driver端。
总结：
client模式适用于测试调试程序。Driver进程是在客户端启动的，这里的客户端就是指提交应用程序的当前节点。这里的客户端就是指提交应用程序的当前节点。
在Driver端可以看到task执行的情况。生产环境下不能使用client模式，原因是：假设要提交100个application到集群运行，Driver每次都会在client端启动，那么就会导致客户端100次网卡流量暴增的问题。
1.1.2、Standalone-cluster提交任务方式
提交命令：
./spark-submit --master spark://node1:7077 --deploy-mode cluster --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 100
注意：Standalone-cluster提交方式，应用程序使用的所有jar包和文件，必须保证所有的worker节点都要有，因为此种方式，spark不会自动上传包。
解决方式：
①将所有的依赖包和文件打到同一个包中，然后放在hdfs上。
②将所有的依赖包和文件各放一份在worker节点上。
执行原理图：
执行流程：
1、cluster模式提交应用程序后，会向Master请求启动Driver。
2、Master接受请求，随机在集群一台节点启动Driver进程。
3、Driver启动后为当前的应用程序申请资源。
4、Driver端发送task到worker节点上执行。
5、worker将执行情况和执行结果返回给Driver端。
总结：
Driver进程是在集群某一台worker上启动的，在客户端是无法查看task的执行情况的。假设要提交100个application到集群运行,每次Driver会随机在集群中某一台Worker上启动，那么这100次网卡流量暴增的问题就散布在集群上。
Standalone两种方式提交任务，Driver与集群的通信包括：
1、Driver负责应用程序资源的申请
2、任务的分发。
3、结果的回收
4、监控task执行情况。
1.2、Yarn模式（两种提交）
1.2.1、yarn-client提交任务方式
提交命令：
./spark-submit --master yarn --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 100
或
./spark-submit --master yarn–client --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 100
或
./spark-submit --master yarn --deploy-mode client --class org.apache.spark.examples.SparkPi
../examples/jars/spark-examples_2.11-2.2.1.jar 100
执行原理图：
执行流程：
1、客户端提交一个Application，在客户端启动一个Driver进程。
2、应用程序启动后会向RS（ResourceManager）发送请求，启动AM(ApplicationMaster)的资源。
3、 RS收到请求，随机选择一台NM(NodeManager)启动AM。这里的NM相当于Standalone中的Worker节点。
4、AM启动后，会向RS请求一批container资源，用于启动Executor。
5、RS会找到一批NM返回给AM,用于启动Executor。
6、AM会向NM发送命令启动Executor。
7、Executor启动后，会反向注册给Driver，Driver发送task到Executor，执行情况和结果返回给Driver端。
总结：
Yarn-client模式同样是适用于测试，因为Driver运行在本地，Driver会与yarn集群中的Executor进行大量的通信，会造成客户机网卡流量的大量增加.
ApplicationMaster的作用：
1、为当前的Application申请资源
2、给NodeManager发送消息启动Executor。
注意：ApplicationMaster有launchExecutor和申请资源的功能，并没有作业调度的功能。
1.2.2、yarn-cluster提交任务方式
提交命令：
./spark-submit --master yarn --deploy-mode cluster --class org.apache.spark.examples.SparkPi
../examples/jars/spark-examples_2.11-2.2.1.jar 100
或
./spark-submit --master yarn-cluster --class org.apache.spark.examples.SparkPi ../examples/jars/spark-examples_2.11-2.2.1.jar 100
执行原理图：
执行流程：
①客户机提交Application应用程序，发送请求到RS(ResourceManager),请求启动AM(ApplicationMaster)。
②RS收到请求后随机在一台NM(NodeManager)上启动AM（相当于Driver端）。
③AM启动，AM发送请求到RS，请求一批container用于启动Excutor。
④RS返回一批NM节点给AM。
⑤AM连接到NM,发送请求到NM启动Excutor。
⑥Excutor反向注册到AM所在的节点的Driver。Driver发送task到Excutor。
总结：
Yarn-Cluster主要用于生产环境中，因为Driver运行在Yarn集群中某一台nodeManager中，每次提交任务的Driver所在的机器都是随机的，不会产生某一台机器网卡流量激增的现象，缺点是任务提交后不能看到日志。只能通过yarn查看日志。
ApplicationMaster的作用：
1、为当前的Application申请资源
2、给NodeManger发送消息启动Excutor。
3、任务调度。
停止集群任务命令：yarn application -kill applicationID
二、补充部分算子
2.1、transformation
1、join,leftOuterJoin,rightOuterJoin,fullOuterJoin
作用在K,V格式的RDD上。根据K进行连接，对（K,V）join(K,W)返回（K,(V,W)）
¬ join后的分区数与父RDD分区数多的那一个相同。
2、union
合并两个数据集。两个数据集的类型要一致。
¬ 返回新的RDD的分区数是合并RDD分区数的总和。
3、intersection
取两个数据集的交集
4、subtract
取两个数据集的差集
5、mapPartition
与map类似，遍历的单位是每个partition上的数据。
6、distinct(map+reduceByKey+map)
7、cogroup
当调用类型（K,V）和（K，W）的数据上时，返回一个数据集（K，（Iterable,Iterable））
2.2、action
foreachPartition
遍历的数据是每个partition的数据。
三、术语解释
四、窄依赖和宽依赖
RDD之间有一系列的依赖关系，依赖关系又分为窄依赖和宽依赖。
窄依赖
父RDD和子RDD partition之间的关系是一对一或者多对一，不会有shuffle的产生。
宽依赖
父RDD与子RDD partition之间的关系是一对多。会有shuffle的产生。
宽窄依赖图理解
五、Stage
Spark任务会根据RDD之间的依赖关系，形成一个DAG有向无环图，DAG会提交给DAGScheduler，DAGScheduler会把DAG划分相互依赖的多个stage，划分stage的依据就是RDD之间的宽窄依赖。遇到宽依赖就划分stage,每个stage包含一个或多个task任务。然后将这些task以taskSet的形式提交给TaskScheduler运行。
stage是由一组并行的task组成。
stage切割规则：
切割规则：从后往前，遇到宽依赖就切割stage。
stage计算模式：
pipeline管道计算模式,pipeline只是一种计算思想，模式。
数据一直在管道里面什么时候数据会落地？
①对RDD进行持久化。
②shuffle write的时候。
Stage的task并行度是由stage的最后一个RDD的分区数来决定的 。
如何改变RDD的分区数？
例如：reduceByKey(XXX,3),GroupByKey(4)
测试验证pipeline计算模式：
val conf = new SparkConf()
conf.setMaster("local").setAppName("pipeline");
val sc = new SparkContext(conf)
val rdd = sc.parallelize(Array(1,2,3,4))
val rdd1 = rdd.map { x => {
println("map--------"+x)
x
}}
val rdd2 = rdd1.filter { x => {
println("fliter********"+x)
true
} }
rdd2.collect()
sc.stop()六、Spark资源调度和任务调度
6.1、Spark资源调度和任务调度的流程
启动集群后，Worker节点会向Master节点汇报资源情况，Master掌握了集群资源情况。当Spark提交一个Application后，根据RDD之间的依赖关系将Application形成一个DAG有向无环图。任务提交后，Spark会在Driver端创建两个对象：DAGScheduler和TaskScheduler，DAGScheduler是任务调度的高层调度器，是一个对象。DAGScheduler的主要作用就是将DAG根据RDD之间的宽窄依赖关系划分为一个个的Stage，然后将这些Stage以TaskSet的形式提交给TaskScheduler（TaskScheduler是任务调度的低层调度器，这里TaskSet其实就是一个集合，里面封装的就是一个个的task任务,也就是stage中的并行度task任务），TaskSchedule会遍历TaskSet集合，拿到每个task后会将task发送到计算节点Executor中去执行（其实就是发送到Executor中的线程池ThreadPool去执行）。task在Executor线程池中的运行情况会向TaskScheduler反馈，当task执行失败时，则由TaskScheduler负责重试，将task重新发送给Executor去执行，默认重试3次。如果重试3次依然失败，那么这个task所在的stage就失败了。stage失败了则由DAGScheduler来负责重试，重新发送TaskSet到TaskSchdeuler，Stage默认重试4次。如果重试4次以后依然失败，那么这个job就失败了。job失败了，Application就失败了。
TaskScheduler不仅能重试失败的task,还会重试straggling（落后，缓慢）task（也就是执行速度比其他task慢太多的task）。如果有运行缓慢的task那么TaskScheduler会启动一个新的task来与这个运行缓慢的task执行相同的处理逻辑。两个task哪个先执行完，就以哪个task的执行结果为准。这就是Spark的推测执行机制。在Spark中推测执行默认是关闭的。
推测执行可以通过spark.speculation属性来配置。
注意：
对于ETL类型要入数据库的业务要关闭推测执行机制，这样就不会有重复的数据入库。
如果遇到数据倾斜的情况，开启推测执行则有可能导致一直会有task重新启动处理相同的逻辑，任务可能一直处于处理不完的状态。
6.2、图解Spark资源调度和任务调度的流程
6.3、粗粒度资源申请和细粒度资源申请
6.3.1、粗粒度资源申请(Spark）
在Application执行之前，将所有的资源申请完毕，当资源申请成功后，才会进行任务的调度，当所有的task执行完成后，才会释放这部分资源。
优点：
在Application执行之前，所有的资源都申请完毕，每一个task直接使用资源就可以了，不需要task在执行前自己去申请资源，task启动就快了，task执行快了，stage执行就快了，job就快了，application执行就快了。
缺点：直到最后一个task执行完成才会释放资源，集群的资源无法充分利用。
6.3.2、细粒度资源申请（MR）
Application执行之前不需要先去申请资源，而是直接执行，让job中的每一个task在执行前自己去申请资源，task执行完成就释放资源。
优点：集群的资源可以充分利用。
缺点：task自己去申请资源，task启动变慢，Application的运行就响应的变慢了。
扫一扫
461
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
