Hadoop较小的输入文件

Question

我以不同的方式使用hadoop。就我而言，输入大小非常小。但是，计算时间更长。我有一些复杂的算法，我将在每一行输入上运行。因此，即使输入大小小于5mb，总计算时间也会超过10小时。所以我在这里使用hadoop。我使用NLineInputFormat按行数而不是块大小拆分文件。在我的初始测试中，我有大约1500行（拆分200行），我发现在四节点集群中，与在一台机器上串行运行相比，只有1.5倍的改进。我正在使用VM。这可能是问题还是对于较小尺寸的输入而言，hadoop不会带来多大好处？任何见解都会非常有用。

Answer 1

对我而言，您的工作量类似于SETI @ Home工作负载 - 小型有效负载，但需要数小时的运算时间。

Hadoop（或更具体地说是HDFS）不是为许多小文件设计的。但我怀疑这是MapReduce的一个问题 - 您正在使用的处理框架。

如果您想将工作量保持在一起： 1）如果文件小于块大小，则将它们分成单个文件（一个工作负载，一个文件），然后它将转到一个映射器。典型的块大小为64MB或128MB

2）为FileInputFormat创建一个包装器，并将'isSplitable（）'方法覆盖为false。这将确保整个文件内容被送到一个映射器，而不是hadoop尝试逐行拆分

参考：http://hadoopilluminated.com/hadoop_book/HDFS_Intro.html

Answer 2

Hadoop并不擅长处理大量小文件，因此，通常需要将大量较小的输入文件合并到较少数量的较大文件中，以减少映射器的数量。

由于InputFormat抽象了Hadoop MapReduce进程的输入。 FileInputFormat是一个处理HDFS文件的默认实现。使用FileInputFormat时，每个文件会被分成一个或多个InputSplits，通常由block size限制。这意味着输入分割的数量受输入文件数量的限制。当MapReduce进程处理大量小文件时，这不是一个理想的环境，因为协调分布式进程的开销远远大于存在相对大量小文件时的开销。

驱动吐痰大小的基本参数是mapred.max.split.size。

使用CombineFileInputFormat和此参数，我们可以控制映射器的数量。

查看我对另一个答案的实施here。