最后的减速器任务需要很长时间才能完成

Question

我有一个群集设置，它有8个节点，我正在使用mapreduce解析一个20GB的文本文件。通常，我的目的是通过mapper获取每一行，并使用一个键发送，该键是输入文件行上的一列。当reducer得到它时，它将根据键值写入不同的目录。如果我举个例子： 输入文件：

test;1234;A;24;49;100

test2;222;B;29;22;22

test2;0099;C;29;22;22

所以这些行将写成：

/output/A-r-0001

/output/B-r-0001

/output/C-r-0001

我在reducer中使用MultipleOutputs对象，如果我使用一个小文件，一切正常。但是当我使用20GB文件时，152个映射器和8个reducer正在初始化。在mapper端，一切都很快完成，但一个减速器继续保持。减速器中的7个完成最多18分钟，但最后一个需要3个小时。 首先，我怀疑减速器的输入比其他减速器大，但实际情况并非如此。一个减速器的输入量比慢速减速器高三倍，并且在17分钟内完成。

我还尝试将减速器的数量增加到14，但这是由于减速任务减少了2次。

我查了很多文档，无法理解为什么会这样。你能帮助我吗？

EDITED

问题是由于我的数据集中存在一些损坏的数据。我在mapper端对输入数据进行了一些严格的检查，现在工作正常。

谢谢你们。

Answer 1

我已经看到在处理偏斜数据时经常会发生这种情况，所以我最好的猜测是你的数据集是偏斜的，这意味着你的Mapper会发出大量的记录，其中相同的密钥会发送到同一个密钥因为它有很多值需要重载的减速器。

对此没有简单的解决方案，这实际上取决于您工作的业务逻辑，您可以检查Reducer并说明如果您有N个以上的值忽略N之后的所有值。

我还发现了一些关于SkewReduce的文档，它可以让我更容易管理Hadoop环境中的偏斜数据，如in their paper所述，但我自己没有尝试过。

Answer 2

感谢您的解释。我知道我的数据集没有均匀分布的键值对。以下是我使用了14个减速器和152个映射器的测试之一。

任务完成17分27秒：

FileSystemCounters

FILE_BYTES_READ 10,023,450,978

FILE_BYTES_WRITTEN 10,023,501,262

HDFS_BYTES_WRITTEN 6,771,300,416

Map-Reduce Framework

减少输入组5

合并输出记录0

减少随机字节6,927,570,032

减少输出记录0

溢出记录28,749,620

合并输入记录0

减少输入记录19,936,319

任务完成14小时17分54秒：

FileSystemCounters

FILE_BYTES_READ 2,880,550,534

FILE_BYTES_WRITTEN 2,880,600,816

HDFS_BYTES_WRITTEN 2,806,219,222

Map-Reduce Framework

减少输入组5

合并输出记录0

减少随机字节2,870,910,074

减少输出记录0

溢出记录8,259,030

合并输入记录0

减少输入记录8,259,030

花费这么多时间的记录要记录的记录较少。

除此之外，一段时间后，相同的任务正在从不同的节点初始化。我猜hadoop认为任务很慢并初始化另一个。但它根本没有帮助。

Answer 3

这是来自慢速减速器和快速减速器的计数器

task_201403261540_0006_r_000019运行速度非常慢，task_201403261540_0006_r_000000运行速度非常快

很明显，我的一个减速器正在获得大量的钥匙。 我们需要优化自定义分区程序