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

  1）扩展性问题。可以随着数据量进行水平扩展，而元数据服务器不能扩展。

2）随着文件数目的增长，元数据服务器的压力变大。据统计，2.5亿个文件在NameNode中Namespace占据的大概64GB的内存空间。

3）文件操作的吞吐率受到单个元数据服务器的限制。目前，Hadoop0.20.*版本可以达到120kreadops/sec，6000writeops/sec.

4)隔离性的问题。0.20.*版本中，一个NameNode对应着唯一的Namespace,所有文件、应用、用户公用同一的名字空间。存在访问权限控制的问题，不利于在HDFS在公有云环境下的应用。

（ps：图1为0.20.*版本下HDFS架构图）

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

1）集群资源利用率较低。整个集群资源按照固定Slot为单位进行资源分配，没有考虑MapTask、ReduceTask任务的特点和逻辑关系进行不同的配置。

2)仅支持MapReduce编程模型。在Hadoop框架内实现PageRank、LogicalRegression等迭代算法，需要将算法映射成MapReduce的组合、或者使用Pig、Casscading、Hive等应用层的逻辑描述，不能从模型本身去表达，算法性能受到了影响(10xslower)。

（ps：图2为0.20.*版本下MapReduce执行架构图）

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

2、Hadoop核心理念

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

3、Hadoop-0.23的NewFeatures

• HDFSFederation

1)Namespace与blockManagement解耦。

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

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

• MapReduceNextGenakaYARN

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、IterativeMR等编程模型，实现对于多种应用场景的支持。

2）运行时环境的扩展性与单点故障问题。

运行时环境的扩展性是支持更多的工作节点，同时运行更多的任务。Hadoop之前版本由于是JobTracker不仅管理集群内资源分配，还要管理任务的调度，造成整个系统扩展性不强，并且JobTracker成为作为脆弱的一环。由于在JobTracker需要繁忙的信息交互，并且所有信息仅保留一份，宕机之后运行作业的信息丢失，这已经成为制约Hadoop继续扩大规模的重要影响因素。

Hadoop0.23为了解决扩展性的问题，为每一个job启动一个Applicationlife-cyclemanagement，负责job内任务的初始化、调度和监控，分担之前所有Job集中管理的JobTracker的负荷，ResourceManager仅仅做集群资源的管理。

Hadoop0.23为了解决单点故障问题。一是如上所说把之前作业内部任务的管理分离出去，减轻中心节点的负载。二是使用ZooKeeper集群缓存ResourceManager的状态信息，保证关键数据的可靠性，当重启之后，保证重要数据不丢失。

4、参考资料