hadoop 2.0--YARN

从2012年8月开始Apache Hadoop YARN（YARN = Yet Another Resource Negotiator）成了Apache Hadoop的一项子工程。自此Apache Hadoop由下面四个子工程组成：

• Hadoop Comon：核心库，为其余部分服务
• Hadoop HDFS：分布式存储系统
• Hadoop MapReduce：MapReduce模型的开源实现
• Hadoop YARN：新一代Hadoop数据处理框架

      归纳来讲，Hadoop YARN的目的是使得Hadoop数据处理能力超越MapReduce。众所周知，Hadoop HDFS是Hadoop的数据存储层，Hadoop MapReduce是数据处理层。然而，MapReduce已经不能知足今天普遍的数据处理需求，如实时/准实时计算，图计算等。而Hadoop YARN提供了一个更加通用的资源管理和分布式应用框架。在这个框架上，用户能够根据本身需求，实现定制化的数据处理应用。而Hadoop MapReduce也是YARN上的一个应用。咱们将会看到MPI，图处理，在线服务等（例如Spark，Storm，HBase）都会和Hadoop MapReduce同样成为YARN上的应用。下面将分别介绍传统的Hadoop MapReduce以及新一代Hadoop YARN架构。
　　因而可知，hadoop2.0吸取目前工业界整个生态圈的现有成就，而且但愿可以支持更多的运算模型。可是生态系统老是有演化的过程，随着各类新物种的出现，总会有一天打破现有的生态平衡的。hadoop虽然提供了MPI但愿可以支持更多的计算类型，可是从目前看，HBase等都是自称一系的。

原 MapReduce 程序的流程及设计思路：

1. 首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他须要与集群中的机器定时通讯 (heartbeat), 须要管理哪些程序应该跑在哪些机器上，须要管理全部 job 失败、重启等操做。
2. TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他作的事情主要是监视本身所在机器的资源状况。
3. TaskTracker 同时监视当前机器的 tasks 运行情况。TaskTracker 须要把这些信息经过 heartbeat 发送给 JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。上图虚线箭头就是表示消息的发送 - 接收的过程。

能够看得出原来的 map-reduce 架构是简单明了的，在最初推出的几年，也获得了众多的成功案例，得到业界普遍的支持和确定，但随着分布式系统集群的规模和其工做负荷的增加，原框架的问题逐渐浮出水面，主要的问题集中以下：

1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2. JobTracker 完成了太多的任务，形成了过多的资源消耗，当 map-reduce job 很是多的时候，会形成很大的内存开销，潜在来讲，也增长了 JobTracker fail 的风险，这也是业界广泛总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目做为资源的表示过于简单，没有考虑到 cpu/ 内存的占用状况，若是两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。
4. 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 若是当系统中只有 map task 或者只有 reduce task 的时候，会形成资源的浪费，也就是前面提过的集群资源利用的问题。
5. 源代码层面分析的时候，会发现代码很是的难读，经常由于一个 class 作了太多的事情，代码量达 3000 多行，，形成 class 的任务不清晰，增长 bug 修复和版本维护的难度。
6. 从操做的角度来看，如今的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提高和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它无论用户的喜爱，强制让分布式集群系统的每个用户端同时更新。这些更新会让用户为了验证他们以前的应用程序是否是适用新的 Hadoop 版本而浪费大量时间。

　　整个hadoop2.0中，namenode上jobtracker的功能被拆分红resourceManager和ApplicationMaster以及客户端上面的NodeManager来统一负责。而AppMst又可有有多个，一个AppMst对应一种计算框架的类型，由AppMst来监控任务的运行状态，以及失败重启。NameNode是YARN每一个节点上面运行的agent，负责集群中每一个计算节点，看看hortonworks的官方描述：The NodeManager (NM) is YARN’s per-node agent, and takes care of the individual compute nodes in a Hadoop cluster. 

 

　　从上面介绍能够看得出，YARN最大的特性就是jobtracker被切分红resourceManager和appMst，而appMst这一层至关于对整个hadoop作了切分跟抽象，在文件系统之上增长了一个应用程序层，从而可以支持扩展。本质上看，appMst实现的逻辑其实用户的代码，不该当与系统代码的nodeManger和resourceManager混在一块儿，有了AppMst后继hadoop就能够支持各类流式运算和各类非MR的运算了。这个看起来貌似很简单的改变，可以极大减轻MASTER节点的压力和运算逻辑，目前业界hadoop系统有三千台的集群的，有五千台集群的，再高的没有谁详细的介绍过，听说YARN能支持的节点数目是远远超过hadoop1.0的。resourceManager相似于jt，而nodeManager相似于tt，而appMst则是新生事物。

　　YARN还支持webHDFS，经过restfull api访问和操做hdfs，这也算是遇上了时代的步伐，将大大方便跨语言对hadoop的调用。

　　悲催的是，没有看到关于MASTER单节点的解决方案，整个YARN对resourceManager的依赖像对jt和nn同样强烈，当resourceManager失效的时候，对整个系统来讲是灾难。这已经被工业界多次实践的一个缺陷了，不少实时切换的方案，可是未见到YARN官方的介绍。

 

　　最后YY一下，号称是HADOOP2.0的产品开发来自这家公司http://hortonworks.com/，完美的商业与技术结合的产品。