hadoop的版本演变以及其他

http://blog.csdn.net/feitongxunke​

以下资料均收集自网上，链接在最下方。

1.先贴个Hadoop官方说明

先贴出Apache Hadoop官方版本说明（至今2014-07-07）：

1.2.X - current stable version, 1.2 release

2.4.X - current stable 2.x version

0.23.X - similar to 2.X.X but missing NN HA.

但是网上一搜一大把的0.20.X和0.23.X又有什么区别呢，继续贴一个之前的官方版本说明：

1.0.X - current stable version, 1.0 release

1.1.X - current beta version, 1.1 release

2.X.X - current alpha version

0.23.X - simmilar to 2.X.X but missing NN HA.

0.22.X - does not include security

0.20.203.X - old legacy stable version

0.20.X - old legacy version

2.两条支线

这里的0.20.x和0.23.x分别演变成了1.x和2.x。

意思就是说这里有两条线0.20和0.23，为什么会有两条线呢？原因是第一代Hadoop有三个版本，分别是0.20.x，0.21.x和0.22.x，后面两个是包含了NameNode HA等重大特性。第二代Hadoop包含两个版本，分别是0.23.x和2.x，完全不同于Hadoop1.0，这里是一套全新的框架，包含了HDFS Federation和YARN两个系统。而且相比于0.23.x，2.x增加了NaneNode HA和Wire-compatibility两个重大特性。

看到这里一下就明白了，在配置Hadoop1.2.1和Hadoop2.4.0的时候，就会发现一个问题，2.4.0有一个yarn-site.xml这个文件，而且mapper.xml里面包含：

  
    
    
    
    

     
     
     
     
mapreduce.framework.name
     
     
     
     
yarn
    
    
    
    

从这里也可以看出来。那YARN是个什么东西呢？

3. 谈谈YARN

谈YARN之前必须先说点关于原Hadoop MapReduce框架的问题。框架图如下图所示，可以从图中看出几点：

1. 用户程序JobClient提交了一个job，job会把信息发给JobTracker中，JobTracker负责集群中的机器定时通信（heartbeat），需要管理哪些程序应该在那些机器上跑，需要管理所有job失败、重启等操作。
2. TaskTracker是每个集群中每个机器都有的一部分，负责监视自己机器上资源情况。同时监视当前机器的tasks运行状况。TaskTracker需要把这些信息通过heartbeat发送给JobTracker，JobTracker会搜集这些信息以给新提交的job分配运行在哪些机器上。

那么这个时候问题也暴露出来了，有以下几个问题，这里只写了一部分：

1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。
2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当map-reduce job非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。
3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。

此处省略（很多不足啊 参考网站见下方。。。。。）

为了满足分布式系统的变化趋势和hadoop框架长远发展，这个时候需要从根本上解决乣框架的性能能瓶颈。从0.23.0版本开始，Hadoop的MapReduce框架完全重构，发生根本变化。新框架命名为MapReduceV2或者叫Yarn，框架结构图如下：

这个时候我们的YARN(Yet Another Resource Negotiator)就出来了！！！

YARN最主要的就是将在Hadoop1.0里面的JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中前者负责所有应用程序的资源分配，而后者仅负责管理一个应用程序。

这个时候YARN最主要的就是ResourceManager, ApplicationMaster 与 NodeManager 三个部分。

接下里详细解释这三个部分，首先 ResourceManager 是一个中心的服务，它做的事情是调度、启动每一个 Job 所属的 ApplicationMaster、另外监控 ApplicationMaster 的存在情况。而且旧框架中Job 里面所在的 task 的监控、重启等等内容也都不见了。这也是 AppMst 存在的原因。ResourceManager 负责作业与资源的调度。接收 JobSubmitter 提交的作业，按照作业的上下文 (Context) 信息，以及从 NodeManager 收集来的状态信息，启动调度过程，分配一个 Container 作为 App Mstr。NodeManager 功能比较专一，就是负责 Container 状态的维护，并向 RM 保持心跳。ApplicationMaster 负责一个 Job 生命周期内的所有工作，类似老的框架中 JobTracker。但注意每一个 Job（不是每一种）都有一个 ApplicationMaster，它可以运行在 ResourceManager 以外的机器上。

Yarn 框架相对于老的 MapReduce 框架什么优势呢？我们可以看到：

1. 这个设计大大减小了 JobTracker（也就是现在的 ResourceManager）的资源消耗，并且让监测每一个 Job 子任务 (tasks) 状态的程序分布式化了，更安全、更优美。
2. 在新的 Yarn 中，ApplicationMaster 是一个可变更的部分，用户可以对不同的编程模型写自己的 AppMst，让更多类型的编程模型能够跑在 Hadoop 集群中，可以参考 hadoop Yarn 官方配置模板中的 mapred-site.xml 配置。
3. 对于资源的表示以内存为单位 ( 在目前版本的 Yarn 中，没有考虑 cpu 的占用 )，比之前以剩余 slot 数目更合理。
4. 老的框架中，JobTracker 一个很大的负担就是监控 job 下的 tasks 的运行状况，现在，这个部分就扔给 ApplicationMaster 做了，而 ResourceManager 中有一个模块叫做 ApplicationsMasters( 注意不是 ApplicationMaster)，它是监测 ApplicationMaster 的运行状况，如果出问题，会将其在其他机器上重启。
5. Container 是 Yarn 为了将来作资源隔离而提出的一个框架。这一点应该借鉴了 Mesos 的工作，目前是一个框架，仅仅提供 java 虚拟机内存的隔离 ,hadoop 团队的设计思路应该后续能支持更多的资源调度和控制 , 既然资源表示成内存量，那就没有了之前的 map slot/reduce slot 分开造成集群资源闲置的尴尬情况。

4. 其他计算框架

上面写了这么多，有些我也没看懂，不过不打紧，很多东西有个印象就行，很多东西功夫到了自然就有了，而且这些也是吹牛逼的素材嘛。

接下来列举些现在很火热得其他计算框架，比如Spark，Storm等。最近微博还有国内互联网资讯一天到晚都在扯大数据，现在公司不和大数据扯点关系好像就不能上市一样，都是扯蛋的东西。前段时间谷歌I/O大会说老早不用MapReduce很多年了，现在都用Cloud Dataflow，那个能用来处理整个数据流。这个时候会觉得学MapReduce已经落后了，其实有句话说得好，以很多人的努力程度来说，还没够得上拼天赋的资格。

1. MapReduce: 这个框架人人皆知，它是一种离线计算框架，将一个算法抽象成Map和Reduce两个阶段进行处理，非常适合数据密集型计算。
2. Spark: 我们知道，MapReduce计算框架不适合（不是不能做，是不适合，效率太低）迭代计算（常见于machine learning领域，比如PageRank）和交互式计算（data mining领域，比如SQL查询），MapReduce是一种磁盘计算框架，而Spark则是一种内存计算框架，它将数据尽可能放到内存中以提高迭代应用和交互式应用的计算效率。官方首页：http://spark-project.org/
3. Storm: MapReduce也不适合进行流式计算、实时分析，比如广告点击计算等，而Storm则更擅长这种计算、它在实时性要远远好于MapReduce计算框架。官方首页：http://storm-project.net/
4. S4: Yahoo开发的流式计算框架，与Storm较为类似。官方首页：http://incubator.apache.org/s4/
5. Open MPI: 非常经典的消息处理框架，非常适合高性能计算，现在仍被广泛使用。
6. HAMA: 基于BSP（bulk-synchronous parallel model）模型的分布式计算框架，与Google的Pregel类似，可用于大规模科学计算，如矩阵，图算法，网络算法等，官方首页：http://hama.apache.org/。
7. Cloudera Impala/ Apache Drill: 基于Hadoop的更快的SQL查询引擎（比Hive快得多），Google Dremel的模仿者。Cloudera Impala官方首页：https://github.com/cloudera/impala，Apache Drill官方首页：http://incubator.apache.org/drill/
8. Giraph：图算法处理框架，采用BSP模型，可用于计算pagerank，shared connections, personalization-based popularity等迭代类算法。官方首页：http://giraph.apache.org/

参考网站：

http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/

http://dongxicheng.org/mapreduce-nextgen/how-to-select-hadoop-versions/

http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-terms-explained/

http://dongxicheng.org/mapreduce-nextgen/understand-hadoop-yarn-from-os-view/

http://dongxicheng.org/mapreduce-nextgen/hadoop-yarn-problems-vs-solutions/