2

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

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

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

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

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

谢谢，

亚历克斯

4

2 回答 2

5

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

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

于 2011-03-08T15:09:20.343 回答
2

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

于 2011-03-08T15:51:24.427 回答