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/，完美的商业与技术结合的产品。