我将在hadoop中复制很多压缩为gzip的大型博客文件。我需要在这些文件上运行许多 map/reduce。
据我了解,只有一个 Map/Reduce 将按文件运行。就我而言,这是不可接受的,因为我们需要尽快完成这些工作。
将 gzip 文件拆分为较小的块(在将它们复制到 hadoop 之前或之后)以能够运行尽可能多的 map/reduce 是否是常见的做法?
谢谢你的帮助。
您可以使用 lzop 生成文件的 lzo 压缩副本 - 尽管压缩率低于 gzip,但 lzo 解压缩速度非常快。
就像是;
gunzip --stdout 文件.gz | lzop -ofile.lzo
应该管用。
将lzo文件复制到hdfs然后安装hadoop-lzo并使用它为lzo文件生成索引;
hadoop jar (hadoop-lzo jar 的路径) com.hadoop.compression.lzo.LzoIndexer file.lzo
(如果您愿意,也可以使用 com.hadoop.compression.lzo.DistributedLzoIndexer)
这将为 lzo 文件创建一个索引。
然后,Hadoop 将在为 MapReduce 作业生成拆分时使用(使用正确的输入格式)索引,以将 .lzo 压缩文件分发到多个映射器/减速器。
这里有更详细的信息;
https://github.com/twitter/hadoop-lzo
以及该 repo 的一个分支,用于解决一些问题;
我仍然不清楚你的问题,所以我会回答这个问题,如果我很接近,你可以告诉我:
如何使用 map/reduce 范式解压缩大的 gzip 文件?
除非为此专门准备了 gzip 文件,否则无法映射出解压作业。解压必须连续进行。即使 bzip2 压缩数据已经在单独的可解压缩块中,您也无法在没有解压整个内容的情况下找到这些块,串行地指向它们,这可能违背了目的。
您提到了 LZO 的“容器”格式,如果我理解正确的话,它也适用于 gzip 和 bzip2。
对于这些格式中的任何一种,您都可以通过分段压缩来准备用于并行解压缩的 gzip 流。例如,每个片段为兆字节或几兆字节,以便不会显着降低压缩性能,并维护对在压缩时构建并与压缩数据文件一起传输或存储的那些片段的索引。
gzip 流的串联本身就是一个有效的 gzip 流,它解压缩为各个流的解压缩的串联。bzip2 格式也是如此。对于 bzip2,这些片段应该是 900K 的倍数,以免有部分块,这在压缩率方面效率较低。
然后,您可以构建这样的 gzip 或 bzip2 文件,并在其中保留每个 gzip 或 bzip2 流开始的文件偏移列表。然后您可以绘制出这些部分,其中 reduce 步骤将简单地以正确的顺序连接未压缩的结果。