转发:http://blog.csdn.net/ae86_fc/article/details/5844869
Apache Hadoop 0.21版本新功能ChangeNode
Apache Hadoop 0.21.0 在2010年8月23日release了。Cloudera的Tom White哥(OReilly.Hadoop.The.Definitive.Guide第一版的作者)已经将该版本对比0.20的 修改进行了整理,记录下来以作备忘。
apache社区上一个release的版本还是0.20.0版本,还是在去年的四月份 release的。所以这个版本中引入了许多新的功能,也有许多新的改进。根据tom哥的统计,在hadoop Common,HDFS,MapReduce三个模块中,总共有超过1300多个改进的issue在JIRA上讨论。但是,就像以前 所有的‘.0’版本一样,0.21.0并不推荐用来做稳定的生产系统,还需要实践对他做进一步的考验。
因为有许多的改进和优化,所以这里无法所有的都面面俱到。这里仅仅从高层面罗列一些在0.21.0中比较重要的 修改和功能。如果要了解0.21.0的所有新增特性和功能,可以参考0.21.0的 change logs (Common , HDFS , MapReduce )。
Project Split
从0.21.0开始,整个hadoop项目被分割成三个独立的模块。分别是 Common , HDFS , and MapReduce . HDSF和MapReduce都对Common模块有依赖,但是0.21.0开始MapReduce对HDFS并没有依赖了(除 非是testcase)。将hadoop项目的分割也可以强调了一个事实:MapReduce可以运行其他的分布式文件系统之上,并 不仅仅限于HDFS(虽然HDFS在读写吞吐和可扩展性上仍然是MapReduce程序的首选)。这样分开以后对每个模块的开发就可 以独立,同时对集群的升级也会变得比以前代价小,比如,如果只修改了调度器,或者jobtracker策略,就只需要升级 mapred模块,而不需要重启hdfs。而如果只修改了namenode rpc逻辑,就只需要升级hdfs就可以。这样分开以后,仍 然是一个tar包发布的,但是内部的目录结构会有一些变化,每个模块的代码被分别放置在各自不同的目录中保存。
对于hadoop用户来说,使用起来会有一些变化。原先的hadoop-site.xml配置文件被分成了三个,分别是core-site.xml , hdfs-site.xml 和mapred-site.xml (这个在0.20中就已经是这样了)。不仅如 此,控制脚本也从以前的bin/hadoop被分解成bin/hadoop, bin/hfds和 bin/mapreduce( HADOOP-4868 , 个人感觉这个没必要……)。不过 以前的 bin/hadoop 命令仍然可用,但是会被标识为deprecation警告。最 后,HADOOP_HOME仍然需要被正确的设置才能使用这些控制脚本。
Common
0.21.0的API仍然向后兼容(0.20.2)。在common的这个版本中,对测试方面有非常大的改进。其 中包括一个Large-Scale Automated Test Framework (HADOOP-6332 )。这 个框架允许开发人员在一个真实的集群上运行自己的testcase。虽然目前只有为数不多的一些testcase在这个框架下运行,但 是将来可以有更多的测试可以被写进去,这样回归测试就可以被重用并运行在新发布的hadoop版本上,从而让hadoop的升级效果 变得更加可预知。
hadoop 0.21的common还引入了fault injection framework , 它使用AOP来将各种faults注入到整个框架下(比如一个datanode)运行,并期望在特定的错误下系统采取的措施是否合 理。
另外,还有一个比较大的改进就是:用户可以通过再浏览器中访问URLs/metrcs,/conf来从 hadoop的daemon进程中(如datanode,jobtracker等)抽取出想要的metrics数据。这将 是对集群管理员和作业运行人员检查和排错至关重要!(做过集群管理员或者帮人排查过mapreduce作业错误失败原因的肯定深深的 体会过!)
HDFS
这次发布的HDFS最大的一个改动就是:支持append模式的。这种模式的功能在0.19.0 的时候就提出来过,但是最终被否决,原因是在当时的情况下,这种模式会带来稳定性的问题。在0.21.0中,这种HDFS的服务模式 终于被支持,HDFS-265 记录了整个append模式的开发和讨论过程以及详细设计文档,这个值得深入调 研。在append模式下,可以使用FileSystem.append()接口来进行append写入。这种模式更具意义的环境在 于:类似像HBase这种随机访问以及对实时写入要求非常苛刻的系统,hdfs的append模式将提供很好的支持,这样 在HBase中由于 HLog 写入hdfs没有sync语义的缘故而导致丢数据等事情将得到解决。
在这次的hadoop 0.21.0 中,提供了一个新的FileSystem的API,叫FileContext,通过这个API,可以让使用者更加方便的在应用程序中使用多个文件系统 (HADOOP-4952 )。这个API还没有在hadoop中被大量的使用,因为还没有被合并倒 mapreduce计算中,但是它包含了normao的FileSystem 接口没有的新功能,如支持hdfs层面的软链接等 (HADOOP-6421 , HDFS-245 )。
在0.21.0中,secondarynamenode被取缔了。往常在 secondarynamenode中无非也就是阶段性的将namenode上的editlog和fsimage进行合并,称之为一次 checkpoint,然后回灌给namenode,就做这么一件事情,现在0.21.0中,被一个叫做checkpoint node的角色给取代。然后还多了一个BackupNode的角色,这个BackupNode相当于一个namenode的“冷备机”,之前的文章中提到 过,namenode在hadoop hdfs中是一个单点,如果这个单点发生故障,需要对namenode进行failover,而在一个规模很大,文件目录以及文件块很多的HDFS中,重 启一次namenode花费的时间是相当长的,时间主要耗费在fsimage加载阶段以及所有的datanodes做blockReport的阶段,这里 的BackupNode之所以可以称之为“冷备机”,原因在于,它在内存中已经将最新的fsimage加载到内存中,跟namenode是保持同步的,一 旦namenode宕机,BackupNode可以接收blockReport,所以fsimage加载的时间可以省下来,但是blockReport的 时间无法省略,所以称之为“冷备”。并且在0.21.0中,BackupNode跟namenode的fsimage同步不再需要NFS mount来实现,它们之间有了一个stream的通道,namenode可以通过这个通道直接将editlog写入到BackupNode的磁盘中。
在新的0.21.0 中,还提供了一个fsimage的离线查看工具 (HADOOP-5467 ), 由于fsimage是一个binary文件,这个工具对于集群管理员查看fsimage里的内容,排查文件系统问题,观察文件系统的各种情况非常有用。不 仅如此,这个工具还支持对fsimage不同版本的支持,连0.19遗留下来的fsimage的version -18版本都支持,的确非常周到。
同 时,还有一个block验证工具(HDFS-567 ),用来从HDFS的log中发现corrupt和missing的数据块,这对集群管理员来说也是非常非常有用的工具。
对于每个文件对应的数据块被放置在哪些datanode上,以前一直没有集群使用者或者管理者进行控制的手段,只能由namenode本身来决定, 如今在0.21.0中提供了block放置算法的自定义方式,集群的开发者或者管理员可以自行定义文件块的放置函数,以根据集群当前的情况来控制 block的放置情况。不过这是比较高级的功能,一般人可能用不上。
还有一些其他新的功能包括:
支持高效的文件合 并操作 (HDFS-222 )等等
MapReduce
在mapreduce模块中变化最大的就是一些新API的加入,叫做 “context objects”。由于mapreduce lib(在org.apache.hadoop.mapreduce.lib中)已经加入该新API (MAPREDUCE-334 ),所以这个新的API在mapreduce中已经被广泛的支持。在新版的 examples包中也都使用了该新的API。不仅如此,为了让用户更加平滑的迁移倒新API上来,对老API的支持仍然有效,这就能保证目前情况下,升 级倒0.21.0不需要对已有的应用程序进行修改(不会会得到一些warning)。
LocalJobRunner (一个在测试环境下运行mapreduce 小数据集作业的工具)在新版本中被改进了很多,使得作业更像是在真正的集群环境下运行。它目前已经支持distribute cache (MAPREDUCE-476 )功能,并且可以并行的运行mappers(MAPREDUCE-1367 ).
Distcp在新版本中也被改进了许多,提供了保存文件的mtime (HADOOP-5620 ),源文件通配符匹配 (HADOOP-5472 ), 保存源路径目录结构(MAPREDUCE-642 )等功能。对用户来说非常方便。
在测试框架方面,这个版本中首次和入了MRUnit框架,该框架是一个contrib中的模块 (HADOOP-5518 ), 可以帮助用户编写自己mapreduce作业的测试用例。
另外,在contrib中还提供了两个新的模块,叫做Rumen (MAPREDUCE-751 )和Mumak(MAPREDUCE-728 ),这两个都是对maprduce作业的工具。它们需要协同工作。Rumen可以从 job的history log中抽取job 数据,然后Mumak可以利用这些job数据来模拟作业和集群情况。Gridmix3 也在做了响应修改,利用Rumen来做job traces。同时,还有一个历史作业日志分析器,也可以用来分析历史作业的日志以及集群情况。没有做过集群管理的人可能比较难理解,这些工具都是集群管理员的福音啊,有了这些工具,集群管理员就可以从被上级要一个什么数据,就要去写一系列的日志分析脚本,要一个另外什么统计数据,又要辛辛苦苦的去写另外 一套分析日志脚本的繁琐工作中解放出来,太有用了。
在调度器方面,Fair Scheduler(提到这个名称,突然由一种莫名其妙的复杂情绪和怀念之情涌上心头……)也做了一些修改,包含了全局调 度优先抢占(MAPREDUCE-548 ),以及支持FIFO pools(MAPREDUCE-551 )等功能。同样的,Capacity Scheduler现在开始支持层级队列,并支持管理层面定义的硬limit等功能。同时还有另外的一个调度器,叫做Dynamic Prorioty调度器(HADOOP-4768 )诞生。
其他一些mapreduce模块的修改包括:
现在支持了Streaming combiners, 因此现在可以通过脚本的方式在streaming作业中提供用户自定义的 combiner,而不仅仅限于用java实现的combiner (HADOOP-4842 )。
在一个job完成后,mapreduce会在output目录下创建一个_SUCCESS文件 (MAPREDUCE-947 )。这个功能虽然小,但是对应用程序需要确认某个输出目录中的数据是否正确非常有 效。(昨天公司的应用里就出过这样的情况,预测执行下的同一个task的两个instance产生了两个输出结果,导致作业结果由问题……)
Apache Hadoop 0.21版本新功能ChangeNode
Apache Hadoop 0.21.0 在2010年8月23日release了。Cloudera的Tom White哥(OReilly.Hadoop.The.Definitive.Guide第一版的作者)已经将该版本对比0.20的 修改进行了整理,记录下来以作备忘。
apache社区上一个release的版本还是0.20.0版本,还是在去年的四月份 release的。所以这个版本中引入了许多新的功能,也有许多新的改进。根据tom哥的统计,在hadoop Common,HDFS,MapReduce三个模块中,总共有超过1300多个改进的issue在JIRA上讨论。但是,就像以前 所有的‘.0’版本一样,0.21.0并不推荐用来做稳定的生产系统,还需要实践对他做进一步的考验。
因为有许多的改进和优化,所以这里无法所有的都面面俱到。这里仅仅从高层面罗列一些在0.21.0中比较重要的 修改和功能。如果要了解0.21.0的所有新增特性和功能,可以参考0.21.0的 change logs (Common , HDFS , MapReduce )。
Project Split
从0.21.0开始,整个hadoop项目被分割成三个独立的模块。分别是 Common , HDFS , and MapReduce . HDSF和MapReduce都对Common模块有依赖,但是0.21.0开始MapReduce对HDFS并没有依赖了(除 非是testcase)。将hadoop项目的分割也可以强调了一个事实:MapReduce可以运行其他的分布式文件系统之上,并 不仅仅限于HDFS(虽然HDFS在读写吞吐和可扩展性上仍然是MapReduce程序的首选)。这样分开以后对每个模块的开发就可 以独立,同时对集群的升级也会变得比以前代价小,比如,如果只修改了调度器,或者jobtracker策略,就只需要升级 mapred模块,而不需要重启hdfs。而如果只修改了namenode rpc逻辑,就只需要升级hdfs就可以。这样分开以后,仍 然是一个tar包发布的,但是内部的目录结构会有一些变化,每个模块的代码被分别放置在各自不同的目录中保存。
对于hadoop用户来说,使用起来会有一些变化。原先的hadoop-site.xml配置文件被分成了三个,分别是core-site.xml , hdfs-site.xml 和mapred-site.xml (这个在0.20中就已经是这样了)。不仅如 此,控制脚本也从以前的bin/hadoop被分解成bin/hadoop, bin/hfds和 bin/mapreduce( HADOOP-4868 , 个人感觉这个没必要……)。不过 以前的 bin/hadoop 命令仍然可用,但是会被标识为deprecation警告。最 后,HADOOP_HOME仍然需要被正确的设置才能使用这些控制脚本。
Common
0.21.0的API仍然向后兼容(0.20.2)。在common的这个版本中,对测试方面有非常大的改进。其 中包括一个Large-Scale Automated Test Framework (HADOOP-6332 )。这 个框架允许开发人员在一个真实的集群上运行自己的testcase。虽然目前只有为数不多的一些testcase在这个框架下运行,但 是将来可以有更多的测试可以被写进去,这样回归测试就可以被重用并运行在新发布的hadoop版本上,从而让hadoop的升级效果 变得更加可预知。
hadoop 0.21的common还引入了fault injection framework , 它使用AOP来将各种faults注入到整个框架下(比如一个datanode)运行,并期望在特定的错误下系统采取的措施是否合 理。
另外,还有一个比较大的改进就是:用户可以通过再浏览器中访问URLs/metrcs,/conf来从 hadoop的daemon进程中(如datanode,jobtracker等)抽取出想要的metrics数据。这将 是对集群管理员和作业运行人员检查和排错至关重要!(做过集群管理员或者帮人排查过mapreduce作业错误失败原因的肯定深深的 体会过!)
HDFS
这次发布的HDFS最大的一个改动就是:支持append模式的。这种模式的功能在0.19.0 的时候就提出来过,但是最终被否决,原因是在当时的情况下,这种模式会带来稳定性的问题。在0.21.0中,这种HDFS的服务模式 终于被支持,HDFS-265 记录了整个append模式的开发和讨论过程以及详细设计文档,这个值得深入调 研。在append模式下,可以使用FileSystem.append()接口来进行append写入。这种模式更具意义的环境在 于:类似像HBase这种随机访问以及对实时写入要求非常苛刻的系统,hdfs的append模式将提供很好的支持,这样 在HBase中由于 HLog 写入hdfs没有sync语义的缘故而导致丢数据等事情将得到解决。
在这次的hadoop 0.21.0 中,提供了一个新的FileSystem的API,叫FileContext,通过这个API,可以让使用者更加方便的在应用程序中使用多个文件系统 (HADOOP-4952 )。这个API还没有在hadoop中被大量的使用,因为还没有被合并倒 mapreduce计算中,但是它包含了normao的FileSystem 接口没有的新功能,如支持hdfs层面的软链接等 (HADOOP-6421 , HDFS-245 )。
在0.21.0中,secondarynamenode被取缔了。往常在 secondarynamenode中无非也就是阶段性的将namenode上的editlog和fsimage进行合并,称之为一次 checkpoint,然后回灌给namenode,就做这么一件事情,现在0.21.0中,被一个叫做checkpoint node的角色给取代。然后还多了一个BackupNode的角色,这个BackupNode相当于一个namenode的“冷备机”,之前的文章中提到 过,namenode在hadoop hdfs中是一个单点,如果这个单点发生故障,需要对namenode进行failover,而在一个规模很大,文件目录以及文件块很多的HDFS中,重 启一次namenode花费的时间是相当长的,时间主要耗费在fsimage加载阶段以及所有的datanodes做blockReport的阶段,这里 的BackupNode之所以可以称之为“冷备机”,原因在于,它在内存中已经将最新的fsimage加载到内存中,跟namenode是保持同步的,一 旦namenode宕机,BackupNode可以接收blockReport,所以fsimage加载的时间可以省下来,但是blockReport的 时间无法省略,所以称之为“冷备”。并且在0.21.0中,BackupNode跟namenode的fsimage同步不再需要NFS mount来实现,它们之间有了一个stream的通道,namenode可以通过这个通道直接将editlog写入到BackupNode的磁盘中。
在新的0.21.0 中,还提供了一个fsimage的离线查看工具 (HADOOP-5467 ), 由于fsimage是一个binary文件,这个工具对于集群管理员查看fsimage里的内容,排查文件系统问题,观察文件系统的各种情况非常有用。不 仅如此,这个工具还支持对fsimage不同版本的支持,连0.19遗留下来的fsimage的version -18版本都支持,的确非常周到。
同 时,还有一个block验证工具(HDFS-567 ),用来从HDFS的log中发现corrupt和missing的数据块,这对集群管理员来说也是非常非常有用的工具。
对于每个文件对应的数据块被放置在哪些datanode上,以前一直没有集群使用者或者管理者进行控制的手段,只能由namenode本身来决定, 如今在0.21.0中提供了block放置算法的自定义方式,集群的开发者或者管理员可以自行定义文件块的放置函数,以根据集群当前的情况来控制 block的放置情况。不过这是比较高级的功能,一般人可能用不上。
还有一些其他新的功能包括:
支持高效的文件合 并操作 (HDFS-222 )等等
MapReduce
在mapreduce模块中变化最大的就是一些新API的加入,叫做 “context objects”。由于mapreduce lib(在org.apache.hadoop.mapreduce.lib中)已经加入该新API (MAPREDUCE-334 ),所以这个新的API在mapreduce中已经被广泛的支持。在新版的 examples包中也都使用了该新的API。不仅如此,为了让用户更加平滑的迁移倒新API上来,对老API的支持仍然有效,这就能保证目前情况下,升 级倒0.21.0不需要对已有的应用程序进行修改(不会会得到一些warning)。
LocalJobRunner (一个在测试环境下运行mapreduce 小数据集作业的工具)在新版本中被改进了很多,使得作业更像是在真正的集群环境下运行。它目前已经支持distribute cache (MAPREDUCE-476 )功能,并且可以并行的运行mappers(MAPREDUCE-1367 ).
Distcp在新版本中也被改进了许多,提供了保存文件的mtime (HADOOP-5620 ),源文件通配符匹配 (HADOOP-5472 ), 保存源路径目录结构(MAPREDUCE-642 )等功能。对用户来说非常方便。
在测试框架方面,这个版本中首次和入了MRUnit框架,该框架是一个contrib中的模块 (HADOOP-5518 ), 可以帮助用户编写自己mapreduce作业的测试用例。
另外,在contrib中还提供了两个新的模块,叫做Rumen (MAPREDUCE-751 )和Mumak(MAPREDUCE-728 ),这两个都是对maprduce作业的工具。它们需要协同工作。Rumen可以从 job的history log中抽取job 数据,然后Mumak可以利用这些job数据来模拟作业和集群情况。Gridmix3 也在做了响应修改,利用Rumen来做job traces。同时,还有一个历史作业日志分析器,也可以用来分析历史作业的日志以及集群情况。没有做过集群管理的人可能比较难理解,这些工具都是集群管理员的福音啊,有了这些工具,集群管理员就可以从被上级要一个什么数据,就要去写一系列的日志分析脚本,要一个另外什么统计数据,又要辛辛苦苦的去写另外 一套分析日志脚本的繁琐工作中解放出来,太有用了。
在调度器方面,Fair Scheduler(提到这个名称,突然由一种莫名其妙的复杂情绪和怀念之情涌上心头……)也做了一些修改,包含了全局调 度优先抢占(MAPREDUCE-548 ),以及支持FIFO pools(MAPREDUCE-551 )等功能。同样的,Capacity Scheduler现在开始支持层级队列,并支持管理层面定义的硬limit等功能。同时还有另外的一个调度器,叫做Dynamic Prorioty调度器(HADOOP-4768 )诞生。
其他一些mapreduce模块的修改包括:
现在支持了Streaming combiners, 因此现在可以通过脚本的方式在streaming作业中提供用户自定义的 combiner,而不仅仅限于用java实现的combiner (HADOOP-4842 )。
在一个job完成后,mapreduce会在output目录下创建一个_SUCCESS文件 (MAPREDUCE-947 )。这个功能虽然小,但是对应用程序需要确认某个输出目录中的数据是否正确非常有 效。(昨天公司的应用里就出过这样的情况,预测执行下的同一个task的两个instance产生了两个输出结果,导致作业结果由问题……)