Hadoop知识点归纳2

二．YARN

1.  YARN产生原因

① MRv1的局限性：扩展性差 、可靠性差、 资源利用率低、 无法支持多种计算框架、只能处理离线数据

② YARN是轻量级弹性计算平台。将所有不同的框架都部署到一个公共的集群中，让他们共享集群资源，并对资源进行统一使用。采用某种资源隔离方案对各个任务进行隔离。

③ 相比“一种计算框架一个集群”的模式， 共享集群模式的好处： 资源利用率高、 运维成本低 、数据共享。

2.  YARN的基本设计思想

① 基本框架对比

1.0：JobTracker由资源管理和 作业控制两部分组成

     由于JobTracker赋予的功能过多而造成负载过重

未能将资源管理相关功能与应用程序相关功能分开，造成 Hadoop难以支持多种计算框架

2.0：将JobTracker的 两个主要功能分拆成两个独立的进程

资源管理进程与具体应用程序无关，负责整个集群的资源管理

作业控制进程直接与应用程序相关模块进行通信，且每个作业控制进程只负责管理 一个作业

② 编程模型对比

MRv1主要由编程模型、数据处理引擎和运行环境三部分组成

MRv2重用了 其编程模型和数据处理引擎，但运行环境被完全重写

（MapReduce编程接口有两套：新API和旧API 。 采用MRv1旧API编写的程序可直接使用之前的 Jar包将程序运行在MRv2上 ，但采用MRv1新API编写的程序需要使用MRv2编程库重新编译并修改不兼容参数和返回值）

③ MRv1运行环境由JobTracker和TaskTracker组成； JobTracker负责资源和任务的管理与调度； TaskTracker负责单个节点的资源管理和任务执行

MRv2运行环境将资源管理和应用程序管理剥离，由ResourceManager和 ApplicationMaster负责； ResourceManager专管资源管理和调度； ApplicationMaster负责与具体应用程序相关 的任务切分、任务调度和容错。

3.  YARN基本架构（2.0中的资源管理系统）

① 基本设计思想是将MRv1中的JobTracker 拆分为两个独立的服务：

全局的资源管理器ResourceManager，负责整个系统的资源管理和分配

每个应用程序特有的ApplicationMaster，负责单个应用程序的管理

② YARN基本组成结构

YARN总体上仍然是Master/Slaves结构

在整个资源管理框架中， ResourceManager为Master， NodeManager为Slaves

ResourceManager负责对各个NodeManager上的资源进行统一管理和调度

当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster

负责向ResourceManager申请资源，并 要求NodeManager启动可以占用一定资 源的任务

 由于不同的ApplicationMaster被分布到不 同的节点上，因此它们之间不会相互影响

（Map与Reduce是否异地启动取决于负载均衡

描述MR整个生命周期的粒度：job(作业)->Task（任务）->taskattempt（运行任务的实例））

l  ResourceManager（RM）

 主要由两个组件构成：

Ø  调度器（Scheduler），

根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序； 而资源分配单位用一个抽象概念 “Container”，Container是一个动态资源 分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源 量

Ø  应用程序管理器（ApplicationsManager， ASM）

负责管理整个系统中所有应用程序还包括应用程序提交，与调度器协商资源以启动ApplicationMaster，监控 ApplicationMaster运行状态，并在失败时重 新启动它

l  ApplicationMaster（AM）

用户提交的每个应用程序均包含一个AM，主要功能包括：

Ø  与RM调度器协商以获取资源

Ø  将得到的任务进一步分配给内部的任务

Ø  与NM通信以启动/停止任务

Ø  监控或跟踪所有任务运行状态，并在任务运行失败或者硬件故障时重新为任务申请资源以重启任务

l  NodeManager（NM）

Ø  NM是每个节点上的资源和任务管理器

Ø  一方面，它会定时向RM汇报本节点上的资源使用情况和各个Container的运行状态

Ø  另一方面，它接收并处理来自AM的 Container启动/停止等各种请求

l  Container

Ø  Container是YARN中的资源抽象，封装了 某个节点上的多维度资源

Ø  内存、磁盘、网络、CPU

Ø  当AM向RM申请资源时，RM为AM返回的资源便用Container表示

Ø  YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源

Ø  Container是一个动态资源划分单位，是根 据应用程序的需求动态生成的

③ YARN通信协议

²  RPC协议：远程过程调用协议，它是一种 通过网络从远程计算机程序上请求服务， 使用此协议不需要了解底层网络技术。

²   在YARN中，任何两个需相互通信的组件之 间仅有一个RPC协议

²  通信双方一端是Client，一端是Server，且 Client总是主动连接Serve

4.  YARN工作流程

²  短应用程序 一定时间内可运行完成并正常退出的应用程序， 如MapReduce作业

²  长应用程序 不出意外，永不终止运行的应用程序，通常是 一些服务，如Hbase Service、Storm Service

n  当用户向YARN中提交一个应用程序后， YARN将分两个阶段运行应用程序：

阶段1：启动ApplicationMaster

阶段2：由ApplicationMaster创建应用程 序，为它申请资源，监控整个运行过程， 直到运行完成

n   

① 用户向YARN提交应用程序

② RM为应用程序分配第一个Container;与对应的NodeManager进行通信，要求NM在此Container中启动应用程序AM（MRAppMstr）

③ AM向RM注册，用户可直接通过RM查询应用程序的运行状态，然后为各个任务申请资源，监控运行状态，直到程序结束

④ AM采用轮询方式向RM申请和领取资源

⑤ 一旦AM申请到资源就会与NM进行通信要求启动任务

⑥ NM为任务设置好运行环境后，将任务启动的命令用脚本运行的方式启动

⑦ 各个任务通过RPC协议向AM报告状态和进度，如果任务失败将重启该任务

⑧ 应用程序运行结束时，AM会向RM发出请求，注销和关闭自己

5.  YARN总结与发展趋势（了解）

① 资源管理系统设计动机

 尽管目前YARN的设计框架比较适合运行类似 于MapReduce这样的短作业，但它最终的定位是通用资源管理系统。

此类系统的动机主要解决以下两类问题：

²  提供集群资源利用率

²  服务自动化部署

② 资源管理系统架构演化

u 集中式架构

资源的调度和应用程序的管理功能全部放 到一个进程中完成，开源届的典型代表是 JobTracker的实现。

 缺点：集群规模受限；新的调度策略难以 融入现有代码中

u 双层调度架构

该架构可以看做一种分而治之的机制或是策略下发机制。 双层调度器仍保留一个经简化的集中式资源调度器，但具体任务相关的调度策略下放到各个应用程序调度器中完成。

 典型代表是Mesos和YARN。

²  双层调度器的特点： 各个框架调度器并不知道整个集群资源使 用情况，只是被动的接收资源；

 资源调度器仅将可用的资源推送给各个框 架，而由框架自己选择是使用还是拒绝这 些资源；

 一旦框架接收到新资源，再进一步将资源 分配给其内部的任务，进而实现双层调度

²  双层调度器的缺点： 各个框架无法知道整个集群的实时资源使 用情况； 采用悲观锁，并发粒度小。

③ 共享状态架构

此架构将双层调度器中的集中式资源调度 模块简化成了一些持久化的共享数据和针对这些数据的验证代码；

而这里的“共享数据”实际上就是整个集 群的实时资源使用信息

④ YARN发展趋势

u YARN自身的完善

（1）  调度框架 当前YARN支持内存和CPU两种资源类型的 管理和分配； 服务器上还有许多其他资源，如磁盘容量、 网络和磁盘IO等，YARN可能在未来将支持 这些资源的调度和隔离。

（2）  在线升级 YARN作为一个通用资源管理平台，不仅可以运行短作业，还可以运行长作业。 对于长作业而言，由于它们需对外不间断 提供服务，因此，当YARN自身升级时，不应该干扰这类长作业。

（3）  容错机制 长作业和短作业的容错方式不同。 长作业由于它们通常拥有自己的客户端， 需为其不间断提供服务，因此，当这些作业出现故障时，应尝试本地重启，如果重 启失败，再尝试将其调度到其他节点上 短作业则一旦运行失败则换另外一个节点 重新运行

u 以YARN为核心的生态系统

YARN是未来的一个趋势，其本身已经变为 一个云操作系统，很多计算框架或应用程 序不再基于传统的操作系统开发，而是基于YARN这个云操作系统。

很多计算框架都在往YARN上迁移，如下：

 Tez 、Storm 、Spark、 Giraph、 OpenMPI

u YARN周边工具的完善

当前YARN对外提供的接口均是底层接口，这给用户编写和调试应用程序带来很大的 麻烦。

为了解决以上关于YARN上应用程序的创建、管理、调试等方面的问题，一些开源软件 诞生。

Weave针对YARN之上应用程序编写、调试和管理等方面的不完善，进行了以下改 进：

 一套经简化的、用于定义、运行和管理应用程 序的编程接口

一个通用的ApplicationMaster实现，以便直接部署简单的服务

应用程序的日志和Metric信息自动聚集呈现 Discovery服

课题作业

1.请介绍MRv1的局限性，并说明其理由

2.请介绍共享集群模式的好处，并说明其理由

3.请从基本框架和编程模型两方面对比 MRv1和MRv2

4.请阐述YARN的基本组成结构

5.请描述YARN的工作流程