Spark on Yarn | Spark,从入门到精通

欢迎阅读美图数据技术团队的「Spark,从入门到精通」系列文章,本系列文章将由浅入深为大家介绍 Spark,从框架入门到底层架构的实现,相信总有一种姿势适合你,欢迎大家持续关注:)

往期直通车:Hello Spark!

/ 为什么需要 Yarn? /

Yarn 的全称是 Yet Anther Resource Negotiator(另一种资源协商者)。它作为 Hadoop 的一个组件,官方对它的定义是一个工作调度和集群资源管理的框架

Yarn 最早出现于 Hadoop 0.23 分支中,0.23 分支是一个实验性分支,之后经过了几次迭代,最后发布于 2014 年 6 月的 0.23.11 版本(该分支的最后一个版本)。在 0.23.0 发布后不久的 2011 年 12 月,Hadoop 的 0.20 分支发展成了 Hadoop1.0,一直到 1.0 的最后一个版本 1.2.1-stable 都没有出现 Yarn 的身影,而在 Hadoop2.0 的第一个版本 2.0.0-alpha,Yarn 已经作为一个正式组件加入。在 2.0.2-alpha 版本,它已经支持了 2k 台机器的集群,接着在 2.0.3-alpha 版本中已经可以支持 30k 台机器的集群。在 2.0.3-alpha 版本中同时还支持了多种资源,如 cpu&memory 的调度和 ResourceManager restart。

图 1,via https://blog.csdn.net/suifeng3051/article/details/49364677

如图 1 所示, Hadoop1.0 的运作流程如下:

1.客户端提交任务给集群;

2.JobTracker 接收 Job 请求;

3.JobTracker 根据 Job 的输入参数向 NameNode 请求包含这些文件数据块的 DataNode 节点列表;

4.JobTracker 确定 Job 的执行计划:确认 Map、Reduce 的 Task 数量,并分配 Task 到离数据块最近的节点上执行。

最初,Hadoop1.0 能够很好地支撑大数据计算,但是随着计算规模的扩大和计算模型的多样化,它逐渐力不从心。众所周知当集群性能不足的时候可以简单粗暴地加机器,但 JobTracker 同时部署多个时只有一个是处于 active 状态,因此受限于这个 active JobTracker 的负载上限,整个集群能够容纳的机器也有限,有数据显示整个集群的管理上限约为 4k 台机器。同时应用程序相关和资源管理相关的逻辑全部放在 JobTracker中,当集群规模扩大的时候,会存在一个瓶颈。除此之外,Map-Reduce 计算模型与 JobTracker 的耦合过高,其他计算模型难以在 Hadoop1.0 上运行。

Yarn 是 Hadoop 基于这些问题的一个解决方案,接下来通过了解 Yarn 的组件、架构以及运作机制来分析 Yarn 是如何解决这些问题的。

/ Yarn 是什么? /

Yarn 的组件&基本架构

如图 2 所示 Yarn 采用 Master/Slave 结构,整体采用双层调度架构。在第一层的调度是 ResourceManager 和 NodeManager:ResourceManager 是 Master 节点,相当于 JobTracker,包含 Scheduler 和App Manager 两个组件,分管资源调度和应用管理;NodeManager 是 Slave 节点,可以部署在独立的机器上,用于管理机器上的资源。NodeManager 会向 ResourceManager 报告它的资源数量、使用情况,并接受 ResourceManager 的资源调度。

*ResourceManager 同 JobTracker 一样可以多机部署,并且只有一台处于 active 状态。但是在 ResourceManager 中将调度管理和应用管理作了拆分,两个组件的功能更专一。

图 2

第二层的调度指的是 NodeManager 和 Container。NodeManager 会将 Cpu&内存等资源抽象成一个个的 Container,并管理它们的生命周期。

通过采用双层调度结构将 Scheduler 管理的资源由细粒度的 Cpu&内存变成了粗粒度的 Container,降低了负载。在 App Manager 组件中也只需要管理 App Master,不需要管理任务调度执行的完整信息,同样降低了负载。通过降低 ResourceManager 的负载,变相地提高了集群的扩展性。

Yarn 运作流程

图 3,via https://blog.csdn.net/suifeng3051/article/details/49486927

如图 3 所示 Yarn 的运作流程如下:

1.客户端向 ResourceManager 的 App Manager 提交应用并请求一个 AppMaster 实例;

2.ResourceManager 找到可以运行一个 Container 的 NodeManager,并在这个 Container 中启动 AppMaster 实例;

3.App Master 向 ResourceManager 注册,注册之后,客户端就可以查询 ResourceManager 获得自己 App Master 的详情以及直接和 App Master 交互;

4.接着 App Master 向 Resource Manager 请求资源,即 Container;

5.获得 Container 后,App Master 启动 Container,并执行 Task;

6.Container 执行过程中会把运行进度和状态等信息发送给 AppMaster;

7.客户端主动和 App Master 交流应用的运行状态、进度更新等信息;

8.所有工作完成 App Master 向 RM 取消注册然后关闭,同时所有的 Container 也归还给系统。

通过这个 Job 的处理过程可以看到 App Master 是作为 Job 的驱动角色,它驱动了 Job 任务的调度执行。在这个运作流程中,App Manager 只需要管理 App Master 的生命周期以及保存它的内部状态,而 App Master 这个角色的抽象使得每种类型的应用都可以定制自己的 App Master,这样其他的计算模型就可以相对容易地运行在 Yarn 集群上。

Yarn HA(容灾备援)

接下来介绍的是 Yarn 集群高可用中关于容错备援的设计。根据图 3 所示的 Yarn 架构图,假如 Container 故障 Resource Manager 可以分配其他的 Container 继续执行,当运行 App Master 的 Container 故障后也将分配新的 Container,App Master 可以从 App Manager 获取信息恢复。当 NodeManager 故障的时候系统可以先把这个节点移除,在其他 NodeManager 重启再继续任务。

图 4,via https://www.cnblogs.com/sodawoods-blogs/p/8715231.html

那么当 ResourceManager 故障的时候呢?如上文所说的在 Yarn 集群中,ResourceManager 可以启动多台,只有其中一台是 active 状态的,其他都处于待命状态。这台 active 状态的 ResourceManager 执行的时候会向 ZooKeeper 集群写入它的状态,当它故障的时候这些 RM 首先选举出另外一台 leader 变为 active 状态,然后从 ZooKeeper 集群加载 ResourceManager 的状态。在转移的过程中它不接收新的 Job,转移完成后才接收新 Job。

/ Spark on Yarn /

首先介绍 Spark 的资源管理架构。Spark 集群考虑到了未来对接一些更强大的资源管理系统(如 Yarn、Mesos 等)没有在资源管理的设计上对外封闭,所以Spark 架构设计时将资源管理抽象出了一层,通过这种抽象能够构建一种插件式的资源管理模块。

图 5,via http://shiyanjun.cn/archives/1545.html

如图 5 所示是 Spark 的资源管理架构图。Master 是 Spark 的 主控节点,在实际的生产环境中会有多个 Master,只有一个 Master 处于 active 状态。Worker 是 Spark 的工作节点,向 Master 汇报自身的资源、Executeor 执行状态的改变,并接受 Master 的命令启动 Executor 或 Driver。Driver 是应用程序的驱动程序,每个应用包括许多小任务,Driver 负责推动这些小任务的有序执行。Executor 是 Spark 的工作进程,由 Worker 监管,负责具体任务的执行。

以上就是 Spark 在资源管理上的抽象出来的架构,这个架构跟 Yarn 的架构十分相似,因此 Spark 很容易地构建于 Yarn 之上。在 Spark 和 Yarn 两边的角色对比中:Master 和 ResourceManager 对应,Worker 和 NodeManager 对应,Driver 和 App Master 对应,Executor 和 Container 对应。

根据 Spark 部署模式的不同资源管理架构也会有不同的形态。Spark 大致包括四种部署模式:

  • Local 模式:部署在同一个进程上,只有 Driver 角色。接受任务后创建 Driver 负责应用的调度执行,不涉及 Master 和 Worker;
  • Local-Cluster 模式:部署在同一个进程上,存在 Master 和 Worker 角色,它们作为独立线程存在于这个进程内;
  • Standalone 模式:Spark 真正的集群模式,在这个模式下 Master 和 Worker 是独立的进程;
  • 第三方部署模式:构建于 Yarn 或 Mesos 之上,由它们提供资源管理。

接着看看 Spark on Yarn 对 Job 的处理过程。客户端提交一个任务给 Yarn ResourceManager 后,App Manager 接受任务并找到一个 Container 创建App Master,此时 App Master 上运行的是 Spark Driver。之后 App Master 申请 Container 并启动,Spark Driver 在 Container 上启动 Spark Executor,并调度 Spark Task 在 Spark Executor 上运行,等到所有的任务执行完毕后,向 App Manager 取消注册并释放资源。

图 6,via https://www.iteblog.com/archives/1223.html

可以看出这个执行流程和 Yarn 对一个任务的处理过程几乎一致,不同的是在 Spark on Yarn 的 Job 处理过程中 App Master、Container 是交由 Spark 相对应的角色去处理的。

图 7,via https://www.iteblog.com/archives/1223.html

Spark on Yarn 还有另外一种运行模式:Spark on Yarn-Client。不同于上述的 Spark on Yarn-Cluster,Spark on Yarn-Client 的客户端在提交完任务之后不会将 Spark Driver 托管给 Yarn,而是在客户端运行。App Master 申请完 Container 之后同样也是由 Spark Driver 去启动 Spark Executor,执行任务。

那为什么使用 Yarn 作为 Spark 的资源管理呢?我们来对比 Spark 集群模式 Standalone 和 Spark on Yarn 在资源调度能力上的区别:Spark 的 Standalone 模式只支持 FIFO 调度器,单用户串行,默认所有节点的所有资源对应用都是可用的;而 Yarn 不止支持 FIFO 的资源调度,还提供了弹性和公平的资源分配方式。

Yarn 是通过将资源分配给 queue 来进行资源分配的,每个 queue 可以设置它的资源分配方式,接着展开介绍 Yarn 的三种资源分配方式。

FIFO Scheduler

如果没有配置策略的话,所有的任务都提交到一个 default 队列,根据它们的提交顺序执行。富裕资源就执行任务,若资源不富裕就等待前面的任务执行完毕后释放资源,这就是 FIFO Scheduler 先入先出的分配方式。

图 8,via https://blog.csdn.net/suifeng3051/article/details/49508261

如图 8 所示,在 Job1 提交时占用了所有的资源,不久后 Job2提交了,但是此时系统中已经没有资源可以分配给它了。加入 Job1 是一个大任务,那么 Job2 就只能等待一段很长的时间才能获得执行的资源。所以先入先出的分配方式存在一个问题就是大任务会占用很多资源,造成后面的小任务等待时间太长而饿死,因此一般不使用这个默认配置。

Capacity Scheduler

Capacity Scheduler 是一种多租户、弹性的分配方式。每个租户一个队列,每个队列可以配置能使用的资源上限与下限(譬如 50%,达到这个上限后即使其他的资源空置着,也不可使用),通过配置可以令队列至少有资源下限配置的资源可使用。

图 9,via https://blog.csdn.net/suifeng3051/article/details/49508261

图 9 中队列 A 和队列 B 分配了相互独立的资源。Job1 提交给队列 A 执行,它只能使用队列 A 的资源。接着 Job2 提交给了队列B 就不必等待 Job1 释放资源了。这样就可以将大任务和小任务分配在两个队列中,这两个队列的资源相互独立,就不会造成小任务饿死的情况了。

Fair Scheduler

Fair Scheduler 是一种公平的分配方式,所谓的公平就是集群会尽可能地按配置的比例分配资源给队列。

图 10,via https://blog.csdn.net/suifeng3051/article/details/49508261

图 10 中 Job1 提交给队列 A,它占用了集群的所有资源。接着 Job2 提交给了队列 B,这时 Job1 就需要释放它的一半的资源给队列 A 中的 Job2 使用。接着 Job3 也提交给了队列 B,这个时候 Job2 如果还未执行完毕的话也必须释放一半的资源给 Job3。这就是公平的分配方式,在队列范围内所有任务享用到的资源都是均分的。

/ the Future of Spark /

Mesos 的资源调度和 Yarn 类似,但是它提供了粗粒度和细粒度的两种模式。所谓的粗粒度和细粒度的差别在于:Executor 申请的资源是在执行前申请,还是在执行过程中按需申请。集群资源紧张时可能有一个 Executor 申请的资源在当时处于闲置状态,如果处于粗粒度模式下,这些资源在当时就浪费了。但是在细粒度模式下,Executor 执行时所需的资源是按照它的需求分配的,这样就不存在资源闲置的情况了。

因为 Mesos 的 Executor 是可以动态调整,而 Yarn 使用的 Container 是不可以动态调整的,所以目前 Yarn 是不支持细粒度的调度模式的,但 Yarn 已经有计划支持细粒度的资源管理方式。

除此之外在 Hadoop3.1.0 中 Yarn 提供了对 gpu 资源的支持,目前只支持 Nvidia gpu。期待 Spark 在其他方面的更多探索,下一篇我们将具体介绍 RDD,欢迎持续关注。

原文发布于微信公众号 - 美图数据技术团队(gh_feb1d206d92b)

原文发表时间:2018-08-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏算法channel

HDFS|基本概念和读写原理

01 — HDFS设计目的 A distributed file system that provides high-throughput access to ...

40770
来自专栏AILearning

Apache Spark 2.2.0 中文文档 - 概述 | ApacheCN

Spark 概述 Apache Spark 是一个快速的, 多用途的集群计算系统。 它提供了 Java, Scala, Python 和 R 的高级 API...

39390
来自专栏kevindroid

Hadoop Yarn初探

29860
来自专栏about云

CDH(Cloudera)与hadoop(apache)对比

问题导读: 1.hadoop有几个版本? 2.CDH有几种安装方式? 3.CDH在安装认证方面做了什么改变? Cloudera的CDH和Apache的H...

55160
来自专栏数据和云

深入学习:In Memory Undo

黄玮(Fuyuncat) 资深 Oracle DBA,从事 Oracle 数据库管理、维护与开发工作十余年,有丰富的大型数据库设计、开发与维护方面的经验。个人网...

35280
来自专栏鸿的学习笔记

hadoop系统概览(三)

大数据不可避免地需要在计算机集群上进行分布式并行计算。因此,我们需要一个分布式数据操作系统来管理各种资源,数据和计算任务。今天,Apache Hadoop是现有...

10410
来自专栏牛肉圆粉不加葱

Spark Streaming + Kakfa 编程指北

本文简述如何结合 Spark Streaming 和 Kakfa 来做实时计算。截止目前(2016-03-27)有两种方式:

11540
来自专栏美图数据技术团队

Spark on Yarn | Spark,从入门到精通

欢迎阅读美图数据技术团队的「Spark,从入门到精通」系列文章,本系列文章将由浅入深为大家介绍 Spark,从框架入门到底层架构的实现,相信总有一种姿势适合你,...

23000
来自专栏祝威廉

Spark Streaming 数据接收优化

看这篇文章前,请先移步Spark Streaming 数据产生与导入相关的内存分析, 文章重点讲的是从Kafka消费到数据进入BlockManager的这条线路...

11710
来自专栏灯塔大数据

每周学点大数据 | No.64 配置Hadoop

NO.64 配置Hadoop 在开始使用Hadoop 之前,先要对Hadoop 进行配置。Hadoop 的配置分为单机模式、完全分布式、伪分布式三种。单机模式一...

362100

扫码关注云+社区

领取腾讯云代金券