MapReduce2框架的原理解析

这篇文章主要围绕MapReduce2框架原理介绍的，文中有详细的代码示例，对学习有一定的帮助，需要的朋友可以借鉴参考

1 MapReduce2产生的原因

1.1 在hadoop1.X的时代，MapReduce做了很多的事情，其核心是JobTracker。

1.2 初探MapReduce1架构

• 首先客户端要编写好mapreduce程序，然后提交作业也就是job，job的信息会发送到JobTracker上，并为该job分配一个ID值，接下来做检查操作，确认输入目录是否存在，如果不存在，则会抛错，如果存在继续检查输出目录是否存在，如果存在则会抛错，否则继续运行；当检查工作都做好了JobTracker就会配置Job需要的资源了。
• JobTracker: 主要负责资源监控管理和作业调度
  • （a）监控所有TaskTracker 与job的健康状况,一旦发现失败,就将相应的任务转移到其他节点；
  • （b）同时JobTracker会跟踪任务的执行进度、资源使用量等信息,并将这些信息告诉任务调度器,而调度器会在资源出现空闲时,选择合适的任务使用这些资源。
• TaskTracker：是JobTracker与Task之前的桥梁
  • （a）从JobTracker接收并执行各种命令:运行任务、提交任务、Kill任务、重新初始化任务;
  • （b）周期性地通过心跳机制,将节点健康情况和资源使用情况、各个任务的进度和状态等汇报给JobTracker。
• Task Scheduler: 任务调度器(默认FIFO,先按照作业的优先级高低,再按照到达时间的先后选择被执行的作业)

1.3MapReduce1缺陷

• Hadoop1.x的MapReduce框架的主要局限：
  • （1）JobTracker 是 Map-reduce 的集中处理点，存在单点故障，可靠性差；
  • （2）JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker 失效的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限，扩展性能差。
  • （3）可预测的延迟：这是用户非常关心的。小作业应该尽可能快得被调度，而当前基于TaskTracker->JobTracker ping（heartbeat）的通信方式代价和延迟过大，比较好的方式是JobTracker->TaskTracker ping, 这样JobTracker可以主动扫描有作业运行的TaskTracker。

面对上诉一系列问题mr1已经不能满足我们的需求，因此在hadoop2.x中MapReduce2应运而生，下面我们一起学习MapReduce2。

2 MapReduce2架构设计

2.1 官网初析MapReduce2

• 从官网上我们可以看到，在Apache Hadoop 2.x中，我们将资源管理和作业调度功能分解为Apache Hadoop YARN来进行管理，它一种通用的分布式应用程序管理框架，而Apache Hadoop MapReduce（又名MRv2）是一个纯粹的分布式计算框架。官网地址
• 之前的MapReduce运行时（又名MRv1）已经被重用，没有进行较大的变化。因此，MRv2能够确保与MRv1应用的令人满意的兼容性。但是，由于一些改进和代码重构，一些API已经向后兼容。
• 可以看出不同的是资源管理和作业管理系统，MRv1中资源管理和作业管理均是由JobTracker实现的，集两个功能于一身，而在MRv2中，将这两部分分开了。

MRv2最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度/监控分成两个独立的进程。在该解决方案中包含两个组件：全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。这里的“应用”指一个单独的MapReduce作业。RM和与NodeManager（NM，每个节点一个）共同组成整个数据计算框架。RM是系统中将资源分配给各个应用的最终决策者。AM实际上是一个具体的框架库，它的任务是【与RM协商获取应用所需资源】和【与NM合作，以完成执行和监控task的任务】。

2.2 MapReduce2组成部分

• ResourceManager（RM）包含两个主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager)
  • （1）调度器（Scheduler）：根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用。这里的调度器是一个“纯调度器”，因为它不再负责监控或者跟踪应用的执行状态等，此外，他也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。调度器仅根据各个应用的资源需求进行调度，这是通过抽象概念“资源容器”完成的，资源容器（Resource Container）将内存，CPU，磁盘，网络等资源封装在一起，从而限定每个任务使用的资源量。总而言之，定时调度器负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序。
  • （2）应用管理器（ApplicationsManager，ASM）：ASM主要负责接收作业，协商获取第一个容器用于执行AM和提供重启失败AM container的服务。
• NodeManager：NM是每个节点上的框架代理，主要负责启动应用所需的容器，监控资源（内存，CPU，磁盘，网络等）的使用情况并将之汇报给调度器（Scheduler）。
• ApplicationMaster：每个应用程序的ApplicationMaster负责从Scheduler申请资源，以及跟踪这些资源的使用情况以及任务进度的监控。
• Container：是YARN中资源的抽象，它将内存、CPU、磁盘、网络等资源封装在一起。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。

3 MapReduce2提交应用程序的过程分析

• 在作业的提交阶段，client向RM提交一个job，这时RM会进行检查，如果没有问题，会返回作业文件提交的路径和jod id；client向HDFS上传文件，准备就绪后请求RM运行作业；
• 作业初始化阶段，用户将应用程序提交到ResourceManager后，RM为该作业分配第一个Container，并与对应的NM通信，在Container中启动作业的MRAppMaster；
• MRAppMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态；
• MRAppMaster采用轮询的方式式通过RPC协议向RM申请任务所需资源；
• 一旦MRAppMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务；
• NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务；
• 各个任务通过某个RPC协议向MRAppMaster汇报自己的状态和进度，以让MRAppMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。在应用程序运行过程中，用户可随时通过RPC向MRAppMaster查询应用程序的当前运行状态;
• 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己。

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

a. 第一个阶段是启动ApplicationMaster；
b. 第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，并监控它的整个运行过程，直到运行完

以上就是MapReduce2框架的原理解析的详细内容，更多关于MapReduce2框架的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

• hadoop之MapReduce框架原理
• Hadoop之Mapreduce序列化
• golang并发工具MapReduce降低服务响应时间
• Golang编程并发工具库MapReduce使用实践
• java实现MapReduce对文件进行切分的示例代码
• 云计算实验：Java MapReduce编程
• MongoDB中MapReduce的使用方法详解