在Map任务源码分析（上）中，对MAP阶段的代码进行了学习，这篇文章文章将学习Map任务的SORT阶段。假设Reducer的数量不为0。则还须要进行SORT阶段。但从上面的学习中并未发现与MAP阶段运行完毕调用mapPhase.complete()相似的在SORT阶段运行完毕调用sortPhase.complete()的源码，那SORT阶段是在什么时候启动的？对于Map任务来说，有输入就有输出。输入由RecordReader负责。输出则由RecordWriter负责，当Reducer的数量不为0时，RecordWriter为NewOutputCollector（该类为MapTask的私有内部类），SORT阶段对map的输出进行处理，由此判断SORT阶段的工作是由NewOutputCollector完毕的。以下将通过分析NewOutputCollector的源码要验证这一判断是否成立。该类继承自RecordWriter。拥有的变量例如以下：
private final MapOutputCollector<K,V> collector;//负责实际的输出操作 private final org.apache.hadoop.mapreduce.Partitioner<K,V> partitioner;//对键空间进行分区 private final int partitions;//分区数量。与Reducer的数量同样该类的构造函数例如以下：
collector = createSortingCollector(job, reporter);
partitions = jobContext.getNumReduceTasks();
if (partitions > 1) {
partitioner = (org.apache.hadoop.mapreduce.Partitioner<K,V>)
ReflectionUtils.newInstance(jobContext.getPartitionerClass(), job);
} else {
partitioner = new org.apache.hadoop.mapreduce.Partitioner<K,V>() {
@Override
public int getPartition(K key, V value, int numPartitions) {
return partitions - 1;
}
};
}
在该段代码中还是未发现与SORT阶段有关的不论什么信息，但却发现了Sorting，据此判断方法createSortingCollector具有最大的可能性。该方法的源码例如以下：
//依据mapreduce.job.map.output.collector.class的值构建MapOutputCollector
//在未指定该參数值的情况，返回MapOutputBuffer对象
MapOutputCollector<KEY, VALUE> collector= (MapOutputCollector<KEY, VALUE>)
ReflectionUtils.newInstance.
(job.getClass(JobContext.MAP_OUTPUT_COLLECTOR_CLASS_ATTR,
MapOutputBuffer.class, MapOutputCollector.class), job);
LOG.info("Map output collector class = " + collector.getClass().getName());
MapOutputCollector.Context context =new MapOutputCollector.Context(this, job, reporter);
//默认调用MapOutputBuffer的init方法
collector.init(context);
return collector;
经过上面的一系列分析可知，SORT阶段的工作由NewOutputCollector完毕，而NewOutputCollector又将SORT工作交给了MapOutputCollector。终于由该接口的实现类MapOutputBuffer完毕，该类做为MapTask的内部类占用了MapTask源码中超过一半的行数（MapTask行数为2000行，MapOutputBuffer约为1100行）。但从行数就能够得出该类的重要性。
MapOutputBuffer的init方法的第一部分代码依据设置构建缓存，代码已经加入了相关凝视：
//sanity checks
//当kvbuffer缓存达到该值时，溢出线程将缓存内容写入硬盘
final float spillper =job.getFloat(JobContext.MAP_SORT_SPILL_PERCENT, (float)0.8);
//用于排序文件的缓存的大小，默觉得100MB
final int sortmb = job.getInt(JobContext.IO_SORT_MB, 100);
//mapreduce.task.index.cache.limit.bytes，默认值为1024 * 1024(1M)
indexCacheMemoryLimit = job.getInt(JobContext.INDEX_CACHE_MEMORY_LIMIT, INDEX_CACHE_MEMORY_LIMIT_DEFAULT);
if (spillper > (float)1.0 || spillper <= (float)0.0) {
throw new IOException("Invalid \"" + JobContext.MAP_SORT_SPILL_PERCENT +
"\": " + spillper);
}
//sortmb的最大值为2047Mb(111 1111 1111)，取sortmb的最低11位
//若大于2047Mb，以下的左移20位将导致溢出
if ((sortmb & 0x7FF) != sortmb) {
throw new IOException("Invalid \"" + JobContext.IO_SORT_MB + "\": " + sortmb);
}
//默认使用高速排序
sorter = ReflectionUtils.newInstance(job.getClass("map.sort.class",
QuickSort.class, IndexedSorter.class), job);
// buffers and accounting
//sortbm*(2的20次方)。将sortbm转换为字节数(1024*1024,2的十次方乘以2的十次方)
int maxMemUsage = sortmb << 20;
//METASIZE=16,maxMemUsage=sortmb << 20
maxMemUsage -= maxMemUsage % METASIZE;
kvbuffer = new byte[maxMemUsage];
bufvoid = kvbuffer.length;
kvmeta = ByteBuffer.wrap(kvbuffer).order(ByteOrder.nativeOrder()).asIntBuffer();
setEquator(0);
//equator:标记元数据或者序列化数据的起源
//bufstart:标记溢出的起始位置，bufend:标记可收集收据的起始位置
//bufindex:标记已收集数据的结束位置。所有初始化为0 bufstart = bufend = bufindex = equator; //kvstart:标记溢出元数据的起源，kvend:标记溢出元数据的结束位置 //kvindex:标记全然序列化的记录的结束位置 kvstart = kvend = kvindex; maxRec = kvmeta.capacity() / NMETA; softLimit = (int)(kvbuffer.length * spillper); bufferRemaining = softLimit;
MapOutputBuffer的init方法的第二部分启动SpillThread线程，该线程用于完毕SORT阶段的工作，并负责溢出缓存中的数据。
在该线程中的run方法中调用了sortAndSpill方法，由方法名就能够得知该方法负责map输出的排序和溢出工作。排序部分的源码例如以下：
final int mstart = kvend / NMETA;
// kvend is a valid record
final int mend = 1 + (kvstart >= kvend? kvstart
: kvmeta.capacity() + kvstart) / NMETA;
//对指定范围的数据进行排序。默认使用的QuickSort
sorter.sort(MapOutputBuffer.this, mstart, mend, reporter);
对数据排完序后就须要将已排序数据写出到文件里。源码例如以下：
int spindex = mstart;
//记录索引的startOffset、rawLength和partLength
final IndexRecord rec = new IndexRecord();
//封装value的字节表示的内部类
final InMemValBytes value = new InMemValBytes();
for (int i = 0; i < partitions; ++i) {
//负责将map的输出写入中间文件
IFile.Writer<K, V> writer = null;
try {
long segmentStart = out.getPos();
writer = new Writer<K, V>(job, out, keyClass, valClass, codec,spilledRecordsCounter);
if (combinerRunner == null) {
// spill directly
DataInputBuffer key = new DataInputBuffer();
while (spindex < mend &&
kvmeta.get(offsetFor(spindex % maxRec) + PARTITION) == i) {
final int kvoff = offsetFor(spindex % maxRec);
int keystart = kvmeta.get(kvoff + KEYSTART);
int valstart = kvmeta.get(kvoff + VALSTART);
key.reset(kvbuffer, keystart, valstart - keystart);
getVBytesForOffset(kvoff, value);
writer.append(key, value);
++spindex;
}
} else {
int spstart = spindex;
while (spindex < mend
&&kvmeta.get(offsetFor(spindex % maxRec)+ PARTITION) == i) {
++spindex;
}
// Note: we would like to avoid the combiner if we've fewer
// than some threshold of records for a partition
if (spstart != spindex) {
combineCollector.setWriter(writer);
RawKeyValueIterator kvIter =new MRResultIterator(spstart, spindex);
combinerRunner.combine(kvIter, combineCollector);
}
}
// close the writer
writer.close();
// record offsets
rec.startOffset = segmentStart;
rec.rawLength = writer.getRawLength();
rec.partLength = writer.getCompressedLength();
spillRec.putIndex(rec, i);
writer = null;
} finally {
if (null != writer) writer.close();
}
}
当保存索引的缓存超过限制时，就将索引保存到文件里，源码例如以下：
if (totalIndexCacheMemory >= indexCacheMemoryLimit) {
// create spill index file
//MAP_OUTPUT_INDEX_RECORD_LENGTH值为24，表示索引文件里每条记录的大小
Path indexFilename =mapOutputFile.getSpillIndexFileForWrite(numSpills, partitions
* MAP_OUTPUT_INDEX_RECORD_LENGTH);
spillRec.writeToFile(indexFilename, job);
} else {
indexCacheList.add(spillRec);
totalIndexCacheMemory +=spillRec.size() * MAP_OUTPUT_INDEX_RECORD_LENGTH;
}
综合上面的分析可知，当在map方法中运行context.write时，将先数据写入到缓存中，当缓存中的数据达到预先设置的阈值时由后台SpillThread线程负责数据排序并将数据溢出到map任务的中间输出文件里。
