林子大了,什么鸟都有,hadoop集群大了,什么job都有。经常在hadoop集群里发现HDFS中有老多长度为0的part-000XX的文件,一看就知道是job的reduce产生的输出文件,但是由于job做partition时由于分桶函数不够优,或数据本身的偏移比较厉害,而且开发job的人又没有进行这种情况进行处理的经验,于是某些reduce上没有分到任何的数据,成了“空桶”,但是以hadoop目前的逻辑,不管该桶有没有数据,最终都会产生一个part-00XXX的输出文件。这其实对job本身没什么问题,反正要处理的数据都算出来了,只要长尾不是严重到令人无法忍受,也不会有人去在意。多一个空文件就多一个空文件了。对于应用程序的开发者,这的确不是什么大不了的事。但是,对namenode,这就是个灾难。namenode的在内存里缓存所有的文件的Inode信息,HDFS中文件越多,namenode的内存就越紧张,由此引来一大堆的namenode和HDFS的问题。这里先不提如何彻底解决namenode的内存问题(That’s gona  be a long~ long ~story, 以后再谈),但至少,减少job中空输出文件,能够帮助namendoe降低其内存的消耗,至少能缓解namenode的内存紧张问题,集群大了,job 越多,这样做带来的收益和效果可能就越明显。


怎么做呢?在老0.21以前的版本里,这个可能得依赖一些外围的方法了,比如job完成后check一下,空输出文件删掉,或者通过一些外围工具将输出目录中的文件进行合并什么的。这样虽然能够达到目的,但是会增加hadoop应用程序开发人员的负担,也会增加集群管理员的负担,因为毕竟这是一件额外的工作。但是在0.21及以后的版本中,内置了一个新的东西,叫做LazyOutputFormat,这个东西其实很简单,就是对 所有的OutputFormat(如TextOutputFormat,SequenceFileOutputFormat等等)的一个wrapper,使用了LazyOutputFormat的job,在输出output的时候,会在第一条output的key value输出(调用output.collect (or Context.write).)之前延迟输出文件的创建(part-000XX),那么如果整个task都没有输出,那么输出文件就不会被创建;而如果有输出,则还是按照原本应该的outputFormat格式进行输出。而不像现在所有outputFormat的机制一样,task以开始运行不管有没有输出先把输出文件给创建了再说。这种延迟创建的方式有利于避免job创建过多的空输出文件而占据过多的namendoe内存。


其实这个东西就是个小工具,如果task有输出,那么没有任何影响,如果存在没有输出的task,就会有利于减少空文件数量,是个不错的工具,跟之前不同的是这个小工具集成到了job内部了