Spark详解

最近查了很多Spark相关的资料，把其中写的比较好的做了系统的整理，现在分享给大家！有不对或不完善的地方请大家指正批评！

目录

1、Spark的特点

2、Spark基本概念

2.1、Spark组件的概念

3、Spark基本架构

4、spark运行流程

5、Spark核心功能

6、Spark扩展功能

7、RDD运行流程

8、Spark模块设计

9、Spark编程模型

10、Spark计算模型

11、Spark运行模式

11.1. Standalone模式

11.2、Spark On Mesos模式

11.3、Spark On YARN模式

12、Spark应用提交与执行

1、Spark的特点

---

• 快速处理能力。随着实时大数据应用越来越多，Hadoop作为离线的高吞吐、低响应框架已不能满足这类需求。HadoopMapReduce的Job将中间输出和结果存储在HDFS中，读写HDFS造成磁盘IO成为瓶颈。Spark允许将中间输出和结果存储在内存中，节省了大量的磁盘IO。同时Spark自身的DAG执行引擎也支持数据在内存中的计算。Spark官网声称性能比Hadoop快100倍，如图所示。即便是内存不足需要磁盘IO，其速度也是Hadoop的10倍以上。

图1-1 Hadoop与Spark执行逻辑回归时间比较

• 易于使用。Spark现在支持Java、Scala、Python和R等语言编写应用程序，大大降低了使用者的门槛。自带了80多个高等级操作符，允许在Scala，Python，R的shell中进行交互式查询。
• 支持查询。Spark支持SQL及Hive SQL对数据查询。
• 支持流式计算。与MapReduce只能处理离线数据相比，Spark还支持实时的流计算。Spark依赖Spark Streaming对数据进行实时的处理，其流式处理能力还要强于Storm。
• 可用性高。Spark自身实现了Standalone部署模式，此模式下的Master可以有多个，解决了单点故障问题。此模式完全可以使用其他集群管理器替换，比如YARN、Mesos、EC2等。
• 丰富的数据源支持。Spark除了可以访问操作系统自身的文件系统和HDFS，还可以访问Cassandra, HBase, Hive, Tachyon以及任何Hadoop的数据源。这极大地方便了已经使用HDFS、Hbase的用户顺利迁移到Spark。

2、Spark基本概念

---

• mater:主要是控制、管理和监督整个spark集群。
• client：客户端，将用应用程序提交，记录着要业务运行逻辑和master通讯。
• sparkContext：spark应用程序的入口，负责调度各个运算资源，协调各个work node上的Executor。主要是一些记录信息，记录谁运行的，运行的情况如何等。这也是为什么编程的时候必须要创建一个sparkContext的原因。
• Driver:  Spark中的Driver即运行上述Application的main函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中由SparkContext负责与ClusterManager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同时负责将SparkContext关闭，通常用SparkContext代表Driver
• RDD（resillient distributed dataset）：spark的核心数据结构，可以通过一系列算子进行操作，当Rdd遇到Action算子时，将之前的所有的算子形成一个有向无环图(DAG)。再在spark中转化成为job，提交到集群执行。一个app可以包含多个job。

• Executor:  某个Application运行在worker节点上的一个进程，  该进程负责运行某些Task， 并且负责将数据存到内存或磁盘上，每个Application都有各自独立的一批Executor， 在Spark on Yarn模式下，其进程名称为CoarseGrainedExecutor Backend。一个CoarseGrainedExecutor Backend有且仅有一个Executor对象， 负责将Task包装成taskRunner,并从线程池中抽取一个空闲线程运行Task， 这个每一个oarseGrainedExecutor Backend能并行运行Task的数量取决与分配给它的cpu个数
• Worker: 集群中任何可以运行Application代码的节点，在Standalone模式中指的是通过slave文件配置的Worker节点，在Spark on Yarn模式下就是NoteManager节点。

2.1、spark组件的概念

---

spark应用(Application)执行过程中各个组件的概念：

• Task：执行具体的任务。被送到某个Executor上的工作单元，但hadoopMR中的MapTask和ReduceTask概念一样，是运行Application的基本单位，多个Task组成一个Stage，而Task的调度和管理等是由TaskScheduler负责。Task分为ShuffleMapTask和ResultTask两种。ShuffleMapTask和ResultTask分别类似于Hadoop中的Map，Reduce。
• TaskSet(任务集)：一组关联的，但相互之间没有Shuffle依赖关系的Task集合。
• Stage: 每个Job会被拆分成多组Task， 作为一个TaskSet， 其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生shuffle的地方。
•  Job: 包含多个Task的并行计算，往往由Spark Action（如save,collect）触发生成，一个Application中往往会产生多个Job。
• Application: Appliction都是指用户编写的Spark应用程序，其中包括一个Driver功能的代码和分布在集群中多个节点上运行的Executor代码。
• Partition：数据分区。即一个RDD的数据可以划分为多少个分区。
• NarrowDependency：窄依赖。即子RDD依赖于父RDD中固定的Partition。NarrowDependency分为OneToOneDependency和RangeDependency两种。
• ShuffleDependency：shuffle依赖，也称为宽依赖。即子RDD对父RDD中的所有Partition都有依赖。
•  Cluster Manager: 在集群上获取资源的外部服务（如Standalone,Mesos,Yarn)，称作资源管理器或集群管理器，目前有三种类型：

Standalon : spark原生的资源管理，由Master负责资源的分配

Apache Mesos :与hadoop MR兼容性良好的一种资源调度框架

Hadoop Yarn : 主要是指Yarn中的ResourceManager

spark基本概念之间的关系：

一个Application可以由一个或者多个job组成，一个job可以由一个或者多个stage组成，其中stage是根据宽窄依赖进行划分的，一个stage由一个taskset组成，一个TaskSET可以由一个到多个task组成。

• 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的作用， TaskScheduler:基于Task的任务调度模块，负责每个Task的跟踪和向DAGScheduler汇报任务执行情况。

在不同运行模式中任务调度器具体为：

1. Spark on Standalone模式为TaskScheduler
2. YARN-Client模式为YarnClientClusterScheduler
3. YARN-Cluster模式为YarnClusterScheduler

将这些术语串起来的运行层次图如下：

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

3、Spark基本架构

---

       从集群部署的角度来看，Spark集群由以下部分组成：

• Cluster Manager：Spark的集群管理器，主要负责资源的分配与管理。集群管理器分配的资源属于一级分配，它将各个Worker上的内存、CPU等资源分配给应用程序，但是并不负责对Executor的资源分配。目前，Standalone、YARN、Mesos、EC2等都可以作为Spark的集群管理器。
• Worker：Spark的工作节点。对Spark应用程序来说，由集群管理器分配得到资源的Worker节点主要负责以下工作：创建Executor，将资源和任务进一步分配给Executor，同步资源信息给Cluster Manager。
• Executor：执行计算任务的一线进程。主要负责任务的执行以及与Worker、Driver App的信息同步。
• Driver App：客户端驱动程序，也可以理解为客户端应用程序，用于将任务程序转换为RDD和DAG，并与Cluster Manager进行通信与调度。

这些组成部分之间的整体关系如图所示：

Spark架构的组成图如下：

Cluster Manager：在standalone模式中即为Master主节点，控制整个集群，监控worker。在YARN模式中为资源管理器

Worker节点：从节点，负责控制计算节点，启动Executor或者Driver。

Driver： 运行Application 的main()函数

Executor：执行器，是为某个Application运行在worker node上的一个进程。

4、spark运行流程

---

• spark运行流程图如下：

1、构建Spark Application的运行环境，启动SparkContext

2、SparkContext向资源管理器（可以是Standalone，Mesos，Yarn）申请运行Executor资源，并启动StandaloneExecutorbackend，

3、Executor向SparkContext申请Task

4、SparkContext将应用程序分发给Executor

5、SparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给Task Scheduler，最后由Task Scheduler将Task发送给Executor运行

6、Task在Executor上运行，运行完释放所有资源

Spark运行特点：

1、每个Application获取专属的executor进程，该进程在Application期间一直驻留，并以 多线程方式运行Task。这种Application隔离机制是有优势的，无论是从调度角度看（每个Driver调度他自己的任务），还是从运行角度看（来自不同Application的Task运行在不同JVM中），当然这样意味着Spark Application不能跨应用程序共享数据，除非将数据写入外部存储系统

2、Spark与资源管理器无关，只要能够获取executor进程，并能保持相互通信就可以了

3、提交 SparkContext的Client应该靠近Worker节点（运行Executor的节点），最好是在同一个Rack里，因为Spark Application运行过程中SparkContext和Executor之间有大量的信息交换

4、Task采用了数据本地性和推测执行的优化机制

5、Spark核心功能

---

Spark Core提供Spark最基础与最核心的功能，主要包括：

• SparkContext：通常而言，DriverApplication的执行与输出都是通过SparkContext来完成的，在正式提交Application之前，首先需要初始化SparkContext。SparkContext隐藏了网络通信、分布式部署、消息通信、存储能力、计算能力、缓存、测量系统、文件服务、Web服务等内容，应用程序开发者只需要使用SparkContext提供的API完成功能开发。SparkContext内置的DAGScheduler负责创建Job，将DAG中的RDD划分到不同的Stage，提交Stage等功能。内置的TaskScheduler负责资源的申请、任务的提交及请求集群对任务的调度等工作。
• 存储体系：Spark优先考虑使用各节点的内存作为存储，当内存不足时才会考虑使用磁盘，这极大地减少了磁盘I/O，提升了任务执行的效率，使得Spark适用于实时计算、流式计算等场景。此外，Spark还提供了以内存为中心的高容错的分布式文件系统Tachyon供用户进行选择。Tachyon能够为Spark提供可靠的内存级的文件共享服务。
• 计算引擎：计算引擎由SparkContext中的DAGScheduler、RDD以及具体节点上的Executor负责执行的Map和Reduce任务组成。DAGScheduler和RDD虽然位于SparkContext内部，但是在任务正式提交与执行之前将Job中的RDD组织成有向无关图（简称DAG）、并对Stage进行划分决定了任务执行阶段任务的数量、迭代计算、shuffle等过程。
• 部署模式：由于单节点不足以提供足够的存储及计算能力，所以作为大数据处理的Spark在SparkContext的TaskScheduler组件中提供了对Standalone部署模式的实现和Yarn、Mesos等分布式资源管理系统的支持。通过使用Standalone、Yarn、Mesos等部署模式为Task分配计算资源，提高任务的并发执行效率。除了可用于实际生产环境的Standalone、Yarn、Mesos等部署模式外，Spark还提供了Local模式和local-cluster模式便于开发和调试。

6、Spark扩展功能

---

         为了扩大应用范围，Spark陆续增加了一些扩展功能，主要包括：

• Spark SQL：由于SQL具有普及率高、学习成本低等特点，为了扩大Spark的应用面，因此增加了对SQL及Hive的支持。Spark SQL的过程可以总结为：首先使用SQL语句解析器（SqlParser）将SQL转换为语法树（Tree），并且使用规则执行器（RuleExecutor）将一系列规则（Rule）应用到语法树，最终生成物理执行计划并执行的过程。其中，规则包括语法分析器（Analyzer）和优化器（Optimizer）。Hive的执行过程与SQ类似。
• Spark Streaming：Spark Streaming与Apache Storm类似，也用于流式计算。SparkStreaming支持Kafka、Flume、Twitter、MQTT、ZeroMQ、Kinesis和简单的TCP套接字等多种数据输入源。输入流接收器（Receiver）负责接入数据，是接入数据流的接口规范。Dstream是Spark Streaming中所有数据流的抽象，Dstream可以被组织为DStreamGraph。Dstream本质上由一系列连续的RDD组成。
• GraphX：Spark提供的分布式图计算框架。GraphX主要遵循整体同步并行计算模式（BulkSynchronous Parallell，简称BSP）下的Pregel模型实现。GraphX提供了对图的抽象Graph，Graph由顶点（Vertex）、边（Edge）及继承了Edge的EdgeTriplet（添加了srcAttr和dstAttr用来保存源顶点和目的顶点的属性）三种结构组成。GraphX目前已经封装了最短路径、网页排名、连接组件、三角关系统计等算法的实现，用户可以选择使用。
• MLlib：Spark提供的机器学习框架。机器学习是一门涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多领域的交叉学科。MLlib目前已经提供了基础统计、分类、回归、决策树、随机森林、朴素贝叶斯、保序回归、协同过滤、聚类、维数缩减、特征提取与转型、频繁模式挖掘、预言模型标记语言、管道等多种数理统计、概率论、数据挖掘方面的数学算法。
• 
  

7、RDD运行流程

---

• RDD在Spark中运行大概分为以下三步：

1）创建RDD对象

2）DAGScheduler模块 介入运算，计算RDD之间的依赖关系，RDD之间的依赖关系就形成了DAG

3）每一个Job被分为 多个Stage。划分Stage的一个主要依据是当前计算因子的输入是否是确定的，如果是则将其 分在同一个Stage，避免多个Stage之间的消息传递开销

示例图如下：

• 以下面一个按 A-Z 首字母分类，查找相同首字母下不同姓名总个数的例子来看一下 RDD 是如何运行起来的

• 创建 RDD  上面的例子除去最后一个 collect 是个动作，不会创建 RDD 之外，前面四个转换都会创建出新的 RDD 。因此第一步就是创建好所有 RDD( 内部的五项信息 )？
• 创建执行计划 Spark 会尽可能地管道化，并基于是否要重新组织数据来划分 阶段 (stage) ，例如本例中的 groupBy() 转换就会将整个执行计划划分成两阶段执行。最终会产生一个 DAG(directed acyclic graph ，有向无环图 ) 作为逻辑执行计划

• 调度任务  将各阶段划分成不同的 任务 (task) ，每个任务都是数据和计算的合体。在进行下一阶段前，当前阶段的所有任务都要执行完成。因为下一阶段的第一个转换一定是重新组织数据的，所以必须等当前阶段所有结果数据都计算出来了才能继续

8、Spark模块设计

---

整个Spark主要由以下模块组成：

• Spark Core：Spark的核心功能实现，包括：SparkContext的初始化（DriverApplication通过SparkContext提交）、部署模式、存储体系、任务提交与执行、计算引擎等。
• Spark SQL：提供SQL处理能力，便于熟悉关系型数据库操作的工程师进行交互查询。此外，还为熟悉Hadoop的用户提供Hive SQL处理能力。
• Spark Streaming：提供流式计算处理能力，目前支持Kafka、Flume、Twitter、MQTT、ZeroMQ、Kinesis和简单的TCP套接字等数据源。此外，还提供窗口操作。
• GraphX：提供图计算处理能力，支持分布式， Pregel提供的API可以解决图计算中的常见问题。
• MLlib：提供机器学习相关的统计、分类、回归等领域的多种算法实现。其一致的API接口大大降低了用户的学习成本。

Spark SQL、Spark Streaming、GraphX、MLlib的能力都是建立在核心引擎之上，如图。

图 Spark各模块依赖关系

9、Spark编程模型

---

Spark 应用程序从编写到提交、执行、输出的整个过程如图2-5所示，图中描述的步骤如下：

1) 用户使用SparkContext提供的API（常用的有textFile、sequenceFile、runJob、stop等）编写Driver application程序。此外SQLContext、HiveContext及StreamingContext对SparkContext进行封装，并提供了SQL、Hive及流式计算相关的API。

2) 使用SparkContext提交的用户应用程序，首先会使用BlockManager和BroadcastManager将任务的Hadoop配置进行广播。然后由DAGScheduler将任务转换为RDD并组织成DAG，DAG还将被划分为不同的Stage。最后由TaskScheduler借助ActorSystem将任务提交给集群管理器（Cluster Manager）。

3) 集群管理器（ClusterManager）给任务分配资源，即将具体任务分配到Worker上，Worker创建Executor来处理任务的运行。Standalone、YARN、Mesos、EC2等都可以作为Spark的集群管理器。

图 代码执行过程

10、Spark计算模型

---

      RDD可以看做是对各种数据计算模型的统一抽象，Spark的计算过程主要是RDD的迭代计算过程，如图。RDD的迭代计算过程非常类似于管道。分区数量取决于partition数量的设定，每个分区的数据只会在一个Task中计算。所有分区可以在多个机器节点的Executor上并行执行。

图 RDD计算模型

11、 Spark运行模式

---

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

11.1. Standalone模式

       即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说， 该模式是其他两种的基础。借鉴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资源。总之，这两种方式各有优缺点。

• Standalone模式使用Spark自带的资源调度框架
• 采用Master/Slaves的典型架构，选用ZooKeeper来实现Master的HA
• 框架结构图如下:

• 该模式主要的节点有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端上的
• 运行过程如下图：

7. SparkContext连接到Master，向Master注册并申请资源（CPU Core 和Memory）
8. Master根据SparkContext的资源申请要求和Worker心跳周期内报告的信息决定在哪个Worker上分配资源，然后在该Worker上获取资源，然后启动StandaloneExecutorBackend；
9. StandaloneExecutorBackend向SparkContext注册；
10. SparkContext将Applicaiton代码发送给StandaloneExecutorBackend；并且SparkContext解析Applicaiton代码，构建DAG图，并提交给DAG Scheduler分解成Stage（当碰到Action操作时，就会催生Job；每个Job中含有1个或多个Stage，Stage一般在获取外部数据和shuffle之前产生），然后以Stage（或者称为TaskSet）提交给Task Scheduler，Task Scheduler负责将Task分配到相应的Worker，最后提交给StandaloneExecutorBackend执行；
11. StandaloneExecutorBackend会建立Executor线程池，开始执行Task，并向SparkContext报告，直至Task完成
12. 所有Task完成后，SparkContext向Master注销，释放资源

11.2、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完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。

11.3、Spark On YARN模式

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

　　spark on yarn 的支持两种模式： 

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

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

　　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 YARN模式根据Driver在集群中的位置分为两种模式：一种是YARN-Client模式，另一种是YARN-Cluster（或称为YARN-Standalone模式）
• Yarn-Client模式中，Driver在客户端本地运行，这种模式可以使得Spark Application和客户端进行交互，因为Driver在客户端，所以可以通过webUI访问Driver的状态，默认是http://hadoop1:4040访问，而YARN通过http:// hadoop1:8088访问
• YARN-client的工作流程步骤为：

• Spark Yarn Client向YARN的ResourceManager申请启动Application Master。同时在SparkContent初始化中将创建DAGScheduler和TASKScheduler等，由于我们选择的是Yarn-Client模式，程序会选择YarnClientClusterScheduler和YarnClientSchedulerBackend
• ResourceManager收到请求后，在集群中选择一个NodeManager，为该应用程序分配第一个Container，要求它在这个Container中启动应用程序的ApplicationMaster，与YARN-Cluster区别的是在该ApplicationMaster不运行SparkContext，只与SparkContext进行联系进行资源的分派
• Client中的SparkContext初始化完毕后，与ApplicationMaster建立通讯，向ResourceManager注册，根据任务信息向ResourceManager申请资源（Container）
• 一旦ApplicationMaster申请到资源（也就是Container）后，便与对应的NodeManager通信，要求它在获得的Container中启动CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend启动后会向Client中的SparkContext注册并申请Task
• client中的SparkContext分配Task给CoarseGrainedExecutorBackend执行，CoarseGrainedExecutorBackend运行Task并向Driver汇报运行的状态和进度，以让Client随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务
• 应用程序运行完成后，Client的SparkContext向ResourceManager申请注销并关闭自己

Spark Cluster模式

• 在YARN-Cluster模式中，当用户向YARN中提交一个应用程序后，YARN将分两个阶段运行该应用程序：

3. 第一个阶段是把Spark的Driver作为一个ApplicationMaster在YARN集群中先启动；
4. 第二个阶段是由ApplicationMaster创建应用程序，然后为它向ResourceManager申请资源，并启动Executor来运行Task，同时监控它的整个运行过程，直到运行完成

• YARN-cluster的工作流程分为以下几个步骤

• Spark Yarn Client向YARN中提交应用程序，包括ApplicationMaster程序、启动ApplicationMaster的命令、需要在Executor中运行的程序等
• ResourceManager收到请求后，在集群中选择一个NodeManager，为该应用程序分配第一个Container，要求它在这个Container中启动应用程序的ApplicationMaster，其中ApplicationMaster进行SparkContext等的初始化
• ApplicationMaster向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将采用轮询的方式通过RPC协议为各个任务申请资源，并监控它们的运行状态直到运行结束
• 一旦ApplicationMaster申请到资源（也就是Container）后，便与对应的NodeManager通信，要求它在获得的Container中启动CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend启动后会向ApplicationMaster中的SparkContext注册并申请Task。这一点和Standalone模式一样，只不过SparkContext在Spark Application中初始化时，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler进行任务的调度，其中YarnClusterScheduler只是对TaskSchedulerImpl的一个简单包装，增加了对Executor的等待逻辑等
• ApplicationMaster中的SparkContext分配Task给CoarseGrainedExecutorBackend执行，CoarseGrainedExecutorBackend运行Task并向ApplicationMaster汇报运行的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务
• 应用程序运行完成后，ApplicationMaster向ResourceManager申请注销并关闭自己

Spark Client 和 Spark Cluster的区别:

• 理解YARN-Client和YARN-Cluster深层次的区别之前先清楚一个概念：Application Master。在YARN中，每个Application实例都有一个ApplicationMaster进程，它是Application启动的第一个容器。它负责和ResourceManager打交道并请求资源，获取资源之后告诉NodeManager为其启动Container。从深层次的含义讲YARN-Cluster和YARN-Client模式的区别其实就是ApplicationMaster进程的区别
• YARN-Cluster模式下，Driver运行在AM(Application Master)中，它负责向YARN申请资源，并监督作业的运行状况。当用户提交了作业之后，就可以关掉Client，作业会继续在YARN上运行，因而YARN-Cluster模式不适合运行交互类型的作业
• YARN-Client模式下，Application Master仅仅向YARN请求Executor，Client会和请求的Container通信来调度他们工作，也就是说Client不能离开

Spark Client和Cluster两种运行模式的工作流程

1.client mode:  在Client模式下，Driver进程会在当前客户端启动，客户端进程一直存在直到应用程序运行结束。

该模式下的工作流程图主要如下：

工作流程如下：

           1.启动master和worker . worker负责整个集群的资源管理，worker负责监控自己的cpu,内存信息并定时向master汇报

           2.在client中启动Driver进程，并向master注册

           3.master通过rpc与worker进行通信，通知worker启动一个或多个executor进程

           4.executor进程向Driver注册，告知Driver自身的信息，包括所在节点的host等

           5.Driver对job进行划分stage，并对stage进行更进一步的划分，将一条pipeline中的所有操作封装成一个task，并发送到向自己注册的executor

              进程中的task线程中执行

           6.应用程序执行完成，Driver进程退出

2.cluster模式：在cluster模式下，Driver进程将会在集群中的一个worker中启动，而且客户端进程在完成自己提交任务的职责后，就可以退出，而不用等到应用程序执行完毕

该模式下的工作流程图如下：

工作流程如下：

            1.在集群的节点中，启动master , worker进程，worker进程启动成功后，会向Master进行注册。

            2.客户端提交任务后， ActorSelection（master的actor引用）,然后通过ActorSelection给Master发送注册Driver请求（RequestSubmitDriver）

            3.客户端提交任务后，master通知worker节点启动driver进程。(worker的选择是随意的，只要worker有足够的资源即可)

               driver进程启动成功后，将向Master返回注册成功信息

            4.master通知worker启动executor进程

            5.启动成功后的executor进程向driver进行注册

            6.Driver对job进行划分stage，并对stage进行更进一步的划分，将一条pipeline中的所有操作封装成一个task，并发送到向自己注册的executor

              进程中的task线程中执行

            7.所有task执行完毕后，程序结束。

通过上面的描述我们知道：Mater负责整个集群的资源的管理和创建worker，worker负责当前结点的资源的管理，并会将当前的cpu，内存等信息定时告知master,并且负责创建Executor进程(也就是最小额资源分配单位)，Driver负责整个应用任务的job的划分和stage的切割以及task的切割和优化，并负责把task分发到worker对应的节点的executor进程中的task线程中执行, 并获取task的执行结果，Driver通过SparkContext对象与spark集群获取联系，得到master主机host，就可以通过rpc向master注册自己。

总结： 

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

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

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

　　· Standalone对于小规模计算集群更适合！

注意： Spark on Yarn 有  yarn  client 和  yarn clusters 模式。

　　　　　Spark on Standalone 也有  standalone client 和  standalone clusters 模式。

12、应用提交与执行

---

spark使用driver进程负责应用的解析，切分Stage并且调度task到Executor执行,包含DAGscheduler等重要对象。Driver进程的运行地点有如下两种：

1.driver进程运行在client端，对应用进行管理监控。

2.Master节点指定某个Worker节点启动Driver进程，负责监控整个应用的执行。

driver运行在client

用户启动Client端，在client端启动Driver进程。在Driver中启动或实例化DAGScheduler等组件。

1.driver在client启动，做好准备工作，计划好任务的策略和方式（ DAGScheduler)后向Master注册并申请运行Executor资源。

2.Worker向Master注册，Master通过指令让worker启动Executor。

3.worker收到指令后创建ExecutorRunner线程，进而ExecutorRunner线程启动executorBackend进程。

4.ExecutorBackend启动后，向client端driver进程内的SchedulerBackend注册,这样dirver进程就可以发现计算资源了。

5.Driver的DAGScheduler解析应用中的RDD DAG并生成相应的Stage，每个Stage包含的TaskSet通过TaskScheduler分配给Executor，在Exectutor内部启动线程池并行化执行Task，同事driver会密切注视，如果发现哪个execuctor执行效率低，会分配其他exeuctor顶替执行，观察谁的效率更高（推测执行）。

6.计划中的所有stage被执行完了之后，各个worker汇报给driver，同事释放资源，driver确定都做完了，就向master汇报。同时driver在client上，应用的执行进度clinet也知道了。

Driver运行在Worker节点

用户启动客户端，客户端提交应用程序给Master

1.Master调度应用，指定一个worker节点启动driver，即Scheduler-Backend。

2.worker接收到Master命令后创建driverRunner线程，在DriverRunner线程内创建SchedulerBackend进程，Dirver充当整个作业的主控进程。

3.Master指定其他Worker节点启动Exeuctor，此处流程和上面相似，worker创建ExecutorRunner线程，启动ExecutorBackend进程。

4.ExecutorBackend启动后，向client端driver进程内的SchedulerBackend注册,这样dirver进程就可以发现计算资源了。

5.Driver的DAGScheduler解析应用中的RDD DAG并生成相应的Stage，每个Stage包含的TaskSet通过TaskScheduler分配给Executor，在Exectutor内部启动线程池并行化执行Task，同事driver会密切注视，如果发现哪个execuctor执行效率低，会分配其他exeuctor顶替执行，观察谁的效率更高（推测执行）。

6.计划中的所有stage被执行完了之后，各个worker汇报给driver，同事释放资源，driver确定都做完了，就向master汇报。客户也会跳过master直接和drive通讯了解任务的执行进度。

文章链接：
spark详解
Spark性能优化：资源调优篇
Spark性能调优：开发调优篇
Spark性能调优：shuffle调优篇
Spark性能调优：数据倾斜调优篇