spark多种运行模式【基于原理讲述】

1. 本地模式

该模式被称为Local[N]模式，是用单机的多个线程来模拟Spark分布式计算，通常用来验证开发出来的应用程序逻辑上有没有问题。

其中N代表可以使用N个线程，每个线程拥有一个core。如果不指定N，则默认是1个线程（该线程有1个core）。

如果是local[*]，则代表 Run Spark locally with as many worker threads as logical cores on your machine.

如下：

spark-submit 和 spark-submit –master local 效果是一样的

（同理：spark-shell 和 spark-shell –master local 效果是一样的）

spark-submit –master local[4] 代表会有4个线程（每个线程一个core）来并发执行应用程序。

那么，这些线程都运行在什么进程下呢？后面会说到，请接着往下看。

运行该模式非常简单，只需要把Spark的安装包解压后，改一些常用的配置即可使用，而不用启动Spark的Master、Worker守护进程( 只有集群的Standalone方式时，才需要这两个角色)，也不用启动Hadoop的各服务（除非你要用到HDFS），这是和其他模式的区别哦，要记住才能理解。

那么，这些执行任务的线程，到底是共享在什么进程中呢？

我们用如下命令提交作业：

spark-submit –class org.apache.spark.examples.JavaWordCount –master local[*] spark-examples_2.11-2.3.1.jar file:///opt/README.md

可以看到，在程序执行过程中，只会生成一个SparkSubmit进程。

这个SparkSubmit进程又当爹、又当妈，既是客户提交任务的Client进程、又是Spark的driver程序、还充当着Spark执行Task的Executor角色。（如下图所示：driver的web ui）

这里有个小插曲，因为driver程序在应用程序结束后就会终止，那么如何在web界面看到该应用程序的执行情况呢，需要如此这般：（如下图所示）

先在spark-env.sh 增加SPARK_HISTORY_OPTS；

export SPARK_HISTORY_OPTS="-Dspark.history.ui.port=18080 
-Dspark.history.retainedApplications=3
-Dspark.history.fs.logDirectory=hdfs://192.168.5.60:9000/history"

然后启动start-history-server.sh服务；

就可以看到启动了HistoryServer进程，且监听端口是18080。

之后就可以在web上使用http://hostname:18080愉快的玩耍了。

2，测试或实验性质的本地伪集群运行模式（单机模拟集群）

这种运行模式，和Local[N]很像，不同的是，它会在单机启动多个进程来模拟集群下的分布式场景，而不像Local[N]这种多个线程只能在一个进程下委屈求全的共享资源。通常也是用来验证开发出来的应用程序逻辑上有没有问题，或者想使用Spark的计算框架而没有太多资源。

用法是：提交应用程序时使用local-cluster[x,y,z]参数：x代表要生成的executor数，y和z分别代表每个executor所拥有的core和memory数。

spark-submit –master local-cluster[2, 3, 1024]

（同理：spark-shell –master local-cluster[2, 3, 1024]用法也是一样的）

上面这条命令代表会使用2个executor进程，每个进程分配3个core和1G的内存，来运行应用程序。可以看到，在程序执行过程中，会生成如下几个进程：

SparkSubmit依然充当全能角色，又是Client进程，又是driver程序，还有点资源管理的作用。生成的两个CoarseGrainedExecutorBackend，就是用来并发执行程序的进程。它们使用的资源如下：

运行该模式依然非常简单，只需要把Spark的安装包解压后，改一些常用的配置即可使用。而不用启动Spark的Master、Worker守护进程( 只有集群的standalone方式时，才需要这两个角色)，也不用启动Hadoop的各服务（除非你要用到HDFS），这是和其他模式的区别哦，要记住才能理解。下面说说集群上的运行模式。

3，Spark自带Cluster Manager的Standalone Client模式（集群）

终于说到了体现分布式计算价值的地方了！（有了前面的基础，后面的内容我会稍微说快一点，只讲本文的关注点）

和单机运行的模式不同，这里必须在执行应用程序前，先启动Spark的Master和Worker守护进程。不用启动Hadoop服务，除非你用到了HDFS的内容。

start-master.sh

start-slave.sh -h hostname url:master

图省事，可以在想要做为Master的节点上用start-all.sh一条命令即可，不过这样做，和上面的分开配置有点差别，以后讲到数据本地性如何验证时会说。

启动的进程如下：（其他非Master节点上只会有Worker进程）

这种运行模式，可以使用Spark的8080 web ui来观察资源和应用程序的执行情况了。利用8080端口。

可以看到，当前环境下，我启动了2个worker进程，每个worker可使用的core是1个，内存1024M。

言归正传，用如下命令提交应用程序

spark-submit –master spark://wl1:7077

或者 spark-submit –master spark://wl1:7077 –deploy-mode client

代表着会在所有有Worker进程的节点上启动Executor来执行应用程序，此时产生的JVM进程如下：（非master节点，除了没有Master、SparkSubmit，其他进程都一样）

Master进程做为cluster manager，用来对应用程序申请的资源进行管理；

SparkSubmit 做为Client端和运行driver程序；

CoarseGrainedExecutorBackend 用来并发执行应用程序；

注意，Worker进程生成几个Executor，每个Executor使用几个core，这些都可以在spark-env.sh里面配置，此处不在啰嗦。

这是driver web ui的显示，可以看到每个executor的资源使用情况

4，spark自带cluster manager的standalone cluster模式（集群）

这种运行模式和上面第3个还是有很大的区别的。使用如下命令执行应用程序（前提是已经启动了spark的Master、Worker守护进程）不用启动Hadoop服务，除非你用到了HDFS的内容。

spark-submit –master spark://wl1:6066 –deploy-mode cluster

各节点启动的JVM进程情况如下：

master节点上的进程

提交应用程序的客户端上的进程

客户端的SparkSubmit进程会在应用程序提交给集群之后就退出（区别1）

Master会在集群中选择一个Worker进程生成一个子进程DriverWrapper来启动driver程序(区别2)

而该DriverWrapper 进程会占用Worker进程的一个core，所以同样的资源下配置下，会比第3种运行模式，少用1个core来参与计算。

应用程序的结果，会在执行driver程序的节点的stdout中输出，而不是打印在屏幕上（区别4）

5，基于YARN的Resource Manager的Client模式（集群）

现在越来越多的场景，都是Spark跑在Hadoop集群中，所以为了做到资源能够均衡调度，会使用YARN来做为Spark的Cluster Manager，来为Spark的应用程序分配资源。

在执行Spark应用程序前，要启动Hadoop的各种服务。由于已经有了资源管理器，所以不需要启动Spark的Master、Worker守护进程。相关配置的修改，请自行研究。

使用如下命令执行应用程序

spark-submit –master yarn

或者 spark-submit –master yarn –deploy-mode client

提交应用程序后，各节点会启动相关的JVM进程，如下：

在Resource Manager节点上提交应用程序，会生成SparkSubmit进程，该进程会执行driver程序。

RM会在集群中的某个NodeManager上，启动一个ExecutorLauncher进程，来做为

ApplicationMaster。
另外，也会在多个NodeManager上生成CoarseGrainedExecutorBackend进程来并发的执行应用程序

对应的YARN资源管理的单元Container，关系如下：

6，基于YARN的Resource Manager的Custer模式（集群）

使用如下命令执行应用程序:

spark-submit –master yarn –deploy-mode cluster

和第5种运行模式，区别如下：

在Resource Manager端提交应用程序，会生成SparkSubmit进程，该进程只用来做Client端，应用程序提交给集群后，就会删除该进程。

Resource Manager在集群中的某个NodeManager上运行ApplicationMaster，该AM同时会执行driver程序。紧接着，会在各NodeManager上运行CoarseGrainedExecutorBackend来并发执行应用程序。

应用程序的结果，会在执行driver程序的节点的stdout中输出，而不是打印在屏幕上。

对应的YARN资源管理的单元Container，关系如下：

为ApplicationMaster生成了容器 000001
为CoarseGrainedExecutorBackend生成了容器 000004-000002

---

附spark常见术语：

Application: Appliction都是指用户编写的Spark应用程序，其中包括一个Driver功能的代码和分布在集群中多个节点上运行的Executor代码

Driver: Spark中的Driver即运行上述Application的main函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负责与ClusterManager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同时负责将SparkContext关闭，通常用SparkContext代表Driver

Executor: 某个Application运行在worker节点上的一个进程， 该进程负责运行某些Task， 并且负责将数据存到内存或磁盘上，每个Application都有各自独立的一批Executor， 在Spark on Yarn模式下，其进程名称为CoarseGrainedExecutor Backend。一个CoarseGrainedExecutor Backend有且仅有一个Executor对象， 负责将Task包装成taskRunner,并从线程池中抽取一个空闲线程运行Task， 每一个coarseGrainedExecutor Backend能并行运行Task的数量取决与分配给它的cpu个数

Cluster Manager：指的是在集群上获取资源的外部服务。目前有三种类型
Standalone: spark原生的资源管理，由Master负责资源的分配
Apache Mesos:与hadoop MR兼容性良好的一种资源调度框架
Hadoop Yarn: 主要是指Yarn中的ResourceManager

Worker: 集群中任何可以运行Application代码的节点，在Standalone模式中指的是通过slave文件配置的Worker节点，在Spark on Yarn模式下就是NoteManager节点

Job: 包含多个Task组成的并行计算，往往由Spark Action触发生成， 一个Application中往往会产生多个Job

Stage: 每个Job会被拆分成多组Task， 作为一个TaskSet， 其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生shuffle的地方

DAGScheduler: 根据Job构建基于Stage的DAG（Directed Acyclic Graph有向无环图)，并提交Stage给TASkScheduler。 其划分Stage的依据是RDD之间的依赖的关系找出开销最小的调度方法。

TASKSedulter: 将TaskSET提交给worker运行，每个Executor运行什么Task就是在此处分配的. TaskScheduler维护所有TaskSet，当Executor向Driver发生心跳时，TaskScheduler会根据资源剩余情况分配相应的Task。另外TaskScheduler还维护着所有Task的运行标签，重试失败的Task。下图展示了TaskScheduler的作用

在不同运行模式中任务调度器具体为：
Spark on Standalone模式为TaskScheduler
YARN-Client模式为YarnClientClusterScheduler
YARN-Cluster模式为YarnClusterScheduler
将这些术语串起来的运行层次图如下：

Job=多个stage，Stage=多个同种task, Task分为ShuffleMapTask和ResultTask，Dependency分为ShuffleDependency和NarrowDependency