Hadoop0.23.0初探1---前因后果
来源:互联网 发布:人工智能如何入门 编辑:程序博客网 时间:2024/05/17 04:00
最近Hadoop社区最火热的事情莫过于Hortonworks公布了Hadoop最新版本(0.23.0),它标志着Hadoop新时代的到来。本文作为系列文章的第一篇,将结合Hadoop-0.20.*的特点,以及Hadoop核心理念,分析Hadoop新版本的特征。
1、Hadoop 0.20.*的局限性
1、Hadoop 0.20.*的局限性
- HDFS单NameNode的不足
1)扩展性问题。可以随着数据量进行水平扩展,而元数据服务器不能扩展。
2)随着文件数目的增长,元数据服务器的压力变大。据统计,2.5亿个文件在NameNode中Namespace占据 的大概64GB的内存空间。
3)文件操作的吞吐率受到单个元数据服务器的限制。目前,Hadoop 0.20.*版本可以达到120k readops/sec,6000writeops/sec.
4)隔离性的问题。0.20.*版本中,一个NameNode对应着唯一的Namespace,所有文件、应用、用户公用同一的名字空间。存在访问权限控制的问题,不利于在HDFS在公有云环境下的应用。
(ps:图1为0.20.*版本下HDFS架构图)
2)仅支持MapReduce编程模型。在Hadoop框架内实现PageRank、LogicalRegression等迭代算法,需要将算法映射成MapReduce的组合、或者使用Pig、Casscading、Hive等应用层的逻辑描述,不能从模型本身去表达,算法性能受到了影响(10xslower)。
(ps:图2为0.20.*版本下MapReduce执行架构图)
2、Hadoop核心理念
3、Hadoop-0.23的NewFeatures
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上。系统提供了一个公共的Blockpools隔离了Namespace与Block交互。图4为HDFS Federation Architecture
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等编程模型,实现对于多种应用场景的支持。
图5 Hadoop YARN Architecture
2)运行时环境的扩展性与单点故障问题。
运行时环境的扩展性是支持更多的工作节点,同时运行更多的任务。Hadoop之前版本由于是JobTracker不仅管理集群内资源分配,还要管理任务的调度,造成整个系统扩展性不强,并且JobTracker成为作为脆弱的一环。由于在JobTracker需要繁忙的信息交互,并且所有信息仅保留一份,宕机之后运行作业的信息丢失,这已经成为制约Hadoop继续扩大规模的重要影响因素。
Hadoop0.23为了解决扩展性的问题,为每一个job启动一个Application life-cyclemanagement,负责job内任务的初始化、调度和监控,分担之前所有Job集中管理的JobTracker的负荷,ResourceManager仅仅做集群资源的管理。
Hadoop0.23为了解决单点故障问题。一是如上所说把之前作业内部任务的管理分离出去,减轻中心节点的负载。二是使用ZooKeeper集群缓存ResourceManager的状态信息,保证关键数据的可靠性,当重启之后,保证重要数据不丢失。
4、参考资料
2)随着文件数目的增长,元数据服务器的压力变大。据统计,2.5亿个文件在NameNode中Namespace占据 的大概64GB的内存空间。
3)文件操作的吞吐率受到单个元数据服务器的限制。目前,Hadoop 0.20.*版本可以达到120k readops/sec,6000writeops/sec.
4)隔离性的问题。0.20.*版本中,一个NameNode对应着唯一的Namespace,所有文件、应用、用户公用同一的名字空间。存在访问权限控制的问题,不利于在HDFS在公有云环境下的应用。
(ps:图1为0.20.*版本下HDFS架构图)
图1 Hadoop0.20.* HDFSarchitecture
- MapReduce编程模型与运行时环境紧耦合
2)仅支持MapReduce编程模型。在Hadoop框架内实现PageRank、LogicalRegression等迭代算法,需要将算法映射成MapReduce的组合、或者使用Pig、Casscading、Hive等应用层的逻辑描述,不能从模型本身去表达,算法性能受到了影响(10xslower)。
(ps:图2为0.20.*版本下MapReduce执行架构图)
图2 Hadoop MapReduce执行流程图
2)扩展性问题。JobTracker目前最多支持4000nodes、40000个concurrent tasks。- 单个JobTracker的单点故障和扩展性
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
- HDFS Federation
Hadoop0.20.*仅有一个NameNode,整个系统使用统一的NameSpace,系统所有对于文件的操作都要经过唯一的Namenode来进行,造成了NameNode负载过重。图3为Namespace和Block Storage的关系图。
图3 Namespace和Block Storage
图4 HDFS Federation Architecture
- MapReduce NextGen aka YARN
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等编程模型,实现对于多种应用场景的支持。
图5 Hadoop YARN Architecture
2)运行时环境的扩展性与单点故障问题。
运行时环境的扩展性是支持更多的工作节点,同时运行更多的任务。Hadoop之前版本由于是JobTracker不仅管理集群内资源分配,还要管理任务的调度,造成整个系统扩展性不强,并且JobTracker成为作为脆弱的一环。由于在JobTracker需要繁忙的信息交互,并且所有信息仅保留一份,宕机之后运行作业的信息丢失,这已经成为制约Hadoop继续扩大规模的重要影响因素。
Hadoop0.23为了解决扩展性的问题,为每一个job启动一个Application life-cyclemanagement,负责job内任务的初始化、调度和监控,分担之前所有Job集中管理的JobTracker的负荷,ResourceManager仅仅做集群资源的管理。
Hadoop0.23为了解决单点故障问题。一是如上所说把之前作业内部任务的管理分离出去,减轻中心节点的负载。二是使用ZooKeeper集群缓存ResourceManager的状态信息,保证关键数据的可靠性,当重启之后,保证重要数据不丢失。
4、参考资料
[1]Hadoop0.23.0http://www.slideshare.net/cloudera/hadoop-world-2011-apache-hadoop-023-arun-murthy-horton-works
[2] HDFS federalhttp://www.slideshare.net/hortonworks/hs-2011-submission87hwfinal
[3} Hadoop Next MapReduceGeneration http://www.slideshare.net/hortonworks/nextgen-apache-hadoop-mapreduce
ps:本篇文章属于原创,其中有不合适的地方,还请大家批评指正。如果要联系本文作者,请发邮件:
jiangbinglover@sina.com
jiangbinglover@gmail.com
如需要转载,请附上上面的邮箱地址,谢谢,我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢!
ps:本篇文章属于原创,其中有不合适的地方,还请大家批评指正。如果要联系本文作者,请发邮件:
jiangbinglover@sina.com
jiangbinglover@gmail.com
如需要转载,请附上上面的邮箱地址,谢谢,我期望和更多的朋友关于MapReduce、Hadoop、分布式系统展开有价值的讨论。谢谢!
- Hadoop0.23.0初探1---前因后果
- Hadoop0.23.0初探1---前因后果
- Hadoop0.23.0初探1---前因后果
- Hadoop0.23.0初探1---前因后果
- Hadoop0.23.0初探1---前因后果
- Hadoop0.23.0初探2---HDFS Federation部署
- Hadoop0.23.0初探2---HDFS Federation部署
- Hadoop0.23.0初探2---HDFS Federation部署
- Hadoop0.23.0初探2---HDFS Federation部署
- Hadoop0.23.0初探3---HDFS NN,SNN,BN和HA
- Hadoop0.23.0初探3---HDFS NN,SNN,BN和HA
- Hadoop0.23.0初探3---HDFS NN,SNN,BN和HA
- Hadoop0.23.0初探4---让你的第一个YARN MapReduce跑起来
- Hadoop0.23.0初探4---让你的第一个YARN MapReduce跑起来
- 张五常-《佃农理论》的前因后果(1)
- hive-0.8.1安装(hadoop0.20.2)
- Hadoop0.23.0 RM-NM-AM源码级分析
- Hadoop0.21.0源码流程分析(1)-客户端提交作业
- java 返回json数据
- ComboBox不能显示下拉内容如何解决
- 7个你不知道的WP7开发工具
- Oracle 优化
- Linux下监测经过网卡的每秒的流量和数据包个数
- Hadoop0.23.0初探1---前因后果
- Single chip和multi chip對Linux研發的影響 - 答客問(转载)
- Android平台调用.NET WebService详解
- UC故事2011/12/16 build linux servers
- VC调试WATCH跟踪变量CXX0017: Error: symbol "temp" not found 解决办法
- Analytiks:低价享受Google Analytics的网站流量分析服务
- ogre 学习笔记系列(一)环境搭建
- Hadoop0.23.0初探2---HDFS Federation部署
- 一个跟操作系统linux和windows差异有关的问题:通过soap的无wsdl实现php程序通信的程序(经典的吐血)