Spark运行模式介绍

文章目录

• 1. Local运行模式
• • 1.1 基本运行情况介绍
  • 1.2 角色划分
  • 1.3 Spark 任务提交与解释器对比
• 2. StandAlone运行模式
• • 2.1 StandAlone介绍
  • 2.2 StandAlone架构
  • 2.3 Spark应用架构
  • 2.4 StandAlone HA 运行原理
• 3. Spark on YARN
• • 3.1 Spark on Yarn 本质
  • 3.2 部署模式
  • 3.3 两种部署模式运行流程

1. Local运行模式

1.1 基本运行情况介绍

本质：启动一个JVM Process进程(一个进程里面有多个线程)，执行任务Task

Local模式可以限制模拟Spark集群环境的线程数量, 即Local[N] 或 Local[*]

其中N代表可以使用N个线程，每个线程拥有一个cpu core。如果不指定N，
则默认是1个线程（该线程有1个core）。 通常Cpu有几个Core，就指定几个
线程，最大化利用计算能力。

如果是local[*]，则代表 Run Spark locally with as many worker threads as
logical cores on your machine.按照Cpu最多的Cores设置线程数

1.2 角色划分

资源管理：

• Master：Local进程本身
• Worker：Local进程本身

任务执行：

• Driver：Local进程本身
• Executor：不存在，没有独立的Executor角色, 由Local进程(也就是Driver)内的线程提供计算能力

Driver也算一种特殊的Executor, 只不过多数时候, 我们将Executor当做纯Worker对待, 这样和Driver好区分(一类是管理 一类是工人)

注意: Local模式只能运行一个Spark程序, 如果执行多个Spark程序, 那就是由多个相互独立的Local进程在执行

1.3 Spark 任务提交与解释器对比

方式	bin/spark-submit	bin/pyspark	bin/spark-shell
功能	提交java/scala/python代码到spark环境中运行	提供一个python解释器环境用来以python代码执行spark程序	提供一个scala解释器环境用来以scala代码执行spark程序
特点	提交代码	解释器环境，写一行执行一行	解释器环境，写一行执行一行
使用场景	正式场合，正式提交spark程序运行	测试\学习	测试\学习

2. StandAlone运行模式

2.1 StandAlone介绍

Standalone模式是Spark自带的一种集群模式，不同于前面本地模式启动多个进程来模拟集群的环境，Standalone模式是真实地在多个机器之间搭建Spark集群的环境，完全可以利用该模式搭建多机器集群，用于实际的大数据处理。

StandAlone 是完整的Spark运行环境，Master角色以Master进程存在, Worker角色以Worker进程存在Driver和Executor运行于Worker进程内, 由Worker提供资源供给它们运行

2.2 StandAlone架构

StandAlone集群在进程上主要有3类进程:

• 主节点Master进程： Master角色, 管理整个集群资源，并托管运行各个任务的Driver
• 从节点Workers：Worker角色, 管理每个机器的资源，分配对应的资源来运行Executor(Task)；每个从节点分配资源信息给Worker管理，资源信息包含内存Memory和CPU Cores核数
• 历史服务器HistoryServer(可选)：Spark Application运行完成以后，保存事件日志数据至HDFS，启动HistoryServer可以查看应用运行相关信息

**注意：**集群模式下程序是在集群上运行的，不要直接读取本地文件，应该读取hdfs上的
因为程序运行在集群上，具体在哪个节点上我们运行并不知道，其他节点可能并没有那个数据文件

2.3 Spark应用架构

Spark Application运行到集群上时，由两部分组成：Driver Program和Executors

Driver Program

• 相当于AppMaster，整个应用管理者，负责应用中所有Job的调度执行
• 运行JVM Process，运行程序的MAIN函数，必须创建SparkContext上下文对象
• 一个SparkApplication仅有一个；

Executors

• 相当于一个线程池，运行JVM Process，其中有很多线程，每个线程运行一个Task任务，一个Task任务运行需要1 Core CPU，所有可以认为Executor中线程数就等于CPU Core核数；
• 一个Spark Application可以有多个，可以设置个数和资源信息

应用执行流程：

1. 用户程序创建 SparkContext 时，新创建的 SparkContext 实例会连接到 ClusterManager。 Cluster Manager 会根据用户提交时设置的 CPU 和内存等信息为本次提交分配计算资源，启动 Executor。
2. Driver会将用户程序划分为不同的执行阶段Stage，每个执行阶段Stage由一组完全相同Task组成，这些Task分别作用于待处理数据的不同分区。在阶段划分完成和Task创建后， Driver会向Executor发送 Task
3. Executor在接收到Task后，会下载Task的运行时依赖，在准备好Task的执行环境后，会开始执行Task，并且将Task的运行状态汇报给Driver
4. Driver会根据收到的Task的运行状态来处理不同的状态更新。 Task分为两种：一种是Shuffle Map Task，它实现数据的重新洗牌，洗牌的结果保存到Executor 所在节点的文件系统中；另外一种是Result Task，它负责生成结果数据；
5. Driver 会不断地调用Task，将Task发送到Executor执行，在所有的Task 都正确执行或者超过执行次数的限制仍然没有执行成
   功时停止；

Spark运行监控页面区别：

4040端口: 是一个运行的Application在运行的过程中临时绑定的端口,用以查看当前任务的状态.4040被占用会顺延到4041.4042等，4040是一个临时端口,当前程序运行完成后, 4040就会被注销

8080端口: 默认是StandAlone下, Master角色(进程)的WEB端口,用以查看当前Master(集群)的状态

18080端口: 默认是历史服务器的端口, 由于每个程序运行完成后,4040端口就被注销了. 在以后想回看某个程序的运行状态就可以通过历史服务器查看,历史服务器长期稳定运行,可供随时查看被记录的程序的运行过程.

Spark程序运行层次结构：

在一个Spark Application中，包含多个Job，每个Job有多个Stage组成，每个Job执行按照DAG图进行的。其中每个Stage中包含多个Task任务，每个Task以线程Thread方式执行，需要1Core CPU。

Spark Application程序运行时的三个概念：Job、Stage、Task

• Job：由多个 Task 的并行计算部分，一般 Spark 中的action 操作（如 save、collect，后面进一步说明），会生成一个 Job。
• Stage：Job 的组成单位，一个 Job 会切分成多个 Stage，Stage 彼此之间相互依赖顺序执行，而每个 Stage 是多个 Task 的集合，类似 map 和 reduce stage。
• Task：被分配到各个 Executor 的单位工作内容，它是Spark 中的最小执行单位，一般来说有多少个 Paritition（物理层面的概念，即分支可以理解为将数据划分成不同
  部分并行处理），就会有多少个 Task，每个 Task 只会处理单一分支上的数据。

2.4 StandAlone HA 运行原理

Spark Standalone集群是Master-Slaves架构的集群模式，和大部分的Master-Slaves结构集群一样，存在着Master单点故障（SPOF）的问题。

Spark提供了两种解决单点故障问题的方案：

1. 基于文件系统的单点恢复(Single-Node Recovery with Local File System)–只能用于开发或测试环境。

2. 基于zookeeper的Standby Masters(Standby Masters with ZooKeeper)–可以用于生产环境。
   
   ZooKeeper提供了一个Leader Election机制，利用这个机制可以保证虽然集群存在多个Master，但是只有一个是Active的，其他的都是Standby。当Active的Master出现故障时，另外的一个Standby Master会被选举出来。由于集群的信息，包括Worker， Driver和Application的信息都已经持久化到文件系统，因此在切换的过程中只会影响新Job的提交，对于正在进行的Job没有任何的影响。

分布式进程是分布在多个服务器上的, 状态之间的同步需要协调，比如谁是master，谁
是worker，谁成了master后要通知worker等, 这些需要中心化协调器Zookeeper来进行状态统一协调

3. Spark on YARN

YARN是一个资源调度框架，负责对运行在内部的计算框架进行资源调度管理。作为典型的计算框架，Spark本身是可以直接运行在YARN中, 并接受YARN的调度的。在企业中，多数场景下，会将Spark运行到YARN集群中。

所以， 对于Spark On YARN， 无需部署Spark集群， 只要找一台服务器， 充当Spark的客户端， 即可提交任务到YARN集群中运行。

3.1 Spark on Yarn 本质

和StandAlone运行模式对比，在Spark on Yarn架构下，Master角色由YARN的ResourceManager担任；Worker角色由YARN的NodeManager担任；Driver角色运行在YARN容器内 或 提交任务的客户端进程中；真正干活的Executor运行在YARN提供的容器内。

3.2 部署模式

Spark On YARN是有两种运行模式的，一种是Cluster模式，一种是Client模式。
这两种模式的区别就是Driver运行的位置。

• Cluster模式：Driver运行在YARN容器内部, 和ApplicationMaster在同一个容器内
• Client模式：Driver运行在客户端进程中, 比如Driver运行在spark-submit程序的进程中

Cluster模式：Driver运行在容器内部

Client模式：Driver运行在客户端程序进程中

两种部署模式区别：

Client模式和Cluster模式最最本质的区别是：Driver程序运行在哪里

Client模式：学习测试时使用，生产不推荐

1. Driver运行在Client上,和集群的通信成本高
2. Driver输出结果会在客户端显示

Cluster模式：生产环境中使用该模式

1. Driver程序在YARN集群中，和集群的通信成本低
2. Driver输出结果不能在客户端显示
3. 该模式下Driver运行ApplicattionMaster这个节点上,由Yarn管理，如果出现问题，yarn会重启ApplicattionMaster(Driver)

3.3 两种部署模式运行流程

在YARN Client模式下，Driver在任务提交的本地机器上运行：

1. Driver在任务提交的本地机器上运行，Driver启动后会和ResourceManager通讯申请启动ApplicationMaster
2. 随后ResourceManager分配Container，在合适的NodeManager上启动ApplicationMaster，此时的ApplicationMaster的功能相当于一个ExecutorLaucher，只负责向ResourceManager申请Executor内存
3. ResourceManager接到ApplicationMaster的资源申请后会分配Container，然后ApplicationMaster在资源分配指定的NodeManager上启动Executor进程
4. Executor进程启动后会向Driver反向注册，Executor全部注册完成后Driver开始执行main函数
5. 之后执行到Action算子时，触发一个Job，并根据宽依赖开始划分Stage，每个Stage生成对应的TaskSet，之后将Task分发到各个Executor上执行

在YARN Cluster模式下，Driver运行在NodeManager Contanier中，此时Driver与AppMaster合为一体

1. 任务提交后会和ResourceManager通讯申请启动ApplicationMaster
2. 随后ResourceManager分配Container，在合适的NodeManager上启动ApplicationMaster，此时的ApplicationMaster就是Driver；
3. Driver启动后向ResourceManager申请Executor内存，ResourceManager接到ApplicationMaster的资源申请后会分配Container，然后在合适的NodeManager上启动Executor进程
4. Executor进程启动后会向Driver反向注册
5. Executor全部注册完成后Driver开始执行main函数，之后执行到Action算子时，触发一个job，并根据宽依赖开始划分stage，每个stage生成对应的taskSet，之后将task分发到各个Executor上执行