Hadoop 之 MapReduce 框架演变详解

经典版的MapReduce

所谓的经典版本的MapReduce框架，也是Hadoop初版成熟的商用框架，简单易用是它的特色，来看一幅图架构图：

上面的这幅图咱们暂且能够称谓Hadoop的V1.0版本，思路很清晰，各个Client提交Job给一个统一的Job Tracker，而后Job Tracker将Job拆分红N个Task,而后进行分发到各个节点（Node）进行并行协同运行，而后再将各自的运行结果反馈至Job Tracker,进而输出结果。

可是，这种框架有它自身的限制性和局限，咱们来简单的分析几点：

一、单点故障，首先，单点故障也是最致命的一点，从上图中能够看到全部的Job的完成都得益于JobTracker的调度和分配，一旦此节点宕机就意味着整个平台的瘫痪，固然，在实际中大部分经过一个JobTracker slaver来解决。可是，在一个以分布式运算为特性的框架中，将这种核心的计算集中与一台机器不是一个最优的方案。

二、可扩展性，一样，在上面的架构图中能够看到，Job Tracker不但承载着Client所提供的Job和分发和调度，还须要管理全部的Job的失败、重启，监视每一个Node的资源利用状况，实现原理无非就是Heartbeat(心跳检测)，随着Node的数量的增长，Job Tracker的任务就会变得越来愈大，在疲于应付各个子节点运行检测的同时，还要进行新的Job的分发，因此这种框架官方给出了限制节点数（<4000 节点）。

三、资料浪费，在传统的架构中，每个Job的分配，是经过Node资源的数量进行分配的方式，显然这种分配方式不能动态的实现负载均衡，好比，两个大的内存消耗的task调度到了一个Node上，这也就意味着状态机器压力很大，而相应的某些节点就比较轻松，显然在分布式计算中这是一种很大的资源浪费。

四、版本耦合，其实这一点也是影响一个平台作大的致命缺陷，以上的架构中，MapReduce框架有着任何的或者不重要的变动（好比BUG修复、性能提高或某些特性），都会强制进行系统级别的升级更新。并且，无论用户是否赞成，都得强制让分布式系统的每个用户端进行更新。

 

以上四点，是V1.0框架之上所带来的局限性，总结的来看，问题主要是集中在中间节的主线程Job tracker上面，因此解决这个线程的问题，基本也就解决了上面所提到的性能浪费和扩展性等诸多问题。

下面咱们再详细的分析下Job Track在MapReduce中的详细职责，解决扩张性的问题无非就是责任解耦，咱们来看一下：

一、管理集群中的计算资源，涉及到维护活动节点列表，可用和占用的Map和Reduce Slots列表。以及依据所选的调度策略可用的Slots分配给合适的做用和任务

二、协调集群中运行的任务，这涉及到指导Task Tracker启动Map和Reduce任务，监视任务的运行状态，从新启动执行失败任务，推测性能运行缓慢的任务，计算做业计数器值的总和，等等。

看看，JobTrack是否是很累.....这样的安排放在一个进程中会致使重大的伸缩性问题，尤为是在较大的集群上面，JobTracker必须不断的跟踪数千个TaskTracker、数百个做业，以及数以万计的Map和Reduce任务，下面来个图看看：

上图中显示了一台比较忙的Job Tracker在忙碌的分配着任务.....

因此，分析到此，彷佛解决问题的方式已经呼之欲出了：减小单个JobTracker的职责！

既然减小JobTracker的职责，也就意味着须要将不属于他的职责分配给别人去干，通过上面的简述，咱们基本上能够将JobTracker的职责分为两大部分：集群资源管理和任务协调。

这两大任务之间，显然集群管理的任务要更重要，它意味着整个平台的性能的健壮和平台的扩展性，而相比较，任务协调之类的事情就能够分配到某一个下属的Node来干，而且因为每个Client所提到的Job分配过程和执行过程而言，分配过程显得短暂而且灵活。

通俗一点的讲：就是将上面架构中的JobTracker责任进行剥离，让它就负责整个平台的资源管理就能够了，至于任务的分配和协调就交给属下（Node）来干就行了。就比如一个公司来个活，大Boss只负责整个公司的资源管理，而这个活就扔给相应的部分就能够了。

通过上面的分析，好像基本下一个版本的架构优化方式也基本明确，咱们来接着分析Hadoop的新一版的架构。

 

新一代的架构设计YARN

来看一下官方的定义：

Apache Hadoop YARN （Yet Another Resource Negotiator，另外一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

通过第一部分的分析，咱们基本已经确认了将之前的JobTracker这个主线程的责任更改成整个集群的资源管理和分配。从这一点讲这里若是这个线程的命名仍是JobTracker显然就不合适了。

因此在新通常的架构图中他的名字变成了ResourceManager(资源管理)，而后这个名字更适合它的职责。

咱们先来一幅图看看

哈，长得基本和上一代的架构图同样，只是责任有了明显的分离，咱们来分析一下，首先来肯定一下图中的名词：

一、ResourceManager(RM)全局群集资源管理器

二、ApplicationMaster(AM)专用的JobTracker,途中能够看出，目前已经将JobTracker的职责分离到了Node中了。

三、NodeManage（NM）管理各个子节点，代替之前的TaskTracker,不过功能基本相似，只不过添加了一个每一个节点的的自管理功能，也是对RM的责任分担。

四、Containers,用Application来提到之前的MapReduce做业，而承载Application的容器就为Container,目的是为了更多应用能运行在Hadoop平台下，为了之后的扩充。

咱们来简述一下，整个框架的运行流程。

在YARN构架中，一个全局的ResourceManager主要是以一个后台进程的形式运行。它通常分配在一个独有的机器上，在各类竞争的应用程序之间独裁可用的集群资源。ResourceManageer会追踪集群中有多少可用的活动节点和资源，协调用户提交的那些应用程序在什么时候获取这些资源。

ResourceManager是惟一拥有此信息的进程，因此它可经过某种共享的，安全的，多租户的方式制定分配（或者调度）决策（例如，依据应用程序的优先级，队列容量，ACLs,数据位置等）

在用户提交一个应用程序时，一个称为ApplicationMaster的轻量级进程实例会启动协调应用程序内的全部任务的执行。包括监视任务，从新启动失败的任务，推测的运行缓慢的任务，以及计算应用程序计数值的总和。这些职责之前就是JobTracker.如今已经独立出来，而且运行在NodeManager控制的资源容器中运行。

NodeManager是TaskTracker的一种更加普通和高效的版本，NodeManager拥有许多动态建立的资源容器，容器的大小取决于所包含的资源量，好比：内存、CPU、磁盘和网络IO.可是目前仅支持内存和CPU(YARN-3).其实这里平台提供的一个接口，方便后续的扩展，将来可以使用cgroups来控制磁盘和网络IO.

其实，简单点讲，NodeManager是一个高度自治的内在节点，包括节点内的JobTracker.

咱们再来看另一幅图，来详细的看一下，YARN内新的Job内在流程在各个节点（Node）中的流转：

从这幅图中能够看到，和以前的初版的架构图相比，是多了后面节点之间的交互，由于，在新的结构图中咱们将JobTracker的职责下放到NodeManager中的ApplicationMaster中了，也就是会在ApplicationMaster中进行传统的Map-Redurce的分发，因此会形成各个不一样的Noder之间发生交互。

固然，这全部的过程都会他们的老大ResourceManager进行调度和管理。

以上的架构，在Hadoop版本中称之为MRv2.

咱们来总结一下，这个架构所解决的问题：

一、更高的集群利用率，一个框架未使用的资源可由另外一个框架进行使用，充分的避免资源浪费

二、很高的扩展性，采用了这种责任下方的架构思路，已经解决了初版4000node的限制，到目前能够充分的扩展资源。

三、在新的Yarn中，经过加入ApplicationMaster是一个可变动的部分，用户能够针对不一样的编程模型编写本身的AppMst,让更多的编程模型运行在Hadoop集群中。

四、在上一版框架中，JobTracker一个很大的负担就是监控Job的tasks运行状况，如今，这个部分下放到了ApplicationMaster中。

除了上面几点以外，咱们特别来分析如下，在新版框架中的ResouceManager的功能亮点。

上个图看看：

当一个Client提交应用程序的时候，首先进去的就是ResourceManager，它维护着集群上运行的应用程序列表，以及每一个活动的NodeManager上的可用资源列表。ResourceManager首先要肯定就是那个应用程序能够运行此Job,会存放到相应的Container中去，固然这里会分配一部分的集群资源，这一部分资源的选择会受到许多的限制，好比：队列容量，ACL和公平性。下一步就是另一个可插拔的组件Scheduler来下发任务（这里不是分发！），Scheduler近执行调度，不会对应用程序内的执行过程有任何监视，Scheduler就比如秘书同样，将大Boss(RM)分配的任务传递到相应的部门。

而后，就是部门的领导（ApplicationMaster）来分配任务给员工（DataNode）了，而这个分发的过程就是Map-Redure，因此在这个过程当中，ApplicationMaster负责此应用程序的整个周期，固然在运行过程当中，它能够跟老大（RM）进行一些相应的资源需求，好比：

一、必定量的硬件资源，好比内存量和CPU份额。

二、一个首选的位置，好比某台Node，一般须要制定主机名、机架名等。

三、Task分配后的优先级。

而后，找到相应的资源以后，就开始甩开膀子进行任务的完成，而这些跑批则发生在（Node）中,可是Node中也有它本身的小队长（NodeManager）,它负责监视本身node种的资源使用状况，好比，本身的任务比当初分配的少，提早完成了，它会结束该容器，释放资源。

而在上面的过程当中，ApplicationMaster会不遗余力协调容器，自动所须要的任务来完成它的应用程序，他会监视应用程序的进度，从新启动失败的任务，以及向Client提交应用程序的报告进度。应用程序完成后，ApplicationMaster会关闭本身并释放本身的容器。

固然，这个过程之中，若是ApplicationMaster本身挂掉了，这时候ResouceManager会从新从新找一个领导（新的容器中启动它），直至整个程序完成。

结束语

Hadoop是一个很是牛掰的分布式架构平台，它的优越性我想不须要我跟你们分享，不少成功的案例都已经在暗示着咱们，将来所谓的大数据，所谓的互联网+，所谓的云....都会找到它的立脚点。

 

参考资源

百度百科：yarn

Apache Hadoop 0.23 中的 MRv2，这是对一个 JARN 集群的重要技术细节的不错介绍。

Hadoop官网 Apache Hadoop 项目站点。