本文为了全面源码级剖析MapReduceshuffle过程,设置了Combiner并进行了剖析,对于没有设置Combiner的shuffle,只需要将Combiner部分忽略即可。
0、前言
shuffle是MapReduce的重要部分,横跨map与reduce两端,是指从Mapper函数输出到Reducer函数输入的这段过程,属于本地(节点内)聚合操作,实现逻辑与reducer相同。目的是为了将Mapper的输出更快更好地传到Reducer。由于Reduce的数量可能不止一个,因此 Mapper的输出需要均匀分到reducer函数中,所以采用HashCode分区,打乱Key的原始顺序,因此得名为shuffle(洗牌)。
在Hadoop这样的集群环境中,大部分map task与reduce task的执行是在不同的节点上。当然很多情况下Reduce执行时需要跨节点去拉取其它节点上的map task结果。如果集群正在运行的job有很多,那么task的正常执行对集群内部的网络资源消耗会很严重。这种网络消耗是正常的,我们不能限制,能做的就是最大化地减少不必要的消耗。还有在节点内,相比于内存,磁盘IO对job完成时间的影响也是可观的。从最基本的要求来说,我们对Shuffle过程的期望可以有:
1)完整地从map task端拉取数据到reduce 端。
2)在跨节点拉取数据时,尽可能地减少对带宽的不必要消耗(网络IO)。
3)减少磁盘IO对task执行的影响。
为了更好达到上面的目的,在业务逻辑满足交换律的条件下,可以设置Combiner优化网络IO和磁盘IO的消耗。
下面通过源码来剖析shuffle的过程,源码版本为Hadoop0.21.0,配图为:
1、Map端shuffle
1)详细Map端的shuffle过程图为
2)具体步骤:
(1)mapper的输出会利用缓冲的方式写到内存,进入一个环形缓冲区。在默认情况下,环形缓冲区大小为100M,这个值可以通过mapreduce. task.io.sort.mb属性来调整,一旦缓冲内容达到阈值(mapreduce. map.sort.spill.percent,默认为0.8),一个后台线程锁定这80MB的内存内容,开始把内容溢出(spill)到磁盘。执行溢写过程,Map task的输出结果还可以往剩下的20MB内存中写,互不影响,但是若20MB也被写满,且80MB没有溢写完毕,map就会被阻塞。
(2)在溢写到磁盘之前,线程首先根据Reduce数对数据的进行分区,然后对每个分区在内存中会执行快排(QiukSort)。排序之后,Combiner开始登场,源码为MapOutputBuffer.sortAndSpill():
for (int i = 0; i < partitions; ++i) {
//...
if (spstart != spindex) {
combineCollector.setWriter(writer);
RawKeyValueIterator kvIter = new MRResultIterator(spstart, spindex);
combinerRunner.combine(kvIter, combineCollector);//缓冲区之后溢写之前的Combiner
}
(3)每次溢写都执行一次Combiner,最后没有达到溢写条件进行flush也进行一次Combiner,Combiner之后生成一个溢出文件(spill file),Mapper完成之后就会形成若干个溢出文件。
(4)对溢出文件进行合并,配置属性mapreduce.task.io.sort.factor控制一次最多能合并多少流。默认为10,最后循环合并成一个已经分好区的map输出文件。在合并过程中,从源码可知若溢出文件大于等于3,会调用Combiner:
private void mergeParts() {
//...
if (numSpills == 1){
//更名,加后缀
}
if (numSpills == 0) {
//创建空文件
}
//当溢写文件数>1