Hadoop Word Count降序实现：需修改Mapper还是Reducer类？

嘿，这个需求我之前折腾过，给你说清楚怎么改：

首先拍板：核心修改全在Reducer类这边，Mapper类几乎不需要碰（除非你有特殊的预处理需求，但常规场景下完全不用动原来的Mapper逻辑）。

为啥不碰Mapper？ #

Mapper的本职工作就是把输入数据拆成<单词, 1>这种键值对，排序是MapReduce框架在Shuffle阶段干的活，在Mapper里硬加排序逻辑既不符合分工，还会平白增加节点的计算负担，纯纯没必要。

Reducer的两种修改思路 #

思路一：双Job实现（推荐，大数据量友好） #

这种方式是用两个MapReduce job配合，让框架帮我们完成排序，效率更高：

1. 第一个Job：标准Word Count
   完全用常规的Word Count逻辑就行，Mapper输出<Text, LongWritable>（单词，1），Reducer计算总词频后输出<Text, LongWritable>（单词，最终词频）。
2. 第二个Job：专门做降序排序
   • Mapper：读取第一个Job的输出，把键值对反转，输出<LongWritable, Text>（词频，单词）。
   • Reducer：接收反转后的键值对，输出的时候再换回来，也就是<Text, LongWritable>（单词，词频）。
   • 关键操作：自定义一个排序比较器，让Hadoop按词频（LongWritable类型的Key）降序排列。具体就是写一个类继承WritableComparator，重写compare()方法，让两个LongWritable按倒序比。然后在Job配置里加上job.setSortComparatorClass(DescendingLongComparator.class)。

思路二：单Job内部排序（小数据量首选，实现简单） #

如果数据量不大，不想写两个Job，可以在Reducer内部把所有结果收集起来再排序：

1. Mapper完全不动：还是输出<单词, 1>。
2. 改造Reducer类：
   • 先定义一个倒序的TreeMap：private TreeMap<Long, List<String>> countToWords = new TreeMap<>(Collections.reverseOrder());，用来存“词频-对应单词列表”的映射。
   • 在reduce()方法里，计算完每个单词的总词频后，把单词加到对应词频的列表里。
   • 重写cleanup()方法（这个方法会在所有reduce任务跑完后执行）：遍历这个TreeMap，按词频从高到低输出每个单词和对应的计数就行。
   • 注意：这种方式要把所有结果加载到Reducer的内存里，数据量大的话容易爆内存，所以只适合小数据集。

最后再划重点 #

• 原Word Count的Mapper类不需要修改（双Job的第二个Job的Mapper是新增的，不是改原来的）。
• 所有排序相关的修改都集中在**Reducer类（或第二个Job的组件）**里，选哪种方案看你的数据量就行。

内容的提问来源于stack exchange，提问作者Kumar Sourabh