我使用hadoop的方式有点不同。在我的例子中，输入大小非常小。但是，计算时间更长。我有一些复杂的算法，我将运行在每一行的输入。因此，即使输入大小小于5mb，总体计算时间也超过10小时。所以我在这里使用hadoop。我使用nlineinputformat按行数而不是按块大小拆分文件。在我最初的测试中，我有大约1500行（被200行分割），我只看到四节点集群与在一台机器上串行运行集群相比只提高了1.5倍。我正在使用虚拟机。这是问题所在还是对于较小的输入，hadoop不会有太多好处？任何见解都会很有帮助。
2条答案
按热度按时间wqsoz72f1#
hadoop并不擅长处理大量的小文件，因此，通常需要将大量较小的输入文件组合成较少的较大文件，以减少Map器的数量。
作为hadoop的输入，mapreduce进程由
InputFormat.FileInputFormat是处理hdfs中文件的默认实现。与FileInputFormat，每个文件被拆分为一个或多个InputSplits通常上界为block size. 这意味着输入拆分的数量是由输入文件的数量下限决定的。当mapreduce进程处理大量的小文件时，这不是一个理想的环境，因为协调分布式进程的开销远远大于处理相对大量的小文件时的开销。驱动spit大小的基本参数是
mapred.max.split.size.使用
CombineFileInputFormat这个参数我们可以控制Map器的数量。在这里查看我的实现以获得另一个答案。
yebdmbv42#
对我来说，你的工作量seti@home 工作负荷——很小的有效负荷，但需要几个小时的工作时间。
hadoop（或者更具体地说hdfs）不是为很多小文件设计的。但我怀疑这对于您正在使用的处理框架mapreduce来说是个问题。
如果您想将工作负载放在一起：1）将它们拆分为单个文件（一个工作负载，一个文件），如果文件小于块大小，则它将转到一个Map器。典型的块大小是64mb或128mb
2） 为fileinputformat创建 Package ，并将“issplitable（）”方法重写为false。这将确保将整个文件内容提供给一个Map器，而不是hadoop试图将其逐行拆分
参考文献：http://hadoopilluminated.com/hadoop_book/hdfs_intro.html