Hadoop MapReduce2.0 架构详解

1. MapReduce 2.0 概述

Apache Hadoop 0.23比以前的版本有了很大的改进。以下是MapReduce的一些亮点;请注意,HDFS也有一些主要的改进,这些都不在本文的讨论范围之内。

MapReduce 2.0(又名MRv2YARN)。新的架构将JobTracker的两个主要功能 - 资源管理和作业生命周期管理 - 分解成单独的组件:

  • 管理计算资源到应用程序的全局分配的ResourceManager(RM)。
  • 每个应用程序的ApplicationMaster(AM),用于管理应用程序的生命周期。

Hadoop 0.23中,MapReduce应用程序是由MapReduce ApplicationMaster执行的MapReduce传统意义上的单一作业。

每个节点上还有一个NodeManager(NM),用于管理该节点上的用户进程。RMNM构成集群的计算框架。该设计还允许在NM中运行长时间的辅助服务(The design also allows plugging long-running auxiliary services to the NM);这些都是特定于应用程序的服务,作为配置的一部分进行指定,并在启动期间由NM加载。对于YARN上的MapReduce应用,shuffle是由NM加载的典型的辅助服务。请注意,在Hadoop 0.23版本之前,shuffleTaskTracker的一部分。

每个应用程序的ApplicationMaster是一个特定框架库,负责与ResourceManager协商资源,并与NodeManager一起来执行和监视这些任务。在YARN设计中,MapReduce只是一个应用程序框架, 该设计也可以允许使用其他框架来构建和部署分布式应用程序。例如,Hadoop 0.23附带了一个分布式Shell应用程序,允许在YARN集群上的多个节点上运行一个shell脚本。

2. MapReduce 2.0 设计

下图显示了一个YARN集群。只有一个资源管理器,它有两个主要的服务:

  • 可插拔的调度器,用于管理和实施集群中的资源调度策略。请注意,在编写本博文时,Hadoop 0.23中支持两个调度器,默认的FIFO调度器和Capacity调度器; Fair调度器尚未支持(译者注:博文2012编写,现在已经支持)。
  • Applications Manager(AsM),负责管理集群中运行的Application Masters,例如,负责启动Application Masters,以及在发生故障时在不同节点上监视和重新启动Application Masters

上图还显示了在集群上的每个节点上都运行一个NM服务。该图还显示了有两个AM(AM1AM2)。对于给定的任意YARN集群中,有多少个应用程序(作业),就运行多少个Application Masters。每个AM管理应用程序的各个任务(启动,监视,以及在发生故障时重新启动任务)。该图还显示了AM1管理三个任务(容器1.1,1.2和1.3),AM2管理四个任务(容器2.1,2.2,2.3和2.4)。每个任务运行在每个节点的Container中。在AM联系对应的NM来启动应用程序的各个任务之前,从RM的调度器中获取这些容器。这些容器可以大致与以前的Hadoop版本中的Map/Reduce插槽进行比较。然而,从集群利用角度来看,Hadoop-0.23中的资源分配模型更加优化。

3. MapReduce 2.0 资源分配模型

在较早的Hadoop版本中,集群中的每个节点都静态分配运行预定义数量的Map插槽和预定义数量的Reduce插槽的资源容量。插槽无法在MapReduce之间共享。这种静态分配槽的方式并不是最佳选择,因为在MR作业生命周期中槽的需求是不同的(典型地,当作业开始时对Map槽有需求,相反,对Reduce槽的需求是在最后)。实际上,在一个真正的集群中,作业是随机提交的,每个集群都有自己的Map/Reduce槽需求,对集群充分利用不是不可能,是非常难。

Hadoop 0.23中的资源分配模型通过提供更灵活的资源建模来解决此类缺陷。以容器的形式请求资源,其中每个容器具有许多非静态属性。在写本博客时(2012年),唯一支持的属性是内存(RAM)。然而,该模型是通用的,并且有意在将来的版本中添加更多的属性(例如CPU和网络带宽)。在这个新的资源管理模型中,每个属性只定义了最小值和最大值,并且AM可以请求具有这些最小值的倍数的属性值的容器。

4. MapReduce 2.0 主要组件

我们将详细介绍MapReduce架构的主要组件,以了解这些组件的功能以及它们如何交互的。

2.1 Client – Resource Manager

下展示了在YARN集群上运行应用程序的初始步骤。通常,客户端与RM(特别是与RMApplications Manager组件)通信来开启此步骤。图中标记为(1)的第一步是让客户端告诉Applications Manager我们提交应用程序的意愿,这是通过创建应用程序请求(New Application Request)完成的。标记为(2)的RM响应通常包含一个新生成的唯一应用程序ID,以及有关客户端在请求资源以运行应用程序AM时所需要的集群资源容量的信息。

使用从RM接收到的响应信息,客户端可以构建并提交标记为(3)的应用程序提交上下文(Application Submission Context),除了RM所需要来启动AM的信息之外,通常还包含诸如调度器队列,优先级和用户信息之类的信息。这些信息包含在容器启动上下文(Container Launch Context)中,还包含应用程序的jar,作业文件,安全令牌和任何需要的资源等。

在提交申请之后,客户端可以向RM查询应用程序报告,并接收返回的报告,并且如果需要,客户端也可以要求RM终止该应用程序。这三个步骤在下图中展示:

2.2 Resource Manager – Application Master

RM从客户端接收到应用程序提交上下文时,会找到一个满足运行AM资源需求的可用容器,并与该容器的NM联系,以便在该节点上启动AM进程。下图描述了AMRM(特别是与RM的调度器)之间的通信步骤。图中标记为(1)的第一步是AM将自己注册到RM中。这一步由一个握手过程组成,同时还传递了AM将要监听的RPC端口,监视应用程序状态和进度的跟踪URL等信息。

标记为(2)的RM注册响应为AM传递一些基本信息,比如集群的最小和最大资源容量。AM将使用这些信息为各个任务的任何资源请求来计算和请求资源。标记为(3)的从AMRM的资源分配请求主要包含所请求的容器列表,并且还可能包含该AM所释放的容器列表。心跳和进度信息也可以通过资源分配请求进行传达,如箭头(4)所示。

RM的调度器接收到资源分配请求时,它基于调度策略计算满足该请求的容器列表,并且返回分配响应,标记为(5),其中包含分配的资源列表。使用资源列表,AM开始联系相关联的NM(很快就会看到),最后,如箭头(6)所示,当作业完成时,AMRM发送应用完成的消息并退出。

2.3 Application Master – Container Manager

下图描述了AMNode Manager之间的通信。AM为每个容器请求NM来启动它,如图中箭头(1)所示。在容器运行时,AM可以分别请求并接收容器状态报告,如步骤(2)和(3)所示。

基于以上讨论,编写YARN应用程序的开发人员应主要关注以下接口:

  • ClientRMProtocolClient RM(图3)。这是客户端与RM进行通信以启动新的应用程序(即AM),检查应用程序状态或终止应用程序的协议。
  • AMRMProtocolAM RM(图4)。这是AM用来向RM注册或取消注册,以及从RM调度器请求资源来运行任务的协议。
  • ContainerManagerAM NM(图5)。这是AM用来与NM进行通信以启动或停止容器以及获取容器状态更新的协议。

原文:http://blog.cloudera.com/blog/2012/02/mapreduce-2-0-in-hadoop-0-23/

您的支持将是我继续写作的动力!