Java 为什么我的一半是；字数“；Hadoop Reducer在AWS/EMR上运行时输出文件0字节？

我有一组数据，基本上是简单单词计数的映射结果（文本文件w/Word&Count对，制表符分隔），我需要减少它。大约有160 GB的数据，压缩成bz2文件

当我在Amazon Web Services Elastic Map Reduce（AWS EMR）上运行我的作业时，我使用10个cc2.8XL大型从属设备和一个m1.xlarge作为主设备。最终有1200个map任务和54个reduce任务。映射任务完成后，正好有一半的reduce任务立即完成，它们的输出都是0字节。我假设输入是0字节，但我还没有充分挖掘日志来确认。其他27个reduce任务最终完成，所有任务的文件大小都是一致的（每个任务2.3gb）。对于输出文件（part-r-00000，…，part-r-00053），偶数文件为0字节文件

当我在一个非常小的样本w/2减速机上本地运行这个时，每个减速机输出都有数据

我的mapper和reducer如下（Java w/extras去掉）：

/。。。
公共void映射（LongWritable键、文本val、上下文上下文）引发IOException、InterruptedException{
String[]parts=val.toString（）.split（“\t”）；
如果（零件长度>1）{
键出设置（部件[0]）；
valOut.set（Integer.parseInt（parts[1]）；
上下文。写入（键入输出、值输出）；
}
}
// ...
公共void reduce（文本键、Iterable值、上下文上下文）引发IOException、InterruptedException{
整数和=0；
for（可写入值：值）{
sum+=val.get（）；
}
结果集（总和）；
编写（键、结果）；
}
// ...

还有其他人经历过吗？知道为什么会发生这种情况，或者我如何进一步调试它吗？我已经打开了EMR调试，以防您对日志中的内容有所了解。谢谢

编辑：我应该注意，我正在S3上读取和存储数据

---

编辑2:我以前运行过一次相同的作业，看到了0字节的文件，并假设我的Reducer中有一个bug，所以取消了该作业。因此，我知道这不是一次性的活动。作业在同一群集上运行。我最初在Cloudera4（CDH4）库上编译Java类，这些库有“Hadoop 2.0”，所以我认为这可能是问题所在。当我第二次运行它时，我使用了使用Cloudera3（CDH3）库和Hadoop 0.20编译的Java类，基本上与AWS的版本相同。我过去也使用过CDH3来编译此行为。

使用的分区器是什么？我认为这就是实际将记录分配给缩减器/分区的原因。如果一些还原程序得到0个输入，那么我会考虑这种逻辑。这不是Hadoop版本的问题，这是哈希分区的自然行为。没有保证一个reducer会得到记录。分区负责这一点可能是对的。我想我只是很惊讶，有一半的减速机没有记录，而其他减速机都是没有数据的。我没有指定自己的分区器，因此默认的分区器必须是使用的分区器。最终的输出符合我的预期，因此我不认为每一次都有错误，但我的集群的潜在降低能力并没有得到充分利用。无论如何，这不是什么大问题，但只是想分享一下，以防其他人遇到类似的问题和/或出现“修复”。

// ...

public void map(LongWritable key, Text val, Context context) throws IOException, InterruptedException {
  String[] parts = val.toString().split("\t");
  if (parts.length > 1) {
    keyOut.set(parts[0]);
    valOut.set(Integer.parseInt(parts[1]));
    context.write(keyOut, valOut);
  }
}

// ...

public void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException {
  int sum = 0;
  for (IntWritable val : values) {
    sum += val.get();
  }
  result.set(sum);
  context.write(key, result);
}

// ...