“戏”说Spark-spark运行模式简解

“戏”说Spark-spark运行模式简解

简介

在“戏”说Spark---Spark初认识中我们知道Spark支持多种运行模式。Spark支持本地运行模式和集群运行模式。目前Apache Spark支持一种本地运行模式local，三种分布式运行方式（常用），分别是standalone、spark on mesos和 spark on YARN，其中，第一种类似于MapReduce 1.0所采用的模式，内部实现了容错性和资源管理，后两种则是未来发展的趋势，部分容错性和资源管理交由统一的资源管理系统完成：让Spark运行在一个通用的资源管理系统之上，这样可以与其他计算框架，比如MapReduce，公用一个集群资源，最大的好处是降低运维成本和提高资源利用率（资源按需分配）

注意：

• Local（只用于测试）---local单线程和local[n]多线程
• Standalone：独立模式资源管理框架
• Spark on yarn：最有前景的模式，hadoop的资源管理框架也是yarn
• Spark on Mesos：官方推荐，支持粗粒度和细粒度的资源管理框架
• Amazon EC2：亚马逊云的方式

概念

在理解Spark的各种运行模式之前，我们需要理解一些重要的概念,详细请查看“戏”说Spark---Spark架构和“戏”说spark---资源调度和任务调度

Spark应用程序执行过程中的术语

回顾Spark的架构图：

一：Spark On Local

本地模式下，只要将Spark包解压即可使用，不需要进行hadoop和Yarn的环境配置

本地模式下，所有的Spark进程均运行于同一个JVM中，并行处理则通过多线程来实现。在默认情况下，单机模式启动与本地系统的CPU核心数目相同的线程。如果要设置并行的级别，则以local[N]的格式来指定一个master变量，N表示要使用的线程数目。

二：Spark on Standalone

Standalone模式是Spark自带的资源调度框架，其主要的节点有Client节点、Master节点和Worker节点。其中Driver既可以运行在Master节点上中，也可以运行在本地Client端。当用spark-shell交互式工具提交Spark的Job时，Driver在Master节点上运行；当使用spark-submit工具提交Job或者在Eclips、IDEA等开发平台上使用”new SparkConf.setManager(“spark://master:7077”)”方式运行Spark任务时，Driver是运行在本地Client端上的。

Spark on Standalone应用程序的提交方式：Cluster提交和Client提交,默认采用的都是Client的方式提交。

1:以client方式提交到Standalone

(1):提交命令：

spark-submit --master spark://node1:7077 --class jar 100

提交命令--以提交Spark Pi为例：

./spark-submit --master spark://node1:7077 --class org.apache.spark.examples.SparkPi

../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

(2):运行流程：----概括性的描述

driver和client运行于同一JVM中，不由worker启动，该JVM进程直到spark application计算完成返回结果后才退出。如下图所示。

1： 使用SparkSubmit提交任务的时候，使用本地的Client类的main函数来创建sparkcontext并初始化它；

2：SparkContext连接到Master，注册并申请资源（内核和内存）。

3：Master根据SparkContext的资源申请要求和Worker心跳周期内报告的信息决定在哪个Worker上分配资源，然后在该Worker上获取资源，然后启动executor；

4：executor向SparkContext注册

5：SparkContext将应用分配给executor

6：executor创建Executor线程池，开始执行task，并向SparkContext汇报

7：所有的task执行完成之后，SparkContext向Master注销

2:以cluster方式提交Standalone

(1):提交命令：

spark-submit --master spark://node1:7077 --deploy-mode cluster --class client jar 100

提交命令--以提交Spark Pi为例：

./spark-submit --master spark://node1:7077 --deploy-mode cluster --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

(2):运行流程：----概括性的描述

在cluster模式下，driver由worker启动，client在确认spark application成功提交给cluster后直接退出，并不等待spark application运行结果返回。如下图所示

1： 使用SparkSubmit提交任务的时候，客户端申请启动一个Driver进程

2：Master随机选择一个Worker启动一个Driver进程，Driver创建sparkcontext并初始化它；

3： SparkContext连接到Master，注册并申请资源（内核和内存）。

4：Master根据SparkContext的资源申请要求和Worker心跳周期内报告的信息决定在哪个Worker上分配资源，然后在该Worker上获取资源，然后启动executor；

5：executor向SparkContext注册

6：SparkContext将应用分配给executor

7：executor创建Executor线程池，开始执行task，并向SparkContext汇报

8：所有的task执行完成之后，SparkContext向Master注销

以client方式提交到Standalone和以cluster方式提交Standalone的区别

（1）：Driver所在的节点不同：

以client方式提交，Driver在Client端创建；以cluster方式提交，Driver在随机的Worker上创建

（2）：运行结果的返回不同：

以client方式提交，运行结果返回Client端；以cluster方式提交，运行结果返回Driver所在的Worker节点

小结：

即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说，该模式是其他两种的基础。借鉴Spark开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的standalone模式，为了快速开发，起初不需要考虑服务（比如master/slave）的容错性，之后再开发相应的wrapper，将stanlone模式下的服务原封不动的部署到资源管理系统yarn或者mesos上，由资源管理系统负责服务本身的容错。目前Spark在standalone模式下是没有任何单点故障问题的，这是借助zookeeper实现的，思想类似于Hbase master单点故障解决方案。将Spark standalone与MapReduce比较，会发现它们两个在架构上是完全一致的： 

　　1)  都是由master/slaves服务组成的，且起初master均存在单点故障，后来均通过zookeeper解决（Apache MRv1的JobTracker仍存在单点问题，但CDH版本得到了解决）； 

　　2) 各个节点上的资源被抽象成粗粒度的slot，有多少slot就能同时运行多少task。不同的是，MapReduce将slot分为map slot和reduce slot，它们分别只能供Map Task和Reduce Task使用，而不能共享，这是MapReduce资源利率低效的原因之一，而Spark则更优化一些，它不区分slot类型，只有一种slot，可以供各种类型的Task使用，这种方式可以提高资源利用率，但是不够灵活，不能为不同类型的Task定制slot资源。总之，这两种方式各有优缺点。

三：Spark on yarn

前提：以yarn的方式提交Spark应用程序需要启动yarn集群并进行Spark的相关配置

1：启动yarn集群

2：在client上Spark安装包下面配置spark-env.sh:指定hadoop配置文件的目录:目的是driver寻找yarn的resourceManager申请资源

export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

1:以client方式提交到yarn

(1):提交命令：

./spark-submit --master yarn-client --class ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

提交命令--以提交Spark Pi为例：

./spark-submit --master yarn-clien --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

(2):运行流程：----概括性的描述

Yarn-Client模式中，Driver在客户端本地运行，这种模式可以使得Spark Application和客户端进行交互，因为Driver在客户端，所以可以通过webUI访问Driver的状态，默认是http://node1:4040访问，而YARN通过http:// node1:8088访问。

1：在client本地启动一个Driver进程

2：Client会向ResourceManager发送请求，申请启动一个ApplicationMaster进程

3：ResourceManager接收请求后，随机找一台NodeManager启动一个ApplicationMaster

4：ApplicationMaster启动后会向ResourceManager申请资源container

5：资源申请好后，Driver调度任务开始执行Application

6：执行结果返回Client端

2:以cluster方式提交yarn

(1):提交命令：

./spark-submit --master yarn-cluster --class ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

提交命令--以提交Spark Pi为例：

./spark-submit --master yarn-cluster --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100

(2):运行流程：----概括性的描述

在YARN-Cluster模式中，当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：第一个阶段是把Spark的Driver作为一个ApplicationMaster在YARN集群中先启动；第二个阶段是由ApplicationMaster创建应用程序，然后为它向ResourceManager申请资源，并启动Executor来运行Task，同时监控它的整个运行过程，直到运行完成。

1：客户端向ResourceManager提交一个请求，申请启动一个Driver

2：ResourceManager接收请求，找一台NodeManager启动一个Driver进程

注意：ApplicationMaster就是Driver

3：Driver会向ResourceManager发送请求，为当前的ApplicationMaster申请资源

4：资源请求完毕后，Application开始执行

以client方式提交到Standalone和以cluster方式提交yarn的区别

（1）：Driver所在的节点不同：

以client方式提交，Driver在Client端创建；以cluster方式提交，Driver在随机的NodeManager上创建

运行结果的返回不同：

以client方式提交，运行结果返回Client端；以cluster方式提交，运行结果返回Driver所在的（）（）（2）：NodeManager节点

注意：以cluster方式提交，ApplicationMaster进程就是Driver进程

yarn-cluster：适用于生产环境； 

yarn-client：适用于交互、调试，希望立即看到app的输出 

小结：

这是一种很有前景的部署模式。但限于YARN自身的发展，目前仅支持粗粒度模式（Coarse-grained Mode）。这是由于YARN上的Container资源是不可以动态伸缩的，一旦Container启动之后，可使用的资源不能再发生变化，不过这个已经在YARN计划中了。 

spark on yarn 的支持两种模式： 

(1):yarn-cluster：适用于生产环境； 

yarn-client：适用于交互、调试，希望立即看到app的输出 

(2):yarn-cluster和yarn-client的区别在于yarn appMaster，每个yarn app实例有一个appMaster进程，是为app启动的第一个container；负责从ResourceManager请求资源，获取到资源后，告诉NodeManager为其启动container。yarn-cluster和yarn-client模式内部实现还是有很大的区别。如果你需要用于生产环境，那么请选择yarn-cluster；而如果你仅仅是Debug程序，可以选择yarn-client。

四：Spark on Mesos

关于Spark on Mesos的安装部署请参考博客：Spark on Mesos部署:

http://blog.csdn.net/lsshlsw/article/details/47008165

http://ifeve.com/spark-mesos-spark/

spark on mesos 有粗粒度(coarse-grained)和细粒度(fine-grained)两种运行模式，细粒度模式在spark2.0后开始弃用。

Spark on Mesos是很多公司采用的模式，官方推荐这种模式（当然，原因之一是血缘关系）。正是由于Spark开发之初就考虑到支持Mesos，因此，目前而言，Spark运行在Mesos上会比运行在YARN上更加灵活，更加自然。目前在Spark On Mesos环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考Andrew Xia的“Mesos Scheduling Mode on Spark”）：

1)   粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个Dirver和若干个Executor组成，其中，每个Executor占用若干资源，内部可运行多个Task（对应多少个“slot”）。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。举个例子，比如你提交应用程序时，指定使用5个executor运行你的应用程序，每个executor占用5GB内存和5个CPU，每个executor内部设置了5个slot，则Mesos需要先为executor分配资源并启动它们，之后开始调度任务。另外，在程序运行过程中，mesos的master和slave并不知道executor内部各个task的运行情况，executor直接将任务状态通过内部的通信机制汇报给Driver，从一定程度上可以认为，每个应用程序利用mesos搭建了一个虚拟集群自己使用。

2)   细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资源浪费，Spark On Mesos还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。与粗粒度模式一样，应用程序启动时，先会启动executor，但每个executor占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos会为每个executor动态分配资源，每分配一些，便可以运行一个新任务，单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于MapReduce调度模式，每个Task完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。

总结:

思考？？？

不管是Spark应用程序Spark on Standalone或者Spark on yarn都有Client和Cluster两种提交方式，为什么要设置Client和Cluster两种不同的提交方式呢？

1：总是以Client的方式提交应用程序，会导致Client所在的节点频繁的和集群通信，导致Client节点的网卡流量激增，Driver占用大量的网络带宽，使得client节点比较卡

2：Cluster方式能够解决多次网卡流量激增的问题，将其均摊到worker进程所在的节点上，但是无法解决单次网卡流量激增的问题

注意区别：以yarn的方式提交应用程序，Driver进程的角色会不一样

Client的方式提交，Driver只是负责任务的调度

Cluster的方式提交，Driver即负责任务的调度，又负责资源的申请

关于一些端口的总结：

HDFS WEBUI的访问端口是：50070

HDFS HA RPC的访问端口是8020

HDFS RPC的访问端口是9000

yarn集群的WEB UI的访问端口是 8088

Standalone集群的 Master的WEBUI的访问端口是8080

Standalone集群的Worker节点的WEBUI的访问端口是8081

Driver进程的WEBUI的访问端口是4040

注意：Driver进程的名称;DriverWrapper

关于Driver作用的总结？

Driver与集群的通信：

1：任务的分发

2：结果的回收

3：监控task的执行情况

4：Driver负责向master申请资源

三种分布式部署方式各有利弊对比

这三种分布式部署方式各有利弊，通常需要根据实际情况决定采用哪种方案。进行方案选择时，往往要考虑公司的技术路线（采用Hadoop生态系统还是其他生态系统）、相关技术人才储备等。上面涉及到Spark的许多部署模式，究竟哪种模式好这个很难说，需要根据你的需求，如果你只是测试Spark Application，你可以选择local模式。而如果你数据量不是很多，Standalone 是个不错的选择。当你需要统一管理集群资源（Hadoop、Spark等），那么你可以选择Yarn或者mesos，但是这样维护成本就会变高。 

(1):从对比上看，mesos似乎是Spark更好的选择，也是被官方推荐的 

(2):但如果你同时运行hadoop和Spark,从兼容性上考虑，Yarn是更好的选择。 · 如果你不仅运行了hadoop，spark。还在资源管理上运行了docker，Mesos更加通用。 

(3):Standalone对于小规模计算集群更适合！

以思维导图构建你的知识体系：

参考：

http://www.cnblogs.com/chushiyaoyue/p/7093695.html

http://www.cnblogs.com/zlslch/p/6628693.html

http://dongxicheng.org/framework-on-yarn/apache-spark-comparing-three-deploying-ways/