Hadoop较小的输入文件

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

来源

2013-03-10 CRS

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

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

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

2）为FileInputFormat创建包装，并将'isSplitable（）'方法重写为false。这将确保整个文件内容被送入一个映射，而不是Hadoop的努力逐行拆呢

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

来源

2013-03-11 02:59:11

感谢您的意见。逐行分割是否有缺点？总之，你的意思是我应该把输入文件分割成更小的文件。可以说我创建了8个文件，每个文件有n/8行。回答那么我应该做你上面提到的第二点？我不是通过这样做来理解这种优势，而是一条一条地分割它。在我的情况下，我把它分成（总行数/总节点）的形式。它并不是单线。 – CRS 2013-03-12 08:43:52

1）一个'记录'是否适合一行？如果是的话，让hadoop做分裂。如果你的'记录'跨越多行，那么你需要控制分裂。 2）如果你让hadoop做分裂，那么让你的输入不是在一个文件中，而是在多个文件中。这样，处理将在节点（更具体地为映射器）之间并行 - 无需您执行任何特殊工作希望这有助于 – 2013-03-13 15:17:20

-1

Hadoop是不是在处理万吨的小文件确实不错，因此，通常希望将大量较小的输入文件合并为较少数量的较大文件，从而减少映射器的数量。

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

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

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

检出我的另一个回答here。

来源

2013-03-11 19:22:26 Amar

谢谢Amar。但正如我所提到的，在我的情况下，我只有一个输入文件。即使这个尺寸非常小，小于5mb。但是，执行时间很长，这就是为什么我使用MapReduce在一组节点之间分配的原因。为了更清楚，我有4万行输入文件和4个节点集群。不是按块大小拆分文件，而是按行数进行。我把它作为10k。通过这样做，每个节点将获得10k条线路。但问题在于整体表现。与连续运行相比，我在4节点集群中只看到1.5倍的改进。 – CRS 2013-03-12 08:52:26

Hadoop较小的输入文件

回答

相关问题