Hadoop源码分析(MapTask辅助类,II)

Posted gcczhongduan

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop源码分析(MapTask辅助类,II)相关的知识,希望对你有一定的参考价值。

有了上面Mapper输出的内存存储结构和硬盘存储结构讨论,我们来细致分析MapOutputBuffer的流程。首先是成员变量。最先初始化的是作业配置job和统计功能reporter。通过配置,MapOutputBuffer能够获取本地文件系统(localFs和rfs),Reducer的数目和Partitioner。
SpillRecord是文件spill.out{spill号}.index在内存中的相应抽象(内存数据和文件数据就差最后的校验和),该文件保持了一系列的IndexRecord,例如以下图:

技术分享 
IndexRecord有3个字段,各自是startOffset:记录偏移量。rawLength:初始长度,partLength:实际长度(可能有压缩)。

SpillRecord保持了一系列的IndexRecord,并提供方法用于加入记录(没有删除记录的操作,由于不须要)。获取记录,写文件,读文件(通过构造函数)。
接下来是一些和输出缓存区kvbuffer。缓存区记录索引kvindices和缓存区记录索引排序工作数组kvoffsets相关的处理,以下的图有助于说明这段代码。



技术分享 

这部分依赖于3个配置參数,io.sort.spill.percent是kvbuffer,kvindices和kvoffsets的总大小(以M为单位。缺省是100,就是100M,这一部分是MapOutputBuffer中占用存储最多的)。

io.sort.record.percent是kvindices和kvoffsets占用的空间比例(缺省是0.05)。

前面的分析我们已经知道kvindices和kvoffsets,假设记录数是N的话,它占用的空间是4N*4bytes,依据这个关系和io.sort.record.percent的值。我们能够计算出kvindices和kvoffsets最多能有多少个记录。并分配相应的空间。參数io.sort.spill.percent指示当输出缓冲区或kvindices和kvoffsets记录数量到达相应的占用率的时候。会启动spill,将内存缓冲区的记录存放到硬盘上。softBufferLimit和softRecordLimit为相应的字节数。


值对<key, value>输出到缓冲区是通过Serializer串行化的。这部分的初始化跟在上面输出缓存后面。接下来是一些计数器和可能的数据压缩处理器的初始化,可能的Combiner和combiner工作的一些配置。
最后是启动spillThread。该Thread会检查内存中的输出缓存区。在满足一定条件的时候将缓冲区中的内容spill到硬盘上。这是一个标准的生产者-消费者模型,MapTask的collect方法是生产者,spillThread是消费者,它们之间同步是通过spillLock(ReentrantLock)和spillLock上的两个条件变量(spillDone和spillReady)完毕的。


先看生产者。MapOutputBuffer.collect的主要流程是:
l           报告进度和參数检測(<K,V>符合Mapper的输出约定);
l           spillLock.lock(),进入临界区。
l           假设达到spill条件。设置变量并通过spillReady.signal(),通知spillThread;并等待spill结束(通过spillDone.await()等待);
l           spillLock.unlock();
l           输出key,value并更新kvindices和kvoffsets(注意,方法collect是synchronized,key和value各自输出。它们也会占用连续的输出缓冲区)。
kvstart,kvend和kvindex三个变量在推断是否须要spill和spill是否结束的过程中非常重要。kvstart是有效记录開始的下标。kvindex是下一个可做记录的位置。kvend的作用比較特殊,它在普通情况下kvstart==kvend。但開始spill的时候它会被赋值为kvindex的值,spill结束时。它的值会被赋给kvstart,这时候kvstart==kvend。

这就是说。假设kvstart不等于kvend,系统正在spill,否则。kvstart==kvend。系统处于普通工作状态。

事实上在代码中。我们能够看到非常多kvstart==kvend的推断。


以下我们分情况,讨论kvstart,kvend和kvindex的配合。初始化的时候。它们都被赋值0。

技术分享 

下图给出了一个没有spill的记录加入过程:

技术分享 

注意kvindex和kvnext的关系,取模实现了循环缓冲区
假设在加入记录的过程中,出现spill(多种条件),那么,基本的步骤例如以下:

技术分享 

首先还是计算kvnext。主要,这个时候kvend==kvstart(图中没有画出来)。

假设spill条件满足,那么,kvindex的值会赋给kvend(这是kvend不等于kvstart),从kvstart和kvend的大小关系,我们能够知道记录位于数组的那一部分(左边是kvstart<kvend的情况,右边是另外的情况)。Spill结束的时候,kvend值会被赋给kvstart,kvend==kvstart又又一次满足。同一时候。我们能够发现kvindex在这个过程中没有变化。新的记录还是写在kvindex指向的位置,然后,kvindex=kvnect,kvindex移到下一个可用位置。
大家体会一下上面的过程,特别是kvstart,kvend和kvindex的配合,事实上,<key。value>对输出使用的缓冲区,也有类似的过程。

Collect在处理<key。value>输出时。会处理一个MapBufferTooSmallException,这是value的串行化结果太大。不能一次放入缓冲区的指示,这样的情况下我们须要调用spillSingleRecord,特殊处理。

很多其它精彩内容请关注:http://bbs.superwu.cn 

关注超人学院微信二维码:技术分享

关注超人学院java免费学习交流群:技术分享



































以上是关于Hadoop源码分析(MapTask辅助类,II)的主要内容,如果未能解决你的问题,请参考以下文章

java.lang.NullPointerException Ignoring exception during close for org.apache.hadoop.mapred.MapTask$

Hadoop文件切分的源码

九MapReduce--input源码分析

Hadoop基础(二十三):MapTask工作机制

Hadoop源码篇---解读Mapprer源码outPut输出

大数据之Hadoop(MapReduce):切片与MapTask并行度决定机制