赞
踩
部分内容摘自尚硅谷、黑马等等培训资料
数据、程序、运算资源(内存、cpu)三者组在一起,完成了数据的计算处理过程。在单机环境下,这些都不是太大问题。为了应对海量数据的场景,Hadoop 出现并提供了分而治之的分布式处理思想。通过对 Hadoop 版本演进的简单回顾,可以让我们知道 YARN 的产生和发展简史,洞悉 YARN 发展进程。
很多 Hadoop 的早期用户使用 Hadoop 的方式与在众多主机上运行桌面应用程序类似。
这种方式的一部分原因是没有在 Hadoop HDFS 上持久存储数据的迫切需求,另一部分原因是没有共享数据和计算结果的动机。
Ad Hoc
应当理解为专用、特定
的意思(数仓领域中常理解为即席查询)。Ad Hoc 集群时代标志着 Hadoop 集群的起源,集群以Ad Hoc、单用户方式
建立。
后来,随着私人集群的使用和 Hadoop 容错性的提高,持久的 HDFS 集群出现,并且实现了 HDFS 集群的共享,把常用和感兴趣的数据集载入 HDFS 共享集群中。当共享 HDFS 成为现实,还没实现共享的计算平台就成为关切对象。
不同于 HDFS,为多个组织的多个用户简单设置一个共享 MapReduce 集群并非易事。尤其是集群下的物理资源的共享很不理想。
为了解决集群条件下的多租户问题, Yahoo 发展并且部署了称为 “Hadoop on Demand” 的平台。Hadoop On Demand(HOD)是一个能在大规模物理集群上供应虚拟 Hadoop 集群的系统。在已经分配的节点上, HOD 会启动 MapReduce 和 HDFS 守护进程来响应用户数据和应用的请求。
HOD 的主要特点是用户可以使用 HOD 来同时分配多个 MapReduce 集群。
HOD 的缺点包括:无法支持数据本地化、资源回收效率低、无动态扩容缩容能力,多租户共享延迟高等。
共享 MapReduce 计算集群和与之协同工作的共享 HDFS 是 Hadoop 1.x 版本里的主要架构。
这种共享计算架构的主要组件如下所示:
JobTracker
:一个中央守护进程,负责运行集群上的所有作业。
TaskTracker
:系统里的从进程,根据 JobTracker 的指令来执行任务。
共享计算集群的主要弊端有 JobTracker 可扩展性瓶颈(JobTracker 在内存中保存用户作业的数据)、JobTracker 身兼多职(作业数据管理、作业状态记录、作业调度、)、可靠性和可用性欠缺(JobTracker 单点故障)、计算模型的单一(不是所有问题都能 MapReduce)。
并且 MapReduce 框架本身也经历了很多变化。但是 MapReduce 被绑定到了集群的管理层,证明 MapReduce 的变化演变是比较困难的。
针对共享计算集群,JobTracker 需要彻底地重写,才能解决扩展性的主要问题。但是,这种重写即使成功了,也不一定能解决平台和用户代码的耦合问题,也不能解决用户对非 MapReduce 编程模型的需求。如果不做重大的重新设计,集群可用性会继续被捆绑到整个系统的稳定性上。
YARN 闪亮登场了,一款被设计用以解决以往架构的需求和缺陷的资源管理和调度软件。经过之前的发展,Hadoop 走下了不少的弯路,甚至跳进了一些深坑。因此对于 YARN 的每个重大决策背后都有完整的惨痛的历史。
Apache Hadoop YARN (Yet Another Resource Negotiator,另一种资源协调者)是一种新的 Hadoop 资源管理器,它是一个通用资源管理系统和调度平台,可为上层应用提供统一的资源管理和调度,它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
可以把 Hadoop YARN 理解为相当于一个分布式的操作系统平台
,而 MapReduce 等计算程序则相当于运行于操作系统之上的应用程序,YARN 为这些程序提供运算所需的资源(内存、cpu 等)。
YARN 是一个分布式的资源管理系统,用以提高分布式的集群环境下的资源利用率,这些资源包括内存、IO、网络、磁盘等。其产生的原因是为了解决原 MapReduce 框架的不足。最初 MapReduce 的 committer 们还可以周期性的在已有的代码上进行修改,可是随着代码的增加以及原 MapReduce 框架设计的不足,在原 MapReduce 框架上进行修改变得越来越困难,所以 MapReduce 的 committer 们决定从架构上重新设计 MapReduce,使下一代的 MapReduce (MRv2/Yarn)框架具有更好的扩展性、可用性、可靠性、向后兼容性和更高的资源利用率以及能支持除了 MapReduce 计算框架外的更多的计算框架。
由于 MRv1(第一代MapReduce)在扩展性、可靠性、资源利用率和多框架等方面存在明显不足, Apache 开始尝试对 MapReduce 进行升级改造,于是诞生了更加先进的下一代 MapReduce 计算框架 MRv2。
并且在 MRv2 中,将资源管理任务调度模块单独抽离出来,构建成了一个独立的通用资源管理系统 YARN,而 MRv2 则专注于数据的计算处理了。
在 Hadoop 1.0 中 MapReduce 框架(MRv1,第一代 MapReduce 框架),和 HDFS 一样,MapReduce 也是采用 Master/Slave 的架构,其架构如下图所示:
MapReduce 包含四个组成部分,分别为 Client,JobTracker,TaskTracker,Task。
在 Hadoop 1.0 中, JobTracker 由资源管理(由 TaskScheduler 模块实现)和作业控制(由 JobTracker 中多个模块共同实现)两部分组成,Hadoop 对 JobTracker 赋予的功能过多而造成负载过重。
Hadoop YARN 是在 MRv1 基础上演化而来的,它克服了 MRv1 中的各种局限性,概括为以下几个方面:
为了克服以上几个缺点, Apache 开始尝试对 Hadoop 进行升级改造,进而诞生了更加先进的下一代 MapReduce 计算框架 MRv2。正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN,直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN
。
YARN 实际上是一个弹性计算平台,它的目标已经不再局限于支持 MapReduce 一种计算框架,而是朝着对多种框架进行统一管理的方向发展。
Hadoop2.0 即第二代 Hadoop,由分布式存储系统HDFS、并行计算框架MapReduce和分布式资源管理系统YARN
三个系统组成,其中 YARN 是一个资源管理系统,负责集群资源管理和调度,MapReduce 则是运行在 YARN 上的离线处理框架,称为 MRv2(MapReduce 的第二版)。
MRv1 主要由编程模型(由新旧 API 组成)、数据处理引擎(由 MapTask 和 ReduceTask 组成)和运行时环境(由一个 JobTracker 和若干个 TaskTracker 组成)三部分组成,为了保证编程模型的向后兼容性, MRv2 重用了 MRv1 中的编程模型和数据处理引擎,但运行时环境被完全重写,具体如下:
YARN(Yet Another Resource Negotiator,另一种资源协调者) 是 Hadoop 2.0 中的资源管理系统,它的基本设计思想是将 MRv1 中的 JobTracker拆分成了两个独立的服务 :一个全局的资源管理器 ResourceManager 和每个应用程序特有的ApplicationMaster。
其中 ResourceManager 负责整个系统的资源管理和分配,而 ApplicationMaster 负责单个应用程序的管理。
官方架构图:
YARN 总体上仍然是 Master/Slave 结构(主从结构),在整个资源管理框架中,ResourceManager 为 Master, NodeManager 为 Slave,ResourceManager 负责对各个 NodeManager 上的资源进行统一管理和调度
。当用户提交一个应用程序时,需要提供一个用以跟踪和管理这个程序的ApplicationMaster,它负责向 ResourceManager 申请资源,并要求 NodeManger 启动可以占用一定资源的任务。由于不同的 ApplicationMaster 被分布到不同的节点上,因此它们之间不会相互影响。
上图描述了 YARN 的基本组成结构, YARN 主要由 ResourceManager、 NodeManager、ApplicationMaster(图中给出了 MapReduce 和 MPI 两种计算框架的 ApplicationMaster,分别为 MR AppMstr 和 MPI AppMstr)和 Container 等几个组件构成。
进程 | 描述 | 级别 |
---|---|---|
ResourceManager | 使用Scheduler(ResourceScheduler类)和ApplicationManager(RMAppManager类)分配群集资源 | 守护进程 |
ApplicationMaster | 通过指示NodeManager创建或销毁Application的Container来管理Application的生命周期。一个Application只有一个ApplicationMaster进程 | 用户进程 |
NodeManager | 通过在群集节点中创建和销毁容器来管理特定节点中的作业或工作流 | 守护进程 |
Container | Container是Yarn对计算资源的抽象,它其实是一组CPU和内存资源,所有的应用都会运行在Container中 | 用户进程 |
RM(ResourceManager) 是一个全局的资源管理器,负责整个系统的资源管理和分配。它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager, ASM)。
用户提交的每个应用程序均包含一个 AM,主要功能包括:
当前 YARN 自带了两个 AM 实现,一个是用于演示 AM 编写方法的例程序 distributedshell,它可以申请一定数目的 Container 以并行运行一个 Shell 命令或者 Shell 脚本 ;另一个是运行 MapReduce 应用程序的 AM—MRAppMaster,此外,一些其他的计算框架对应的 AM 正在开发中,比如 Spark、Flink 等。
NM(NodeManager) 是每个节点上的资源和任务管理器,一方面,它会定时地向 RM 汇报本节点上的资源使用情况和各个 Container 的运行状态;另一方面,它接收并处理来自 AM 的 Container 启动/停止等各种请求。
Container 是 YARN 中的资源抽象,它封装了某个节点上的多维度资源,如内存、CPU、磁盘、网络等,当 AM 向 RM 申请资源时, RM 为 AM 返回的资源便是用 Container表示的。 YARN 会为每个任务分配一个 Container,且该任务只能使用该 Container 中描述的资源。需要注意的是, Container 不同于 MRv1 中的 slot,它是一个动态资源划分单位,是根据应用程序的需求动态生成的。当下, YARN 仅支持 CPU 和内存两种资源,且使用了轻量级资源隔离机制 Cgroups 进行资源隔离 。
YARN 支持各种数据处理引擎对 HDFS 中的数据进行批处理、交互式和流处理。在不同的场景中使用不同的框架,常见的包括 MapReduce、Spark、Storm 和 Flink 等 Application。这种架构可以更好、更优雅地进行扩展。因此从一开始就内置了高可用性、安全性和多租户支持更多用户在大型集群上使用,新架构还将提高创新性,敏捷性和硬件利用率。
此外,YARN 提供以下功能:
RPC 协议是连接各个组件的“大动脉”,了解不同组件之间的 RPC 协议有助于更深入地理解学习 YARN 框架。在 YARN 中,任何两个需相互通信的组件之间仅有一个 RPC 协议,而对于任何一个 RPC 协议,通信双方有一端是 Client,另一端为 Server,且 Client 总是主动连接 Server 的
,因此, YARN 实际上采用的是拉式(pull-based)通信模型。
如上图所示,箭头指向的组件是 RPC Server,而箭头尾部的组件是 RPC Client, YARN 主要由以下几个 RPC 协议组成 :
运行在 Hadoop YARN 上的应用程序主要分为两类 :短应用程序和长应用程序。
尽管这两类应用程序作用不同,一类直接运行数据处理程序,一类用于部署服务(服务之上再运行数据处理程序),但运行在 YARN 上的流程是相同的。
当用户向 YARN 中提交一个应用程序后, YARN 将分两个阶段运行该应用程序 :第一个阶段是启动 ApplicationMaster ;第二个阶段是由 ApplicationMaster 创建应用程序,为它申请资源,并监控它的整个运行过程,直到运行完成。
如上图所示, YARN 的工作流程分为以下几个步骤:
YARN 正是一个资源管理系统,它的出现弱化了计算框架之争,引入 YARN 这一层后,各种计算框架可各自发挥自己的优势,并由 YARN 进行统一管理,进而运行在一个大集群上。
Job提交过程之YARN:
Job提交过程之HDFS & MapReduce:
作业提交全过程详解:
job.waitForCompletion
方法,向整个集群提交 MapReduce 作业。mapreduce.client.progressmonitor.pollinterval
设置)向应用管理器请求进度更新,展示给用户。 除了向应用管理器请求作业进度外,客户端每 5 秒都会通过调用waitForCompletion()
来检查作业是否完成。时间间隔可以通过mapreduce.client.completion.pollinterval
来设置。作业完成之后,应用管理器和 Container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。