hadoop - 如何在 hadoop 中处理不可分割的 500 MB+ 输入文件？

Question

我正在编写一个 hadoop MapReduce 作业，它运行在一个完整的 Debian 镜像(≈ 40 GB)的所有源代码文件上。由于Debian镜像数据在单独的机器上，不在hadoop集群中，所以第一步是下载数据。

我的第一个实现下载一个文件并输出 key=$debian_package, value=$file_contents。然后应将每个键的各种值(通常为 4 个)减少为一个条目。下一个 MapReduce 作业将作为键对 debian 包进行操作，并将其所有文件作为值进行操作。

但是，我注意到 hadoop 的输出值有时非常大(700 MB 是我见过的最大输出值)，但效果很差。在 MapReduce 框架的各个地方，整个文件都存储在内存中，有时是两倍甚至三倍。我经常遇到内存不足的错误，即使 Java 堆大小为 6 GB。

现在我想知道如何拆分数据以使其更好地匹配 hadoop 的 64 MB block 大小。

我不能简单地将大文件分成多个部分，因为它们是压缩的(tar/bz2、tar/xz、tar/gz，也许将来会是其他文件)。在我对它们进行 dpkg-source 提取整个包之前(必要!)，文件需要保持完整大小。

我想到的一个想法是在第一个 MapReduce 中将文件存储在 hdfs 上，只将它们的路径传递给第二个 MapReduce。但是，我正在规避 hadoop 对数据局部性的支持，或者有没有办法解决这个问题？

是否还有我遗漏的其他技术？你有什么建议？

Answer 1

你是对的。这不是 Hadoop 内部的好案例。大量复制...有两个明显的解决方案，假设您不能在某处解压它:

1. 使用允许您递归读取压缩文件和存档文件的多个库中的任何一个来分解 tarball(apache VFS 对此的能力有限，但 apache 压缩库具有更多能力)。
2. nfs 将一堆数据节点本地空间挂载到您的主节点，然后获取并解压缩到该目录结构中...然后使用 forqlift 或类似实用程序将小文件加载到 HDFS。

另一种选择是编写一个实用程序来执行此操作。我已经为客户做了这个。 Apache VFS 和压缩、truezip，然后是要编写的 hadoop 库(因为我做了一个通用实用程序，所以我使用了很多其他库，但这是基本流程)。