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

阿牛

　　  本博客属原创文章,转载请注明出处:http://guoyunsky.iyunv.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为何没法做到,也是一样的切片逻辑.具体待测试.
更多文章、感悟、分享、勾搭，请用微信扫描: