Hadoop中的数据编码/解码器

在海量数据存储系统中，好的压缩算法可以有效的降低存储开销，减轻运营成本。Hadoop作为当前主流的海量数据存储与计算平台，当然也不例外，再其内部实现了几种经典的编码/解码算法来提供给用户选择，以达到提高应用系统的性能。因此，本文将主要围绕Hadoop中的数据编码/解码器展开详细地讨论。

在 Hadoop的实现中，数据编码器和解码器被抽象成了两个接口：org.apache.hadoop.io.compress.Compressor、org.apache.hadoop.io.compress.Decompressor，所以在Hadoop内部的编码/解码算法实现都需要实现对应的接口。在实际的数据压缩与解压缩过程，Hadoop为用户提供了统一的I/O流处理模式，其过程如下：

与上图描述的过程相对应的一个类图为：

从上面的类图可以轻松的看出，每一种编码器(Compressor)/解码器(Decompressor)最后统一的交由编码解码器(CompressionCodec)来管理，为了标识某一种编码解码器(CompressionCodec)，它设计了getDefaultExtesion()方法来表示这种编解码算法，对应的就是文件的后缀扩展名了。当前在Hadoop内部实现的编码解码器主要有：

对应的文件扩展名是：

当Hadoop启动之前，我们可以通过配置文件来为Hadoop集群配置任意多个编码解码器(CompressionCodec)，这些编码解码器(CompressionCodec)既可以是Hadoop内部实现的，也可以是用户自定义的。对应的配置项为：io.compression.codec，当然，如果没有在配置文件中指定一系列的编码解码器(CompressionCodec)的话，则采用默认的编码解码器：GzipCodec和DefaultCodec。最后所有的这些配置的编码解码器(CompressionCodec)统一交由CompressionCodecFactory来管理。当hadoop在处理一个文件时，它会根据这个文件的后缀名从CompressionCodecFactory获取相应的编码解码器进而对该文件进行解码处理。

所有的压缩算法显现了一个时间和空间的交易：更快的压缩或者解压就以得到很少的空间节约为代价。所有的在上图中的压缩给了一些控制对于在压缩的时候时空的交易。不同的压缩工具有不同的压缩特征。gzip和Zip都是最常见的压缩，出于中间的时间和空间交易比。Bizp2压缩比gzip和ZIP更加有效的，但是更慢。Bzip2的压缩速度比解压速度快，但是它还是比其他别的压缩方法慢。另一方面LZO速度比较快：它比gzip和ZIP快（或者其他别的压缩和解压方法），但是压缩效果不高效。