我正在尝试使用bzip2压缩hdfs上的文件。使用mapreduce流媒体进行此操作似乎是一种很好的方法，如以下帖子中的答案所示：
hdfs中的hadoop压缩文件
该帖子的相关代码示例是：

hadoop jar contrib/streaming/hadoop-streaming-1.0.3.jar \
            -Dmapred.reduce.tasks=0 \
            -Dmapred.output.compress=true \
            -Dmapred.compress.map.output=true \
            -Dmapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec \
            -input filename \
            -output /filename \
            -mapper /bin/cat \
            -inputformat org.apache.hadoop.mapred.TextInputFormat \
            -outputformat org.apache.hadoop.mapred.TextOutputFormat
hadoop fs -cat /path/part* | hadoop fs -put - /path/compressed.gz

实际上，我为bzip2做了与上面相同的工作，使用javahadoopstreamingapi，并使用toolrunner从非集群机器调用集群上的流作业。
这种方法的重要特点是：
因为这是一个输入格式为文本的流式作业，所以只从map任务输出值，而不是键，即文件行的内容，而不是字节偏移量。
这是一项只做Map的工作。我相信这意味着在map阶段结束时不会进行排序，这使得它非常有效。
单独的压缩部分连接在一起，形成一个单独的压缩文件。
尝试过这种方法后，我发现它似乎很有效，但随后发现无法保证part文件在连接到一起之前的顺序是正确的。i、 e.当我解压缩文件时，块本身在内部总是正确的，但有时顺序是错误的。
我一直在考虑的可能的解决方案基本上分为两类——要么引入减速机要么不引入减速机。
如果引入减速机，那么下面的帖子似乎是相关的：
mapreduce作业输出排序顺序
问题不是同一个要求，但是对所有part文件进行全局排序的想法似乎是相关的，可以通过覆盖默认的partitioner和其他方法来实现。然而，我不认为这符合我的目的，因为如果我有减缩器，那么map阶段将对数据进行排序（在行数据上按字母顺序排列，因为键没有被写入，根据上面的第1点），这是我不希望发生的。即使我可以阻止这种情况，但我觉得使用减速器并不是解决这个问题的真正方法。
所以我只想找到一种方法，用零减速器来实现这一点。我真正想要的是一种跟踪/标记/排序输入拆分的方法，这样当part*文件从mapreduce出来时，我就知道如何重新排序，这样在解压缩时，文件与原始文件相同。但是，我怀疑mapreduce不是设计成这样工作的——也就是说，作为一个用户，我无法控制拆分本身，Map作业彼此独立运行，可能以任何顺序完成。
如果有人对如何解决这个问题有任何想法，我很想听听你的意见，谢谢。