Spark 任务提交流程说明

前言
Spark on Yarn集群管理方式
- Yarn-Client 任务提交方式
- Yarn-Cluster 任务提交方式
Spark Standalone集群管理方式
- Standalone Client 提交任务方式
- Standalone Cluster 提交任务方式
总结

前言

本篇主要阐述 Spark 任务提交的流程，其主要目的在于通过了解 Spark 任务提交可以清楚大概的流程，并知道每一步是做什么；当遇到问题可以快速的知道是什么环节或者哪一步骤出现了问题，及时定位到问题并解决。目前Spark官方支持五中集群管理模式，分别是 Standalone、Yarn、Mesoes、Kubernetes、Amazon EC2 等。本篇文章主要阐述笔者平时经常使用的 Standalone 与 Yarn 集群管理模式。

Spark Standalone模式：该模式是不借助于第三方资源管理框架的完全分布式模式。Spark 使用自己的 Master 进程对应用程序运行过程中所需的资源进行调度和管理；对于中小规模的 Spark 集群首选 Standalone 模式。目前Spark 在 Standalone 模式下主要是借助 Zookeeper 实现单点故障问题；思想也是类似于 Hbase Master 单点故障解决方案。

Spark on Yarn模式：该模式是借助于第三方资源管理框架 Yarn 的完全分布式模式。Spark 作为一个提交程序的客户端将 Job 任务提交到 Yarn 上；然后通过 Yarn 来调度和管理 Job 任务执行过程中所需的资源。需要此模式需要先搭建 Yarn 集群，然后将 Spark 作为 Hadoop 中的一个组件纳入到 Yarn 的调度管理下，这样将更有利于系统资源的共享。

Spark on Yarn集群管理方式

Yarn-Client 任务提交方式

在 YARN Client 模式下，spark-submit提交 Spark Job之后，就会提交的本地机器上启动一个对应的 Driver；
Driver 启动后会与 ResourceManager 建立通讯并发起启动 ApplicationMaster 请求；
ResourceManage 接收到这个 Job 时，会在集群中选一个合适的 NodeManager 并分配一个 Container，及启动 ApplicationMaster（初始化SparkContext）；
ApplicationMaster 的功能相当于一个 ExecutorLaucher ，负责向 ResourceManager 申请 Container 资源； ResourceManage 便会与 NodeManager 通信，并启动 Container；
ApplicationMaster 对指定 NodeManager 分配的 Container 发出启动 Executor 进程请求；
Executor进程启动后会向 Driver 反向注册，Executor 全部注册完成后 Driver 开始执行执行 Job 任务；
Driver 中的 SparkContext 分配 Task 给 Executor 执行，Executor 运行 Task 并向 Driver 汇报运行的状态、进度、以及最终的计算结果；让 Driver 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
应用程序运行完成后，ApplicationMaster 向 ResourceManager 申请注销并关闭自己。

==> Spark 参数说明

==> Spark 任务提交流程涉及源码说明

Yarn-Cluster 任务提交方式

在 YARN Cluster 模式下，Spark 任务提交之后会与 ResourceManager 建立通讯，并发出申请启动 ApplicationMaster 请求；
ResourceManage 接收到这个 Job 时，会在集群中选一个合适的 NodeManager 并分配一个 Container；以及启动 ApplicationMaster ，此时的 ApplicationMaster 就是 Driver ；
ApplicationMaster 启动后向 ResourceManager 申请资源，ResourceManager 接到 ApplicationMaster 的资源申请后会在合适（有资源的情况下）的 NodeManager 中分配 Container；
ApplicationMaster 对指定 NodeManager 分配的 Container 发出启动 Executor 进程请求；
Executor 进程启动后会向 Driver 反向注册，Executor 全部注册完成后 Driver 开始执行执行 Job 任务；
ApplicationMaster 中的 SparkContext 分配 Task 给 Executor 执行，Executor 运行 Task 并向ApplicationMaster 汇报运行的状态、进度、以及最终的计算结果；让 ApplicationMaster 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
应用程序运行完成后，ApplicationMaster 向 ResourceManager 申请注销并关闭自己；

Spark Standalone集群管理方式

Standalone Client 提交任务方式

在 Standalone Client 模式下，spark-submit提交 Spark Job之后，就会提交的本地机器上启动一个对应的 Driver；
Driver 会与 Master 建立通讯，并发出申请启动 Executor 资源的请求；
Master 会通知合适的 Worker 启动 Executor 进程；
Executor 进程启动后会向 Driver 反向注册，Executor 全部注册完成后 Driver 开始执行执行 Job 任务；
Driver 分配 Task 给 Executor 执行，Executor 运行 Task 并向 Driver 汇报运行的状态、进度、以及最终的计算结果；让 Driver 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
Job 任务完成之后，Driver 会向 Master 申请注销并关闭自己；

Standalone Cluster 提交任务方式

在 Standalone Cluster 模式下，Spark 任务提交之后会与 Master 建立通讯，并发出申请启动 Driver的请求；
Master 接收到这个 Job 时，会在集群中选一个合适的 Worker 并分配一个 Driver；
Driver 启动后为当前的 Spark Job申请资源；
Master 会通知合适的 Worker 启动 Executor 进程；
Executor 进程启动后会向 Driver 反向注册，Executor 全部注册完成后 Driver 开始执行执行 Job 任务；
Driver 分配 Task 给 Executor 执行，Executor 运行 Task 并向 Driver 汇报运行的状态、进度、以及最终的计算结果；让 Driver 随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务；
Job 任务完成之后，Driver 会向 Master 申请注销并关闭自己；

总结

Spark standalone 与 Spark on Yarn 都是资源调度管理，底层实现的方式不一样。Standalone 模式只支持简单的 FIFO 调度器（单用户串行，排队先来先执行），而 Yarn 有 FIFO 调度器、容器调度器（Capacity Scheduler）、公平调度器（Fair Scheduler）等三种；可以实现动态资源的扩展，以及资源调度更为灵活。
目前笔者所了解使用更多的是 Yarn 资源调度器，其 Yarn 资源调度器也是基于 Hadoop 集群；Standalone 资源调度器是基于 Spark 集群，相对于 Hadoop 集群其的生态更为完善，有利于进行集群的扩展于维护。
Yarn Client 与 Yarn Cluster 任务提交方式两者区别，可以通过上面的 Spark 任务提交流程图可以看出来；主要区别在于 Driver的创建的位置不一样，Client 方式是直接在本地机器上创建一个 Driver 进程，而 Cluster 方式在通过 ResourceManager 在某一个 NodeManager 中创建一个 Driver。
在使用场景当中，Yarn Client 方式一般适用于进行 Job 的调试（Debug），因为 Driver 是在本地可以直接远程断点调试，而且 Driver 会与 Executor 进行大量的通信就会造成占用大量 IO ；Yarn Cluster 方式一般适用于生产环境，因为 Driver 运行在某一个 NodeManager 中就不会出现某一台机器出现网卡激增的情况，缺点就是运行的 Job 日志不能在机器本地实时查看而是需要通过 Job Web 界面查看。

参考链接：https://spark.apache.org/docs/3.2.1/spark-standalone.html