我使用hadoop的方式有点不同。在我的例子中，输入大小非常小。然而，计算时间更多。我有一些复杂的算法我会在每一行输入上运行。因此，即使输入大小小于5mb，总体计算时间也超过10小时。这里我用的是hadoop。我使用NLineInputFormat按行数而不是块大小分割文件。在我最初的测试中，我有大约1500行代码(每200行代码分开)，与在一台机器上连续运行相比，我发现在一个四节点集群中只提高了1.5倍。我用的是VM。这可能是问题所在，或者对于较小的输入，hadoop不会有太多好处?任何见解都会很有帮助的。
对我来说，您的工作负载类似于SETI@Home工作负载——小的有效负载，但是几个小时的处理时间。
Hadoop(或者更具体地说HDFS)不是为大量小文件设计的。但我怀疑这对你正在使用的处理框架MapReduce来说是一个问题。
如果你想保持你的工作量在一起:1)将它们分割成单独的文件(一个工作负载，一个文件)，如果文件小于块大小，那么它将进入一个映射器。典型的块大小为64MB或128MB
2)为FileInputFormat创建一个包装器，并覆盖'isSplitable()'方法为false。这将确保整个文件内容被馈送到一个映射器，而不是hadoop试图逐行分割它
参考:http://hadoopilluminated.com/hadoop_book/HDFS_Intro.html
Hadoop并不擅长处理大量的小文件，因此，通常希望将大量较小的输入文件组合成较少数量的较大文件，以减少映射器的数量。
As Input to Hadoop MapReduce进程由InputFormat抽象。FileInputFormat是处理HDFS文件的默认实现。对于FileInputFormat，每个文件被分割成一个或多个InputSplits，通常以block size为上限。这意味着输入分割的数量受到输入文件数量的限制。当MapReduce进程处理大量小文件时，这不是一个理想的环境，因为协调分布式进程的开销远远大于处理相对大量的小文件时的开销。
驱动吐槽大小的基本参数是mapred.max.split.size。
使用CombineFileInputFormat和这个参数可以控制映射器的数量。
查看我在这里得到的另一个答案的实现