Hadoop 用于处理非常大的二进制文件

Question

我有一个我希望分发的系统，我希望在其中以分布式方式处理许多非常大的不可分割的二进制文件。这些是几百 Gb 的数量级。由于各种固定的、特定于实现的原因，这些文件不能并行处理，而必须由同一进程按顺序处理直到结束。

该应用程序是用 C++ 开发的，所以我会考虑使用 Hadoop 管道将数据流进出。每个实例都需要按顺序处理 100Gb 到 200Gb 的自身数据（当前存储在一个文件中），并且应用程序当前（可能）受到 IO 限制，因此每个作业都完全在本地运行非常重要。

我非常热衷于 HDFS 来托管这些数据 - 自动维护冗余副本和在添加新节点时重新平衡的能力将非常有用。我也热衷于 map reduce，因为它计算简单，并且要求尽可能靠近数据托管计算。但是，我想知道 Hadoop 是否适合这个特定的应用程序。

我知道，为了表示我的数据，可以生成不可拆分的文件，或者生成巨大的序列文件（在我的情况下，单个文件的大小约为 10Tb - 我应该打包所有文件吗？我的数据合二为一）。因此 可能 使用 Hadoop 处理我的数据。但是，我的模型似乎不太适合 Hadoop：社区是否同意？或者有建议以最佳方式布置这些数据？甚至对于可能更适合该模型的其他集群计算系统？

这个问题可能与 hadoop 上的现有问题重复，但除了我的系统需要每个单个文件一个数量级或两个以上的数据（以前我看到过关于几个 Gb 的单个文件的问题在尺寸方面）。因此，如果之前已经回答过这个问题，请原谅我 - 即使对于这种大小的数据。

谢谢，

亚历克斯

Answer 1

您似乎处理的大文件数量相对较少。由于您的文件很大且不可拆分，Hadoop 将难以在集群中有效地调度和分发作业。我认为您在一个批次中处理的文件越多（比如数百个），使用 Hadoop 的价值就越大。

由于您只处理几个文件，您是否尝试过更简单的分发机制，例如使用 ssh 或 GNU Parallel 在多台机器上启动进程？使用这种方法完成简单的任务，我取得了很大的成功。在所有节点上使用 NFS 安装驱动器可以共享限制您必须执行的复制量。

Answer 2

您可以为您的文件编写一个自定义 InputSplit，但正如 bajafresh4life 所说，这并不理想，因为除非您的 HDFS 块大小与您的文件大小相同，否则您的文件将四处散布并且会有网络开销。或者，如果您确实使您的 HDFS 大小与您的文件大小相匹配，那么您将无法从集群的所有磁盘中受益。底线是 Hadoop 可能不是最适合您的工具。