Hadoop Lzo 源码分析之分片/切片原理

  本博客属原创文章,转载请注明出处:http://guoyunsky.iteye.com/blog/1420402

   欢迎加入Hadoop超级群: 180941958

 

      lzo压缩已经广泛用于Hadoop中,至于为什么要在Hadoop中使用Lzo.这里不再重述.其中很重要的一点就是由于分布式计算,所以需要支持对压缩数据进行分片,也就是Hadoop的InputSplit,这样才能分配给多台机器并行处理.所以这里花了一天的时间,看了下Hadoop lzo的源码,了解下Hadoop lzo是如何做到的.

       其实一直有种误解,就是以为lzo本身是支持分布式的,也就是支持压缩后的数据可以分片.我们提供给它分片的逻辑,由lzo本身控制.但看了Hadoop lzo源码才发现,lzo只是个压缩和解压缩的工具,如何分片,是由Hadoop lzo(Javad代码里)控制.具体的分片算法写得也很简单,就是在内存中开一块大大的缓存,默认是256K,缓存可以在通过io.compression.codec.lzo.buffersize参数指定.数据读入缓存(实际上要更小一些),如果缓存满了,则交给lzo压缩,获取压缩后的数据,同时在lzo文件中写入压缩前后的大小以及压缩后的数据.所以这里,一个分片,其实就是<=缓存大小.具体lzo文件格式(这里针对Lzop):

       1.lzo文件头

        1）写入lzo文件标识： 此时长度9

2）写入版本

LZOP_VERSIONlzo版本，short，此时长度11

LZO_VERSION_LIBRARYlzo压缩库版本，short，此时长度13

LZOP_COMPAT_VERSION最后lzo应该一直的版本，short，此时长度15

3）写入压缩策略

LZO1X_1的话writeByte写入1和5，此时长度17

4)writeInt写入flag(标识)，此时长度21

5）writeInt写入mode(模式)，此时长度25

6)writeInt写入当前时间秒，此时长度29

7）writeInt写入0,不知道做何用途，此时长度33

8）writeBye写入0，不知道做何用途，此时长度34

9）writeInt写入之前数据的checksum，此时长度38

 

       2. 写入多个块,会有多个.循环处理,直到压缩完成

10)写入压缩前的数据长度,此时长度为39

        11)如果压缩前的长度小于压缩后的长度,则写入未压缩的数据长度,再写入未压缩的数据.

             反之则写入压缩后的数据长度,以及压缩后的数据

       

      3.lzo文件尾,只是写入4个0,不知道做什么用途

 

     同时如果你指定索引文件路径的话,则一个缓存写完后便会将写入的数据长度写到索引文件中.如此在Hadoop分布式时只要根据索引文件的各个长度,读取该长度的数据 ,便可交给map处理.

 

     以上是hadoop lzo大概原理,同时LzopCodec支持在压缩时又生成对应的索引文件.而LzoCodec不支持.具体代码看下来,还不明确LzoCodec为何没法做到,也是一样的切片逻辑.具体待测试.

 

更多技术文章、感悟、分享、勾搭，请用微信扫描:

       

评论

2 楼 jalimay 2012-09-05  

那是否可以这样理解，lzo压缩后文件其实本身是可拆分的，拆分单位默认是256K。
因为HDFS的block大小刚好是256K的整数倍，所以HDFS在把lzo压缩过的文件拆分后，每个block的压缩文件还是可以被lzo算法给解压为正确文本。

1 楼 caizhongda 2012-02-28  

mark.一下。