大量 zip 压缩包，每一个都很小， 10M 以内，如何利用 MapReduce 实现快速解压呢？

自己写 InputFormat （别问我怎么写有没有资料啥的，逃～

@ym1ng 自己实现了解压工作，但是现在的问题是速度异常慢

@ym1ng 我是参考这个博主写的代码实现解压的，http://cutler.io/2012/07/hadoop-processing-zip-files-in-mapreduce/

你这个瓶颈是磁盘 io 吧

如果你只是想解压这些 zip 文件的话，多开几个进程或者线程，和 CPU 个数差不多，一个个解压就挺快吧？当然如果有很多资源可用，确实可以搞分布式解压，就行 mapreduce 一样？

@Vamposine 但是目前解压速度远远没到磁盘 io 的瓶颈

多开几个进程同时解
为什么要扯到 mapreduce 上去

线程池足够了把

@dawncold 现在的情况是总共有 16T 文件，通过手动的把文件分开放在不同电脑上，开多线程去解压就已经非常耗时了，所以才想通过上传到 hdfs，利用 MapReduce 解压，。但是目前发现解压速度太慢了，完全不知道因为什么。

@dhairoot 这个不好说呢，分布式解压也得看你有多少资源可以被用起来，是有闲置的资源吗，还是解压速度已经够好了只是达不到心理预期？

MapReduce 肯定没有本地多线程解压快的

不同压缩格式的解压速度是不一样的，先看看你的压缩格式能支持多快的速度吧

应该用 c 语言来写

这个没必要 MapReduce 吧，你这个全是小任务，就多进程 /线程来好了，效率肯定比 MapReduce 高。

forkjoinpool

你是说 hdfs 上有大量 zip 文件，还是说你本地硬盘上有很多小 zip 文件想用 mapreduce 加速？


如果是后者。。。

@est hdfs 上和本地上的文件是一样的

@dawncold 我现在测试在本地多线程解压，但是因为都是小文件，每秒 io 次数很多，但是读写速度只能达到 10mb/s

要考虑磁盘的 IOPS 吧..小文件多线程并发解压应该算个低队列深度 IO.你先确认下 IOPS 到达你的 SSD 瓶颈没有.而不是看读写速度

为啥要 mapreduce.～

@dhairoot 完全不一样。hdfs 的 io 成本很高。解压效率应该不是瓶颈。。纯粹是你小文件 open() 的瓶颈。

处理 zip 里面的数据可以用 mr，但是就解压 zip，为什么要和 mr 扯上关系呢