如何在 Hadoop 程序中处理大量映射器的键？答案

【问题标题】：How to handle great number of mapper's key in a Hadoop program?如何在 Hadoop 程序中处理大量映射器的键？
【发布时间】：2013-10-30 22:23:55
【问题描述】：

我的 Hadoop 程序的映射阶段会生成大量唯一键（一个数据集大约 200K 键，另一个数据集大约 900K）。每个键都是一个包含 60 个数字字符的字符串值。我的 Hadoop 程序的排序/改组阶段花费的时间太长。对于如此多的键，有什么方法可以使排序/改组阶段更有效吗？

【问题讨论】：

您是否真的在为您的密钥使用String 值？您是否考虑过使用实现Comparable<BinaryComparable> 的数字类型？
是的，我使用 Text 作为映射器的键类型。我可以将其更改为 IntWritable，在这种情况下是否需要实现 Comparable？我相信 IntWritable 会进行字节级别的比较，对吗？
你不需要实现Comparable，如果你能把key改成更“紧凑”的类型就可以了，考虑VIntWritable或者VLongWritable，两者都节省内存在整数上分配空间。
@Diego Jimeno 根据这个 JavaDoc，键应该是 WritableComparable，它扩展了 Comparable。必须对键进行比较才能进行排序。我建议BinaryComparable，因为 Hadoop 文档指出比较二进制值通常比文本值快。 hadoop.apache.org/docs/current/api/org/apache/hadoop/io/…

标签： hadoop mapreduce

【解决方案1】：

您应该考虑使用组合器来减少网络的过热，组合发送到减速器的“映射阶段”输出。

关于 WritableComparator，你是对的，最好实现你的，因为据我所知，在排序阶段比较两个对象的方式是，一旦序列化对象（从映射器输出），Hadoop 以便give and order，必须反序列化它们，所以最好避免“反序列化阶段”并在字节级别进行比较。

在从WritableComparable 覆盖方法compare 时必须小心，因为要正确执行它可能非常具有挑战性，我指的是GrepCode 中的方法：

http://grepcode.com/file/repository.cloudera.com/content/repositories/releases/com.cloudera.hadoop/hadoop-core/0.20.2-737/org/apache/hadoop/io/WritableComparator.java#WritableComparator.compare%28byte%5B%5D%2Cint%2Cint%2Cbyte%5B%5D%2Cint%2Cint%29

编辑

我添加了一篇我认为很棒的文章，以对提高 MapReduce 的性能提出一些建议：

http://blog.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/

【讨论】：

当有很多唯一键并且组很小时，组合器没有多大帮助。
是否将键从 Text 更改为其他数据类型，如 IntWritable 帮助？

【解决方案2】：

您可能应该创建一个自定义键类型。这有几个原因：

通过使用数字（二进制）键，您可以实现Comparable<BinaryComparable>，它比较字节而不是文本，从而提高速度
您可以将密钥以二进制格式写入，这样可以节省传输和读取密钥的时间。如果我们要编写一个密钥类，我们可以扩展 BytesWritable，它已经实现了我在第一个项目符号中提到的接口。

您可能应该调整一些作业参数。例如，您可能需要考虑在您的工作中调整 io.sort 选项。因为你有很多独特的值，Hadoop 可能无法在内存中对它们进行排序，这意味着它必须溢出到磁盘。发生这种情况时，必须重新读取数据并重新排序，从而减慢 shuffle。您可以通过查看日志来判断是否发生了溢出，因为溢出已被记录。调优技巧见http://www.slideshare.net/cloudera/mr-perf

【讨论】：