Spark运行模式及原理

1. Spark运行模式概述

1.1  Spark运行模式列表

       在实际应用中，Spark应用程序的运行模式取决于传递给SparkContext的MASTER环境变量的值，支持的MASTER环境变量由特定的字符串或URL组成，如下所示。

• Local[N]：本地模式，使用N个线程。
• Local cluster[worker,core,Memory]：伪分布式模式，可以配置所需要启动的虚拟工作节点的数量，以及每个工作节点所管理的CPU数量和内存大小。
• Spark：//hostname：port：Standalone模式，需要部署Spark到相关节点。URL为Spark Master主机地址和端口。
• Mesos：//hostname：port：Mesos模式，需要部署Spark到相关节点，URL为Spark Master主机地址和端口。
• YARN standalone/Yarn cluster：YARN模式一，主程序逻辑和任务都运行在YARN集群中。
• YARN client：YARN模式二，主程序逻辑运行在本地，具体任务运行在YARN集群中。

1.2 Spark基本工作流程

        看到这么多的部署和运行模式,其实这些运行模式尽管表面上看起来差异很大,但总体上来说,都基于一个相似的工作流程。它们从根本上都是将Spark的应用分为任务调度和任务执行两个部分,如图所示的是在分布式模式下,Spark的各个调度和执行模块的大致框架图。对于本地模式来说,其内部程序逻辑结构也是类似的,只是其中部分模块有所简化。例如集群管理模块简化为进程内部的线程池。
        从图中可以看到,所有的应用程序都离不开SparkContext和Executor两部分，Executor负责执行任务,运行Executor的机器称为worker节点,SparkContext由用户程序启动，通过资源调度模块和Executor通信。SparkContext和Executor这两部分的核心代码
实现在各种运行模式中都是公用的,在它们之上,根据运行部署模式的不同,包装了不同调度模块以及相关的适配代码。

                                                   

        具体来说,以SparkContext为程序运行的总入口,在SparkContext的初始化过程中,Spark会分别创建DAGScheduler作业调度和TaskScheduler任务调度两级调度模块。
        其中作业调度模块是基于任务阶段的高层调度模块,它为每个Spark作业计算具有依赖关系的多个调度阶段(通常根据shuffle来划分),然后为每个阶段构建出一组具体的任务(通常会考虑数据的本地性等).然后以Tasksets(任务组)的形式提交给任务调度模块来具体执行。而任务调度模块则负责具体启动任务、监控和汇报任务运行情况。
        作业调度模块和具体的部署运行模式无关,在各种运行模式下逻辑相同,因此在本章不做过多介绍,我们会在后面介绍调度管理的章节中再详细分析。
        不同运行模式的区别主要体现在任务调度模块,不同的部署和运行模式,根据底层资源调度方式的不同,各自实现了自己特定的任务调度模块,用来将任务实际调度给对应的计算资源。

2. Standalone模式

        在Spark Standalone模式中，Spark集群由Master节点和Worker节点构成，用户程序通过与Master节点交互，申请所需的资源，Worker节点负责具体Executor的启动运行。

2.1 内部实现原理

        如图所示，Standalone模式使用SparkDeploySchedulerBackend配合TaskSchedulerImpl工作，而SparkDeploySchedulerBackend本身拓展自CoarseGrainedSchedulerBackend。

                              

        CoarseGrainedSchedulerBackend是一个基于Akka Actor实现的粗粒度的资源调度类,在整个Spark作业运行期间,CoarseGrainedSchedulerBackend会监听并持有注册给它的Executor资源(相对于细粒度的调度，Executor基于每个任务的生命周期创建和销毁),并且在接受Executor注册、状态更新、响应Scheduler请求等各种时刻,根据现有Executor资源发起任务调度流程。
        Executor本身是可以通过各种途径启动的,对应的,在Standalone模式中,SparkDeploySchedulerBackend通过Client类向Master发送请求，在独立部署的Spark集群中启动CoarseGrainedExecutorBackend,根据所需的CPU资源的数量,一个或多个CoarseGrainedExecutorBackend在worker节点上启动并注册给CoarseGrainedSchedulerBackend的Driver Actor。
       完成所需的启动后,任务调度就在CoarseGrainedSchedulerBackend和CoarseGrainedExecutorBackendi的Actor之间直接完成。

3.  YARN cluster模式

3.1  内部实现原理

        下图是cluster模式的原理框图,相对于其他模式有些特殊,它需要由外部程序辅助启动APP,用户的应用程序通过辅助的YARN Client类启动。Client类通过Client API 提交请求在Hadoop集群上启动一个Spark ApplicationMaster,Spark ApplicationMaster首先注册自己为一个YARN Application Master,之后启动用户程序，SparkContext在用户程序中初始化时,使用
CoarseGrainedSchedulerBackend配合YARNClusterScheduler,YARNClusterScheduler只是对的一个简单包装,增加了对Executor的等待逻辑等。
        根据Client类传递的参数,Spark ApplicationMaster通过YARN ResourceManager/NodeManager的接口在集群中启动若干个Container(容器),用于运行CoarseGrainedExecutorBackend。CoarseGrainedExecutorBackend在启动过程中会向CoarseGrainedSchedulerBackend注册。

                                           

 

4. YARN Client模式

4.1 内部实现原理

       client模式与cluster模式的区别在于,在cluster模式中,应用程序(包括SparkContext)都是作为YARN框架所需要的Application Master,在由ResourceManager为其分配的一个随机节点上运行,而在client模式中,sparkContext运行在本地,该模式适用于应用程序本身需要在本地进行交互的场合,如Spark Shell。
       如图所示的client模式中,sparkContext在初始化过程中启动YARNClientSchedulerBackend，该Backemd进一步在远程启动一个workerLauncher作为spark的Application Master，相比于YARN standalone模式，workerLauncher不再负责用户程序的启动（已经在客户端本地启动），而只是启动Container运行CoarseGrainedExecutorBackend与客户端本地的Driver进行通信,后续任务调度流程相同。