Spark的分布式运行模式 Local，Standalone, Spark on Mesos, Spark on Yarn, Kubernetes

Spark的分布式运行模式 Local，Standalone, Spark on Mesos, Spark on Yarn, Kubernetes

• Local模式
• Standalone模式
• Spark on Mesos模式
• Spark on Yarn
• Kubernetes模式

 

Local模式

Standalone模式的单机版，Master和Worker分别运行在一台机器的不同进程上

Standalone模式

Standalone模式即独立模式，自带完整的服务，可以单独部署到一个集群中，不需要任何的资源管理系统，只支持FIFO调度，在该模式下没有AM和NM的概念，也没有RM的概念，用户节点直接与Master交互，由Driver负责向Master申请资源，由Driver进行资源的分配和调度等。目前Spark在Standalone模式下是没有任何单点故障问题的，借助了zk思想类似hbase Master单点故障解决方案。 各个节点上的资源被抽象成粗粒度的slot，有多少slot就能同时运行多少task。

Spark on Mesos模式

Spark on Mesos模式。在Spark on Mesos环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考Andrew Xia的“Mesos Scheduling Mode on Spark”）

粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个Dirver和若干个Executor组成，其中，每个Executor占用若干资源，内部可运行多个Task（对应多少个“slot”）。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。举个例子，比如你提交应用程序时，指定使用5个executor运行你的应用程序，每个executor占用5GB内存和5个CPU，每个executor内部设置了5个slot，则Mesos需要先为executor分配资源并启动它们，之后开始调度任务。另外，在程序运行过程中，Mesos的Master和slave并不知道executor内部各个task的运行情况，executor直接将任务状态通过内部的通信机制汇报给Driver，从一定程度上可以认为，每个应用程序利用Mesos搭建了一个虚拟集群自己使用。

细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资源浪费，Spark on Mesos还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。与粗粒度模式一样，应用程序启动时，先会启动executor，但每个executor占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，Mesos会为每个executor动态分配资源，每分配一些，便可以运行一个新任务，单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于MapReduce调度模式，每个Task完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。

Spark on Yarn

当在Spark on Yarn模式下，每个Spark Executor作为一个Yarn Container在运行，同时支持多个任务在同一个Container中运行，极大地节省了任务的启动时间。在Spark中，有Yarn-Client和Yarn-cluster两种模式可以运行在Yarn上，下面是两种的区别
（1）SparkContext初始化不同，这也导致了Driver所在位置的不同，Yarn-Cluster的Driver是在集群的某一台NM上，Yarn-Client 的Driver运行在客户端
（2）而Driver会和Executors进行通信，这也导致了Yarn-Cluster在提交App之后可以关闭Client，而Yarn-Client不可以；
（3）最后再来说应用场景，Yarn-Cluster适合生产环境，Yarn-Client适合交互和调试。

Yarn-cluster
在该模式下，Driver运行在Appliaction Master上，Appliaction Master进程同时负责驱动Application和从Yarn中申请资源，该进程运行在Yarn Container内，所以启动Application Master的Client可以立即关闭而不必持续到Application的生命周期结束。

Yarn-Client
在Yarn-Client中，Application Master仅仅从Yarn中申请资源给Executor，之后Client会跟Container通信进行作业的调度

下表是不同模式下的比较

Kubernetes模式

使用Kubernetes原生调度的Spark on Kubernetes是对现有的Spark on Yarn/Mesos的资源使用方式的革命性的改进，主要表现在以下几点：

Kubernetes原生调度：不再需要二层调度，直接使用Kubernetes的资源调度功能，跟其他应用共用整个Kubernetes管理的资源池；
资源隔离，粒度更细：原先Yarn中的queue在Spark on Kubernetes中已不存在，取而代之的是Kubernetes中原生的namespace，可以为每个用户分别指定一个namespace，限制用户的资源quota；
细粒度的资源分配：可以给每个Spark任务指定资源限制，实际指定多少资源就使用多少资源，因为没有了像Yarn那样的二层调度（圈地式的），所以可以更高效和细粒度的使用资源；
监控的变革：因为做到了细粒度的资源分配，所以可以对用户提交的每一个任务做到资源使用的监控，从而判断用户的资源使用情况，所有的metric都记录在数据库中，甚至可以为每个用户的每次任务提交计量；
日志的变革：用户不再通过Yarn的web页面来查看任务状态，而是通过pod的log来查看，可将所有的kuberentes中的应用的日志等同看待收集起来，然后可以根据标签查看对应应用的日志；
所有这些变革都可以让我们更高效的获取资源、更有效率的获取资源！

参考资料:
apache-Spark-resource-management-and-Yarn-app-models
running-Spark-with-Kubernetes-native-scheduler

————————————————

standalone 作为 spark 自带的分布式部署模式，是最简单也是最基本的 spark 应用程序部署模式。

 yarn 和 mesos 的区别：
    (1) 就两种框架本身而言，mesos上可部署 yarn 框架。而 yarn 是更通用的一种部署框架，而且技术较成熟。
    (2) mesos 双层调度机制，能支持多种调度模式，而 yarn 通过 Resource　Mananger 管理集群资源，只能使用一种调度模式。Mesos 的双层调度机制为：mesos 可接入如 yarn 一般的分布式部署框架，但 Mesos 要求可接入的框架必须有一个调度器模块，该调度器负责框架内部的任务调度。当一个 Framework 想要接入 mesos 时，需要修改自己的调度器，以便向 mesos 注册，并获取 mesos 分配给自己的资源，这样再由自己的调度器将这些资源分配给框架中的任务，也就是说，整个 mesos 系统采用了双层调度框架：第一层，由 mesos 将资源分配给框架；第二层，框架自己的调度器将资源分配给自己内部的任务。
    (3) mesos 可实现粗、细粒度资源调度，可动态分配资源，而 yarn 只能实现静态资源分配。其中粗粒度和细粒度调度定义如下：
    粗粒度模式（Coarse-grained Mode）：程序运行之前就要把所需要的各种资源（每个 executor 占用多少资源，内部可运行多少个 executor）申请好，运行过程中不能改变。
    细粒度模式（Fine-grained Mode）：为了防止资源浪费，对资源进行按需分配。与粗粒度模式一样，应用程序启动时，先会启动 executor，但每个 executor 占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos 会为每个 executor 动态分配资源，每分配一些，便可以运行一个新任务，单个 Task 运行完之后可以马上释放对应的资源。每个 Task 会汇报状态给 Mesos Slave 和 Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于 MapReduce 调度模式，每个 Task 完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。
    从 yarn 和 mesos 的区别可看出，它们各自有优缺点。因此实际使用中，选择哪种框架，要根据本公司的实际需要而定，可考虑现有的大数据生态环境。如我司采用 yarn 部署 spark，原因是，我司早已有较成熟的 hadoop 的框架，考虑到使用的方便性，采用了 yarn 模式的部署。