问题背景
众所周知，Map-Reduce任务完成后，输出的结果文件总是按照Key进行升序排列（shuffle阶段完成）。
例如Hadoop里经典的word count程序：
// File1原始数据
hello
world
hello
apple
apple
apple
baby
// 输出结果文件，已按Key进行升序排序
apple 3
baby 1
hello 2
world 1
显然，这种默认的排序方式很多时候能帮开发者减轻负担，因为开发者不用去自行实现对Key进行排序的算法，所有的排序操作均由Hadoop帮开发者完成（详情参考Map-Reduce中的shuffle原理，具体参考map端的partition->spill->(spill.sort)->(combine)过程）。
一切似乎很美好，可是如果我们遇到了要对value排序的需求呢？
// 假设有如下电影评分数据 movies.dat
// 且我们希望对rating进行降序排序, 以便分析每部电影的评分趋势
MovieID, rating
001, 75.5
001, 89
001, 60
002, 55
002, 79
003, 92.5
003, 92.8
003, 60
......
// 期望输出值（Key有序的同时，按rating降序排序）
001 89.0
001 75.5
001 60.0
002 79.0
002 55.0
003 92.8
003 92.5
003 60.0
在“排序”的需求下，我们很自然地会想到：
- 利用系统默认的排序。
- 预处理数据，把rating当成Key，movieID当成Value。
虽然按照以上的想法，确实是对作为Key的rating排序了，但我们需要的是降序输出而非默认的升序输出，且输出格式不符合要求（第一列应为movieID）。
此时，就需要引入一种二次排序（Secondary Sort）的概念了。所谓二次排序（Secondary Sort）其实就是人工地对所需字段进行排序，在系统的默认排序基础上做第二次的排序。
解决方案
二次排序（Secondary Sort）概念上不难理解，无非就是自行多做一次特定的排序。可是该如何实现呢？怎么在map-reduce的流程框框内对Value进行人工排序呢？
其实关键技巧就是利用map-reduce会对Key排序的特点，让它“顺带”对Value进行排序。为了达到这种“顺带”的效果，我们可以将原始数据中的Key（MovieID）和Value（rating）合并到一起作为新的Key（MovieBean），同时仍然保持原Value（rating）作为Value。当系统对这个合并的Key（MovieBean）按照某种特性进行排序时，其对应的Value也会被相应地“排序”（因为map端输出时，Key和Value是一个整体数据结构），为此我们应设计一个自定义的Bean类。
/**
* 自定义的MovieBean类, 将原始数据中的Key和Value合并到一个类中。
*/
public class MovieBean implements WritableComparable<MovieBean>{
public Text movieID;
public DoubleWritable score;
public MovieBean() {
}
public MovieBean(Text movieID, DoubleWritable score) {
this.movieID = movieID;
this.score = score;
}
public void set(Text movieID, DoubleWritable score) {
this.movieID = movieID;
this.score = score;
}
public Text getMovieID() {
return movieID;
}
public void setMovieID(Text movieID) {
this.movieID = movieID;
}
public DoubleWritable getScore() {
return score;
}
public void setScore(DoubleWritable score) {
this.score = score;
}
@Override
public String toString() {
return "movieID=" + movieID +
", score=" + score;
}
/**
* 重点! 利用自定义的compareTo方法实现排序效果!
* @param o object of MovieBean
* @return result of comparison
*/
@Override
public int compareTo(MovieBean o) {
if(o == null) {
throw new RuntimeException();
}
// movieID相同时, 按照score进行降序排序
if(this.movieID.compareTo(o.getMovieID()) == 0) {
return -score.compareTo(o.getScore());
}
// movieID不相同时, 直接按照MovieID排序
return this.movieID.compareTo(o.getMovieID());
}
/**
* @param dataOutput 序列化输出
*/
@Override
public void write(DataOutput dataOutput) throws IOException {
dataOutput.writeUTF(movieID.toString());
dataOutput.writeDouble(score.get());
}
/**
* @param dataInput 序列化输入
*/
@Override
public void readFields(DataInput dataInput) throws IOException {
movieID = new Text(dataInput.readUTF());
score = new DoubleWritable(dataInput.readDouble());
}
}
有了这个自定义的MovieBean类作为新的Key后，Mapper端的输出就从原来的
<MovieID, Rating>键值对转换成了<MovieBean, Rating>键值对。
<MovieID, Rating> => <(MovieID, Rating), Rating>
那么Reducer端接收到的将是大量的<MovieBean, Rating>数据。此时问题就来了，当我们的Key是简单类型时（如IntWritable，Text，DoubleWritable），很自然就能将多个K-V对中相同的Key提取出来，且将多个Value合并成一个集合，构成Reducer端的输入数据结构<Key, List<Value>>。但是当我们的Key是复合类型，例如MovieBean是MovieID和Rating的复合结构时，即使两个MovieBean对象的MovieID相同，但这两个MovieBean却是不会被认为是同一个对象的。
// 1号K-V对
<("0001", 85.0), 85.0>
// 2号K-V对
<("0001", 68.0), 68.0>
// Reducer接收到以上两个K-V对后，并不会把它们合并成<MovieBean, List<Value>>的数据结构
// 因为两个K-V对的Key（MovieBean）并不相同
为了解决这个问题，让Reducer把相同MovieID的MovieBean当成是一样的Key，继而把相同MovieID所对应的Ratings合并成<MovieBean, List<Value>>结构，我们需要通过实现自定义的GroupingComparator来 欺骗 Reducer。
/**
* 自定义的GroupingComparator
*/
public class MovieGroupingComparator extends WritableComparator {
/**
* 构造函数, 告知自定义Bean类
*/
protected MovieGroupingComparator() {
super(MovieBean.class, true);
}
/**
* 重写WritableComparator接口的compare方法(类似于普通Comparator接口)
* @param a movieA
* @param b movieB
* @return result of comparison
*/
@Override
public int compare(WritableComparable a, WritableComparable b) {
MovieBean movieA = (MovieBean) a;
MovieBean movieB = (MovieBean) b;
// 只比较两个MovieBean的MovieID, 忽略其他属性
return movieA.getMovieID().compareTo(movieB.getMovieID());
}
}
实现以上的自定义GroupingComparator时，我们在compare方法中只考虑MovieID这一个属性，等同于欺骗了Reducer。Reducer判断两个Key是否相同时只考虑MovieID是否相同，从而将不同的MovieBean对象抽取成一个统一的MovieBean作为Reducer的输入Key，即可顺利合并出<MovieBean, List<Rating>>这样的数据结构。
// example
// 假设Reducer0接收到了以下K-V对
<("0001", 89.0), 89.0>
<("0001", 76.8), 76.8>
<("0001", 69.5), 69.5>
<("0001", 69.3), 69.3>
// 由于compare方法只比较MovieBean中的MovieID属性, 完全忽略Rating, 所以
// 以上4个K-V对中的MovieBean均会被视作一样的Key，最终合并成的数据结构如下
// (为什么是有序的, 因为在map端的spill过程中已经依照rating降序排列了,参考MovieBean
// 类中重写的compareTo方法)
< Key, List<Value>>
<("0001", 89.0), [89.0, 76.8, 69.5, 69.3]>
作业提交
至此，二次排序中所有自定义的工作已经完成。但是千万不要忘记在提交Job之前，给Job设置以上自定义GroupingComparator，否则Job会使用内置默认的GroupingComparator，那我们的二次排序就无法生效了。
movieJob.setGroupingComparatorClass(MovieGroupingComparator.class);
另外，如果需要自定义Reducer数量（例如有时希望输出N个结果文件，则需要N个Reducer），还要自定义Partitioner。Partitioner的作用简单来说就是给Mapper端产生的K-V对打上一个partition id烙印，让系统知道这个K-V对应该被哪个Reducer取走。在本例中，如有需要（不是必须），我们可以按照MovieID进行划分，不同MovieID的K-V对划分到不同的Reducer上进行处理。
/**
* 自定义Partitioner, 用于划分K-V对被哪个Reducer取走
*/
public class MoviePartitioner extends Partitioner<MovieBean, DoubleWritable> {
@Override
public int getPartition(MovieBean movieBean, DoubleWritable doubleWritable, int numReducers) {
// 相同MovieID的必定会到同一个Reducer上
return movieBean.getMovieID().hashCode() % numReducers;
}
}
最后给Job设定自定义的Reducer数，即可启动N个Reducer进行数据处理。
final int NUM_REDUCE_TASK = 5;
movieJob.setNumReduceTasks(NUM_REDUCE_TASK);
总结
使用SecondarySort可以使我们在Map-Reduce框架内完成自定义排序。依托Map-Reduce会对Key进行排序的特性，可以将需要排序的字段（Value）与原始Key合成为自定义的Bean作为新的Key，原Value保持不动。有了SecondarySort，我们就不必在框架外做额外的工作进行排序，干扰程序的可读性；也不必将原始Key和Value对换，影响输出格式。
