文章目录
- 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可以有多个,可以设置个数和资源信息
应用执行流程:
- 用户程序创建 SparkContext 时,新创建的 SparkContext 实例会连接到 ClusterManager。 Cluster Manager 会根据用户提交时设置的 CPU 和内存等信息为本次提交分配计算资源,启动 Executor。
- Driver会将用户程序划分为不同的执行阶段Stage,每个执行阶段Stage由一组完全相同Task组成,这些Task分别作用于待处理数据的不同分区。在阶段划分完成和Task创建后, Driver会向Executor发送 Task
- Executor在接收到Task后,会下载Task的运行时依赖,在准备好Task的执行环境后,会开始执行Task,并且将Task的运行状态汇报给Driver
- Driver会根据收到的Task的运行状态来处理不同的状态更新。 Task分为两种:一种是Shuffle Map Task,它实现数据的重新洗牌,洗牌的结果保存到Executor 所在节点的文件系统中;另外一种是Result Task,它负责生成结果数据;
- 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提供了两种解决单点故障问题的方案:
-
基于文件系统的单点恢复(Single-Node Recovery with Local File System)–
只能用于开发或测试环境
。 -
基于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模式:学习测试时使用,生产不推荐
- Driver运行在Client上,和集群的通信成本高
- Driver输出结果会在客户端显示
Cluster模式:生产环境中使用该模式
- Driver程序在YARN集群中,和集群的通信成本低
- Driver输出结果不能在客户端显示
- 该模式下Driver运行ApplicattionMaster这个节点上,由Yarn管理,如果出现问题,yarn会重启ApplicattionMaster(Driver)
3.3 两种部署模式运行流程
在YARN Client模式下,Driver在任务提交的本地机器上运行:
- Driver在任务提交的本地机器上运行,Driver启动后会和ResourceManager通讯申请启动ApplicationMaster
- 随后ResourceManager分配Container,在合适的NodeManager上启动ApplicationMaster,此时的ApplicationMaster的功能相当于一个ExecutorLaucher,只负责向ResourceManager申请Executor内存
- ResourceManager接到ApplicationMaster的资源申请后会分配Container,然后ApplicationMaster在资源分配指定的NodeManager上启动Executor进程
- Executor进程启动后会向Driver反向注册,Executor全部注册完成后Driver开始执行main函数
- 之后执行到Action算子时,触发一个Job,并根据宽依赖开始划分Stage,每个Stage生成对应的TaskSet,之后将Task分发到各个Executor上执行
在YARN Cluster模式下,Driver运行在NodeManager Contanier中,此时Driver与AppMaster合为一体
- 任务提交后会和ResourceManager通讯申请启动ApplicationMaster
- 随后ResourceManager分配Container,在合适的NodeManager上启动ApplicationMaster,此时的ApplicationMaster就是Driver;
- Driver启动后向ResourceManager申请Executor内存,ResourceManager接到ApplicationMaster的资源申请后会分配Container,然后在合适的NodeManager上启动Executor进程
- Executor进程启动后会向Driver反向注册
- Executor全部注册完成后Driver开始执行main函数,之后执行到Action算子时,触发一个job,并根据宽依赖开始划分stage,每个stage生成对应的taskSet,之后将task分发到各个Executor上执行