Hadoop0.23.0初探1—前因后果

十一月 30th, 2011 by klose | Posted under mapreduce.

最近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架构图)
Hadoop0.23.0初探1---前因后果
图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执行架构图)
Hadoop0.23.0初探1---前因后果

图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的关系图。

      Hadoop0.23.0初探1---前因后果
图3 Namespace和Block Storage

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

Hadoop0.23.0初探1---前因后果
           图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等编程模型,实现对于多种应用场景的支持。

Hadoop0.23.0初探1---前因后果
图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:本篇文章属于原创,其中有不合适的地方,还请大家批评指正。如果要联系本文作者,请发邮件:
jiangbinglover@sina.com
jiangbinglover@gmail.com
如需要转载,请附上上面的邮箱地址,谢谢,我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢!

From Binospace, post Hadoop0.23.0初探1—前因后果

文章的脚注信息由WordPress的wp-posturl插件自动生成





Do you have any comments on Hadoop0.23.0初探1—前因后果 ?