Hadoop较小的输入文件答案

【问题标题】：Hadoop smaller input fileHadoop较小的输入文件
【发布时间】：2013-03-10 23:20:13
【问题描述】：

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

【问题讨论】：

标签： hadoop mapreduce

【解决方案1】：

对我来说，您的工作量类似于 SETI@Home 的工作量 - 负载量小，但需要数小时的工作时间。

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

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

2) 为 FileInputFormat 创建一个包装器，并将“isSplitable()”方法重写为 false。这将确保将整个文件内容提供给一个映射器，而不是 hadoop 试图逐行拆分它

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

【讨论】：

感谢您的意见。逐行拆分有什么缺点吗？总结一下，您的意思是我应该将输入文件拆分为较小的文件。假设我创建了 8 个文件，每个文件都有 n/8 行。 Ans 那么我应该做你上面提到的第 2 点吗？我不理解这样做而不是逐行拆分的优势。就我而言，我以（总行数/总节点数）的形式将其拆分。它实际上不是单行。
1) 一个“记录”是否适合一行？如果是这样，那么让 hadoop 进行拆分。如果您的“记录”跨越多行，那么您将需要控制拆分。 2）如果您让hadoop进行拆分，那么您的输入不是在一个文件中，而是在多个文件中。这样，处理将在节点（更具体地说是映射器）之间并行化——无需您做任何特殊工作，希望这会有所帮助

【解决方案2】：

Hadoop 并不擅长处理大量的小文件，因此，通常希望将大量较小的输入文件组合成较少数量的较大文件，以减少映射器的数量。

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

驱动吐出尺寸的基本参数是mapred.max.split.size。

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

查看我的实现以获取另一个答案 here。

【讨论】：

谢谢阿马尔。但正如我所提到的，就我而言，我只有 1 个输入文件。即便如此，它的大小也非常非常小，不到 5mb。但是，执行时间很长，这就是我使用 MapReduce 在一组节点之间分配的原因。更清楚地说，我在输入文件中有 40k 行，在集群中有 4 个节点。我不是按块大小拆分文件，而是按行数。我给它10k。通过这样做，每个节点将获得 10k 行。但问题在于整体性能。与串行运行相比，我看到 4 节点集群的性能提高了 1.5 倍。