我们意识到太晚了,将我们的文件以GZip格式进行Hadoop处理的归档并不是一个好主意。 GZip无法分割,以下是问题的参考资料,我不再赘述:
我的问题是:BZip2是否是最佳归档压缩,使单个归档文件可以由Hadoop并行处理? Gzip明显不是,从我阅读的内容来看,LZO也存在一些问题。
gzip和xz都支持简单的串联。 这使您可以轻松地准备归档以进行另一种并行解压缩。 简而言之:
gzip < a > a.gz
gzip < b > b.gz
cat a.gz b.gz > c.gz
gunzip < c.gz > c
cat a b | cmp - c
这将导致比较成功。
然后,您可以根据所需大小分块压缩并连接结果。保存每个gzip流的偏移量的索引。从这些偏移量解压缩。您可以根据应用程序选择块的大小。但是,如果它们太小,压缩将受到影响。
通过简单地连接gzip文件,如果使每个块具有固定的未压缩大小,则还可以放弃索引。然后,每个块以相同的四个字节结尾,即按little-endian顺序的未压缩长度,例如对于1 MiB块,为00 00 10 00
,后跟来自下一块的1f 8b 08
,它是gzip标头的开头。该七字节标记可以像bzip2标记一样进行搜索,尽管存在更小的误报概率。
对于连接的xz文件,同样可以使用七个字节的标头:fd 37 7a 58 5a 00 00
。
mapred.output.compression.codec
为org.apache.hadoop.io.compress.BZip2Codec
。我的建议是,bzip 写入速度非常慢。在 Apache Spark 1.6.2、Hadoop 2.7 上测试了一个简单的 JSON 文件压缩,大小为 50GB,使用 bzip 比 gzip 花费的时间多 2 倍。
但是使用 bzip 可以将 50GB 压缩成 4GB!