【转】Hadoop0.23.0初探1---前因后果

最近Hadoop社区最火热的事情莫过于Hortonworks公布了Hadoop最新版本(0.23.0)，它标志着Hadoop新时代的到来。本文作 为系列文章的第一篇，将结合Hadoop-0.20.*的特点，以及Hadoop核心理念，分析Hadoop新版本的特征。
1、Hadoop 0.20.*的局限性

• HDFS单NameNode的不足

 

   1）扩展性问题。可以随着数据量进行水平扩展，而元数据服务器不能扩展。
    2）随着文件数目的增长，元数据服务器的压力变大。据统计，2.5亿个文件在NameNode中Namespace占据  的大概64GB的内存空间。
    3）文件操作的吞吐率受到单个元数据服务器的限制。目前，Hadoop 0.20.*版本可以达到120k readops/sec，6000 writeops/sec.
    4)隔离性的问题。0.20.*版本中，一个NameNode对应着唯一的Namespace,所有文件、应用、用户公用同一的名字空间。存在访问权限控制的问题，不利于在HDFS在公有云环境下的应用。
（ps：图1为0.20.*版本下HDFS架构图）

图1 Hadoop0.20.* HDFS architecture

• MapReduce编程模型与运行时环境紧耦合

    1）集群资源利用率较低。整个集群资源按照固定Slot为单位进行资源分配，没有考虑MapTask、ReduceTask任务的特点和逻辑关系进行不同的配置。
    2)仅支持MapReduce编程模型。在Hadoop框架内实现PageRank、Logical Regression等迭代算法，需要将算法映射成MapReduce的组合、或者使用Pig、Casscading、Hive等应用层的逻辑描述，不能从模型本身去表达，算法性能受到了影响(10x slower)。
       （ps：图2为0.20.*版本下MapReduce执行架构图）

图2 Hadoop MapReduce执行流程图

• 单个JobTracker的单点故障和扩展性

    1）JobTracker的负载较重。JobTracker负责作业和任务的初始化、以及提供TaskTracker的RPC Server、任务的调度等任务。因此，JobTracker一旦故障，所有执行的任务的状况丢失。

    2）扩展性问题。JobTracker目前最多支持4000nodes、40000个concurrent tasks。


2、Hadoop核心理念

• HDFS分为NameNode，DataNode。NameNode维护了名字空间(Namespace),fileName与Block映射关系，以及DataNode交互信息。DataNode是存储Block的位置，为客户端提供读取block内容的接口。
• HDFS DataNode随着数据量的大小可以实现动态扩展，配合start-balance.sh可以自由地实现节点上线和下线。
• Hadoop执行框架要遵循“计算向数据迁移 ”的要求。这也意味着节点上需要同时部署DataNode和任务执行节点。
• 工作节点通过RPC与中心节点交互。（NameNode与DataNode，0.20.*版本的JobTracker与TaskTracker，以及0.23的Resource Manager 与Node Manager），工作节点与中心节点的链接变成一种动态的绑定的方式进行，可以灵活支持工作节点的加入和退出。

3、Hadoop-0.23的New Features

• HDFS Federation

    1) Namespace与block Management解耦。
    Hadoop0.20.*仅有一个NameNode，整个系统使用统一的NameSpace，系统所有对于文件的操作都要经过唯 一的Namenode来进行，造成了NameNode负载过重。图3为Namespace和Block Storage的关系图。

     
图3 Namespace和Block Storage

         Hadoop0.23支持多个Namespace，每个NameNode都对应一个NameSpace。配置人员可以根据应用的特点，选择合适的 Namespace划分的方式。所有的DataNode被全部的NameNode共享，也就是每一个NameNode中Namespace下的文件可以分 散在任意的DataNode上。系统提供了一个公共的Block pools隔离了Namespace与Block交互。图4为HDFS Federation Architecture

           图4 HDFS Federation Architecture

• MapReduce NextGen aka YARN
  

    1）编程模型与运行时框架解耦。 
    Hadoop0.20.*运行时框架分为JobTracker和TaskTracker，JobTracker负责MapTask和ReduceTask 的初始化、调度和资源分配。TaskTracker负责MapTask和ReduceTask的执行。运行环境已经烙上了MapReduce编程模型的 Map->sort[->combine]->partition->shuffle->merge->reduce 过程...这个运行时环境都在围绕这个过程准备，然而这种方式是hadoop在分布式计算领域扩大发展的最大瓶颈，因为如果要在Hadoop执行的任务， 就需要根据不同的类型计算映射成一个或者多个MapReduce过程，而这些过程在处理迭代、更新频繁的应用时就显得过于繁琐。
       Hadoop0.23最大的亮点，个人认为将JobTracker的MapReduce编程模型从运行时环境中剥离，MapReduce变成了Hadoop的编程库。从而，在运行时环境之上灵活开发MapReduce、DAG、Iterative MR等编程模型，实现对于多种应用场景的支持。

图5 Hadoop YARN Architecture

     2）运行时环境的扩展性与单点故障问题。
     运行时环境的扩展性是支持更多的工作节点，同时运行更多的任务。Hadoop之前版本由于是JobTracker不仅管理集群内资源分配，还要管理任务的 调度，造成整个系统扩展性不强，并且JobTracker成为作为脆弱的一环。由于在JobTracker需要繁忙的信息交互，并且所有信息仅保留一份， 宕机之后运行作业的信息丢失，这已经成为制约Hadoop继续扩大规模的重要影响因素。
     Hadoop0.23为了解决扩展性的问题，为每一个job启动一个Application life-cycle management，负责job内任务的初始化、调度和监控，分担之前所有Job集中管理的JobTracker的负荷，Resource Manager仅仅做集群资源的管理。
     Hadoop0.23为了解决单点故障问题。一是如上所说把之前作业内部任务的管理分离出去，减轻中心节点的负载。二是使用ZooKeeper集群缓存Resource Manager的状态信息，保证关键数据的可靠性，当重启之后，保证重要数据不丢失。

4、参考资料

[1]Hadoop0.23.0 http://www.slideshare.net/cloudera/hadoop-world-2011-apache-hadoop-023-arun-murthy-horton-works

[2] HDFS federal http://www.slideshare.net/hortonworks/hs-2011-submission87hwfinal

[3} Hadoop Next MapReduce Generation  http://www.slideshare.net/hortonworks/nextgen-apache-hadoop-mapreduce

ps：本篇文章属于原创，其中有不合适的地方，还请大家批评指正。如果要联系本文作者，请发邮件：
[e-mail]
[e-mail]
如需要转载，请附上上面的邮箱地址，谢谢，我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢！