11.Spark之运行模式及原理

2019独角兽企业重金招聘Python工程师标准>>>

1.Spark运行模式

    Spark的运行模式多种多样，灵活多变。

1. 部署在单机上时，既可以用本地模式运行，也可以用伪分布式模式运行。

2. 以分布式集群方式部署时，也有众多的运行模式可供选择，这取决于集群的实际情况。底层的资源调度既可以依赖于外部的资源调度框架（Mesos、Yarn），也可以使用Spark内建的Standalone模式。

    实际应用中，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和Mesos到相关节点，URL为Mesos主机地址和端口。

• YARN standalone/YARN cluster：YARN模式一，主程序逻辑和任务都运行在YARN集群中。

• YARN client：YARN模式二，主程序逻辑运行在本地，具体任务运行在YARN集群中。

2.Spark基本工作流程

    运行模式尽管看起来差异很大，但总体来讲都基于一个相似的工作流程。它们从根本上都是将Spark的应用分为任务调度和任务执行两个部分。下图所示的是分布式模式下，Spark的各个调度和执行模块的大致框架图。对于本地模式来说，其内部程序逻辑结构也是类似的，只是其中部分模块有所简化，例如集群管理模块简化为进程内部的线程池。

    

    具体来说，以SparkContext为程序运行的总入口，在SparkContext的初始化过程中，Spark会分别创建DAGScheduler作业调度和TaskScheduler任务调度两级调度模块。

    其中作业调度模块是基于任务阶段的高层调度模块，它为每个Spark作业计算具有依赖关系的多个调度阶段（通常根据shuffle来划分），然后为每个阶段构建出一组具体的任务（通常会考虑数据的本地性），然后以TaskSets（任务组）的形式提交给任务调度模块来具体执行。而任务调度模块则负责具体启动任务、监控和汇报任务运行情况。

    作业调度模块和具体部署运行模式无关，在各种运行模式下逻辑相同。

    不同运行模式的区别主要体现在任务调度模块。不同的部署和运行模式，根据底层资源调度方式的不同，各自实现了自己特定的任务调度模块，用来将任务实际调度给对应的计算资源。

3.相关基本类

• TaskScheduler / SchedulerBackend
  

    为了抽象出一个公共的接口供DAGScheduler作业调度模块使用，所有的这些运行模式实现的任务调度模块都是基于这两个接口（Trait）的：TaskScheduler及SchedulerBackend。

    TaskSceduler的实现主要用于与DAGScheduler交互，负责任务的具体调度和运行，其核心接口是submitTasks和cancleTasks。

    SchedulerBackend的实现是与底层资源调度系统交互（如Mesos/YARN），配合TaskSceduler实现具体任务执行所需要的资源分配，核心接口是receiveOffers。

• TaskSchedulerImpl

    TaskSchedulerImpl实现了TaskSceduler接口，提供了大多数本地和分布式运行调度模式的任务调度接口。

    此外它还实现了resourceOffers和statusUpdate这两个接口供Backend调用，用于提供调度资源和更新任务状态。

    另外，在提交任务和更新状态等阶段，TaskSchedulerImpl都会调用Backend的receiveOffers函数，用于发起一次任务资源调度请求。

• Executor

    实际任务的运行，最终都由Executor类来执行，Executor对每一个任务创建一个TaskRunner类，交给线程池运行。运行结果通过ExecutorBackend接口返回。

4.Local模式

• 部署及程序运行

  Local模式，顾名思义就是在本地运行。如果不加任何配置，Spark默认设置为Local模式。以SparkPi为例，Local模式下的应用程序的启动命令如下：

         ./bin/run-example org.apache.spark.examples.SparkPi local

  在SparkPi的具体实现中，是根据传入的参数来选择运行模式的（如上例中的local）。也可以在代码中配置Master来指定运行模式，但为了能够使应用程序在各种部署环境下使用，不建议把与运行环境相关的设置在代码中写死。

• 内部实现原理

  Local本地模式使用LocalBackend配合TaskSchedulerImpl，内部逻辑结构如图所示：

  

  LocalBackend响应Scheduler的receiveOffers请求，根据可用的CPU核的设定值[N]直接生成CPU资源返回给Scheduler，并通过Executor类在线程池中依次启动和运行Scheduler返回的任务列表，其核心事件循环由内部类LocalActor以Akka Actor的消息处理形式来实现。

  因为Local模式无需配置，同时所有的代码都在本地进程中执行，所以常常用来作为快速验证代码和跟踪调试的手段。

5.Standalone模式

• 部署及程序运行

  在该模式中，Spark集群由Master、Worker节点构成，程序通过与Master节点交互申请所需的资源，Worker节点负责具体Executor的启动运行。部署也很简单，只需要将编译好或者下载的Spark发布版本复制到各个集群节点即可。为了方便通过启动脚本使用，部署的路径最好一致。

  手动启动集群

  在作为Master节点的服务器上通过命令手动启动集群：

         ./sbin/start-master.sh

  接下来在打算作为Worker节点的服务器上启动一个或多个Worker：

         ./bin/spark-class org.apache.spark.deploy.worker.Worker spark://MasterURL:PORT

  注：spark://MasterURL:PORT中的MasterURL和PORT可以在./sbin/start-master.sh输出信息中找到。

  脚本启动集群

  首先在Spark的Conf目录下创建一个名为slaves的文件，内容包含所有作为Worker节点的主机名（或IP），按行分隔。同时，Master节点必须能通过SSH秘钥登录的形式访问Worker节点（不需要手动输入密码）。配置好之后，就可以通过以下脚本启动、停止Standalone模式的集群了。

  sbin/start-master.sh：在执行该脚本的机器上启动一个Spark Master实例。

  sbin/start-slaves.sh：在slaves文件中指定的每一个节点上启动一个或多个Spark Worker实例。

  sbin/start-all.sh：执行上述两步。

  sbin/stop-master.sh：关闭由sbin/start-master.sh启动的Master实例。

  sbin/stop-slaves.sh：关闭由sbin/start-slaves.sh启动的Worker实例。

  sbin/stop-all.sh：执行上述两步。

  集群参数配置

  通过conf/spark-env.sh配置环境变量，你可以进一步控制Spark集群的运行参数。下面列出一些主要可供配置的参数。

  SPARK_MASTER_IP：Master节点的IP地址。

  SPARK_MASTER_PORT：Spark Master的工作端口（默认为7077）。

  SPARK_MASTER_WEBUI_PORT：Master节点监控网页的端口（默认为8080）。

  SPARK_WORKER_PORT：Spark Worker的工作端口（默认为随机）。

  SPARK_WORKER_DIR：Spark应用程序，包括Log记录等使用的目录（默认为SPARK_HOME/work）。

  SPARK_WORKER_CORES：Spark Worker管理的CPU核的数量（默认为使用所有核）。

  SPARK_WORKER_MEMORY：Spark Worker管理的内存数量（默认为总内存减1GB）。

  SPARK_WORKER_WEBUI_PORT：Spark Worker的网页端口（默认为8081）。

  SPARK_WORKER_INSTANCES：每个物理节点所运行的Worker进程的数量（默认为1），通过配置这个参数可以在一台机器上运行多个Spark Worker进程，但需要注意的是需要对应地调整每个Worker所管理的CPU核数和内存的数量。

  SPARK_DAEMON_MEMORY：Spark Master和Spark Worker自己所使用内存的大小（默认为512MB）。

  SPARK_DAEMON_JAVA_OPTS：传递给Spark Master和Spark Worker的JVM参数。

• 内部实现原理

  该模式使用SparkDeploySchedulerBackend配合TaskSchedulerImpl工作，而SparkDeploySchedulerBackend本身拓展自CoarseGrainedSchedulerBackend。

  
  

  CoarseGrainedSchedulerBackend是一个基于Akka Actor实现的粗粒度的资源调度类，在整个Spark作业运行期间，CoarseGrainedSchedulerBackend会监听并持有注册给它的Executor资源（相对于细粒度的调度，Executor基于每个任务的生命周期创建和销毁），并且在接受Executor注册、状态更新、响应Scheduler请求等各种时刻，根据现有Executor资源发起任务调度流程。

  Executor本身是可以通过各种途径启动的，对应的在Spark Standalone模式中，SparkDeploySchedulerBackend通过Client类向Spark Master发送请求，在独立部署的Spark集群中启动CoarseGrainedExecutorBackend，根据所需的CPU资源的数量，一个或多个CoarseGrainedExecutorBackend在Spark Worker节点上启动并注册给SparkDeploySchedulerBackend的Driver Actor。

  完成所需Actor的启动后，任务调度就在SparkDeploySchedulerBackend和CoarseGrainedExecutorBackend的Actor之间直接完成。

6.Local cluster模式

• 部署及程序运行

  Local cluster伪分布式模式，实际是在SparkContext初始化的过程中，在本地启动一个所有服务都在单机上运行的伪分布Spark集群，所以从部署的角度来说无须做任何准备工作。以SparkPi为例，伪分布式模式下的应用程序的启动命令的示例如下：

         ./bin/run-example org.apache.spark.examples.SparkPi local-cluster[2,2,1024]

  上面的伪分布式模式启动两个Worker，每个Worker管理两个CPU和1024MB的内存。

• 内部实现原理

  伪分布式模式是基于Standalone模式来实现的，除了启动Master和Worker的位置不同，在集群启动完毕后，后续的应用程序的工作流程及资源的调度流程与Standalone模式完全相同。

  

7.Mesos模式

• 部署及程序运行

  首先需要部署Mesos到所有的工作节点上，请参考http://mesos.apache.org/gettingstarted。

  之后需要创建一个Spark发布包，可以通过make-distribution.sh脚本来创建。这个脚本将Spark运行所需的配置文件和依赖关系复制到dist目录中，再将这个目录打包上传到HDFS中共Mesos调用。

  此外，还需在spark-env.sh文件中配置以下几个环境变量，需要注意的是如果你的Mesos集群使用Zookeeper来管理Master节点，那Master对应需要配置的是Zookeeper的主机和端口。

  MESOS_NATIVE_LIBRARY：libmesos.so的路径。

  SPARK_EXECUTOR_URI：Spark发布包的地址。

  MASTER：格式为mesos://HOST:PORT，Mesos Master的主机和端口（Mesos端口默认为5050）

  以SparkPi为例，在Mesos模式下的应用程序启动命令如下：

         ./bin/run-example org.apache.spark.examples.SparkPi mesos://10.0.2.31:5050

• 内部实现原理

  在该模式中，资源的调度可以分为粗粒度和细粒度调度两种，相应的Spark分别使用CoarseMesosSchedulerBackend和MesosSchedulerBackend来配合TaskSchedulerImpl工作。

  

  

8.YARN standalone/YARN cluster模式

• 部署及程序运行

  0.9之前使用YARN standalone，1.0以后改为YARN cluster，通过Hadoop YARN框架来调度Spark应用所需要的资源。要将Spark集群运行在YARN模式下，首先部署一个YARN集群供该模式使用。实际中，这两者的因果关系往往是反过来的，这是因为用户有了一个YARN集群，也希望将Spark纳入YARN的调度管理之下，这样有利于系统的资源共享。

  在该模式下，需要通过额外的辅助程序来启动应用。
  

• 内部实现原理

  相对于其他模式，YARN cluster模式需要由外部程序辅助启动APP。用户的应用程序通过辅助的YARN Client类启动。

  

  Client类通过YARN Client API提交请求，在Hadoop集群上启动一个Spark ApplicationMaster，它首先注册自己为一个YARN ApplicationMaster，之后启动用户程序，SparkContext在用户程序中初始化时，使用CoarseGrainedSchedulerBackend配合YARNClusterScheduler（只是对TaskScheduler的一个简单封装，增加了对Executor的等待逻辑等）。

  根据Client类传递的参数，Spark ApplicationMaster通过YARN ResourceManager/NodeManager的接口在集群中启动若干个Container（容器），用于运行CoarseGrainedExecutorBackend。CoarseGrainedExecutorBackend在启动过程中会向CoarseGrainedSchedulerBackend注册。之后的任务调度流程同其他Cluster模式。

9.YARN client模式

• 部署及程序运行

  YARN client模式的部署准备工作和YARN standalone模式完全一致。由于该模式不直接暴露前面提到的用于提交YARN程序的辅助程序，所以许多参数是通过环境变量来设置的，可以配置的环境变量如下。

  SPARK_JAR：Spark自身JAR包的路径。

  SPARK_YARN_APP_JAR：应用APP的JAR包路径，在1.0版本中已经移除。

  SPARK_WORKER_INSTANCES：需要启动的Worker的数量（默认为2）。

  SPARK_WORKER_CORES：每个Worker使用的CPU Core的数量（默认为1）。

  SPARK_WORKER_MEMORY：每个Worker使用的内存数量（默认为1GB）。

  SPARK_MASTER_MEMORY：Master节点的内存大小（默认为512MB）。

  SPARK_YARN_APP_NAME：应用程序在YARN框架中使用的名字（默认为Spark）。

  SPARK_YARN_QUEUE：资源分配时使用的YARN的队列（默认为'default'）。

  SPARK_YARN_DIST_FILES：需要随作业分发到集群上的文件。

  SPARK_YARN_DIST_ARCHIVES：需要随作业分发到集群上的压缩包。

  这些环境变量可以在spark-env.sh中配置，也可以在启动应用时设置。

• 内部实现原理

  在YARN cluster模式中，应用程序（包括SparkContext）都是作为YARN框架所需要的Application Master，再由YARN ResourceManager为其分配的一个随机节点上运行。而在YARN client模式中，SparkContext运行在本地，该模式适用于应用程序本身需要在本地进行交互的场合，如Spark Shell、Shark等。

  

  SparkContext在初始化过程中启动YARNClientSchedulerBackend（拓展自CoarseGrainedSchedulerBackend），该Backend进一步调用org.apache.spark.deploy.yarn.Client在远程启动一个WorkerLauncher作为Spark的Application Master，相比于YARN standalone模式，WorkerLauncher不再负责用户程序的启动（已在客户端本地启动），而只是启动Container运行CoarseGrainedExecutorBackend与客户端本地的Driver进行通信，后续任务调度流程相同。

转载于:https://my.oschina.net/xingkongxia/blog/612714