MapReduce之mapOutputBuffer解析

来源：互联网发布：网络信息发布十不准编辑：程序博客网时间：2024/05/16 01:10

转载地址：http://blog.csdn.net/wangqinghuan1993/article/details/53785403

MapOutPutBuffer就是map任务暂存记录的内存缓冲区。不过这个缓冲区是有限的，当写入的数据超过缓冲区设定的阈值时，需要将缓冲区的数据写入到磁盘，这个过程叫spill。在溢出数据到磁盘的时候，会按照key进行排序，保证刷新到磁盘的记录时排好序的。该缓冲区的设计非常有意思，它做到了将数据的meta data(索引)和raw data(原始数据)一起存放到了该缓冲区中，并且，在spill的过程中，仍然能够往该缓冲区中写入数据，我们在下面会详细分析该缓冲区是怎么实现这些功能的。

缓冲区分析

MapoutPutBuffer是一个环形缓冲区，每个输入的key->value键值对以及其索引信息都会写入到该缓冲区，当缓冲区块满的时候，有一个后台的守护线程会负责对数据排序，将其写入到磁盘。

核心成员变量

1、 kvbuffer :字节数组，数据和数据的索引都会存在该数组中

2、 kvmeta：只是kvbuffer中索引存储部分的一个视角，为什么这么说？因为索引往往是按整型存储（4个字节），所以使用kvmeta来重新组织该部分的字节（kvmeta中的一个单元相当于4个字节，但是kvmeta并没有重新开辟内存，其指向的还是kvbuffer）

3、 equator:缓冲区的分割线，用来分割数据和数据的索引信息。

4、 kvindex:下次要插入的索引的位置

5、 kvstart:溢出时索引的起始位置

6、 kvend:溢出时索引的结束位置

7、 bufindex:下次要写入的raw数据的位置

8、 bufstart:溢出时raw数据的起始位置

9、 bufend:溢出时raw数据的结束位置

10、spiller:当数据占用超过这个比例时，就溢出

11、sortmb:kvbuffer总的内存量，默认值是100m，可以配置

12、indexCacheMemoryLimit:存放溢出文件信息的缓存大小，默认1m，可以配置

13、bufferremaining:buffer剩余空间，字节为单位

14、softLimit:溢出阈值，超出后就溢出。Sortmb*spiller

初始状态

初始时，equator=0，在写入数据时，raw data往数组下标增大的方向延伸，而meta data（索引信息）往从数组后面往下标减小的方向延伸。从上图来看，raw data就是按照顺时针来写入数据，而meta data按照逆时针写入数据。我们再看一下各个变量的初始化情况，raw data部分的变量，bufstart、bufend、bufindex都初始化为0。Meta data部分的变量，kvstart 、kvend、kvindex都是按逆时针偏移了16个字节（metasize=16个字节），因为一个meta data占用16个字节（4个整数，分别存储keystart,valuestart,partion,valuelen），所以需要逆时针偏移16个字节来标记第一个存储的metadata的起始位置。还有一个重要的变量，bufferremaining = softlimit（默认是sortmb*80%）。

我们下面看一下对应这部分的初始化代码：

[java] view plain copy

1. public void init(MapOutputCollector.Context context

2. ) throws IOException, ClassNotFoundException {

3. job = context.getJobConf();

4. reporter = context.getReporter();

5. mapTask = context.getMapTask();

6. mapOutputFile = mapTask.getMapOutputFile();

7. sortPhase = mapTask.getSortPhase();

8. spilledRecordsCounter = reporter.getCounter(TaskCounter.SPILLED_RECORDS);

9. //获取reduce的数量，作为分区数

10. partitions = job.getNumReduceTasks();

11. rfs = ((LocalFileSystem)FileSystem.getLocal(job)).getRaw();

12.

13. //sanity checks

14. //获取到spiller，默认80%

15. final float spillper =

16. job.getFloat(JobContext.MAP_SORT_SPILL_PERCENT, (float)0.8);

17. //获取sortmb，就是整个缓冲区的大小，默认100M

18. final int sortmb = job.getInt(JobContext.IO_SORT_MB, 100);

19. indexCacheMemoryLimit = job.getInt(JobContext.INDEX_CACHE_MEMORY_LIMIT,

20. INDEX_CACHE_MEMORY_LIMIT_DEFAULT);

21. if (spillper > (float)1.0 || spillper <= (float)0.0) {

22. throw new IOException("Invalid \"" + JobContext.MAP_SORT_SPILL_PERCENT +

23. "\": " + spillper);

24. }

25. if ((sortmb & 0x7FF) != sortmb) {

26. throw new IOException(

27. "Invalid \"" + JobContext.IO_SORT_MB + "\": " + sortmb);

28. }

29. //获取排序方法，使用快速排序的方法

30. sorter = ReflectionUtils.newInstance(job.getClass("map.sort.class",

31. QuickSort.class, IndexedSorter.class), job);

32. // buffers and accounting

33. //将mb转化成byte，sortmb<<20就是sortmb*104*1024

34. int maxMemUsage = sortmb << 20;

35. maxMemUsage -= maxMemUsage % METASIZE;

36. //生成kvbuffer

37. kvbuffer = new byte[maxMemUsage];

38. bufvoid = kvbuffer.length;

39. //生成kvmeta，就像前面所说的，kvmeta只是kvbuffer的一种视角，下面会详细讲解kvmeta对kvbuffer的封装

40. kvmeta = ByteBuffer.wrap(kvbuffer)

41. .order(ByteOrder.nativeOrder())

42. .asIntBuffer();

43. //设置分割线为0

44. setEquator(0);

45. //初始化bufstart,bufend,bufindex,equator都为0

46. bufstart = bufend = bufindex = equator;

47. //初始化kvstart，kvend，kvindex都为kvbuffer.length-metasize，kvindex在setEquator中已经计算出来了

48. kvstart = kvend = kvindex;

49. //计算kvmeta能存储的最大数量

50. maxRec = kvmeta.capacity() / NMETA;

51. //设置softlimit为缓存的80%

52. softLimit = (int)(kvbuffer.length * spillper);

53. //设置bufferRemaining为softlimit

54. bufferRemaining = softLimit;

55. if (LOG.isInfoEnabled()) {

56. LOG.info(JobContext.IO_SORT_MB + ": " + sortmb);

57. LOG.info("soft limit at " + softLimit);

58. LOG.info("bufstart = " + bufstart + "; bufvoid = " + bufvoid);

59. LOG.info("kvstart = " + kvstart + "; length = " + maxRec);

60. }

61.

62. // k/v serialization

63. //生成keySerializer，valueSerializer

64. comparator = job.getOutputKeyComparator();

65. keyClass = (Class<K>)job.getMapOutputKeyClass();

66. valClass = (Class<V>)job.getMapOutputValueClass();

67. serializationFactory = new SerializationFactory(job);

68. keySerializer = serializationFactory.getSerializer(keyClass);

69. keySerializer.open(bb);

70. valSerializer = serializationFactory.getSerializer(valClass);

71. valSerializer.open(bb);

72.

73. // output counters

74. //输出统计，byteCounter,recorderCounter。返回给用户

75. mapOutputByteCounter = reporter.getCounter(TaskCounter.MAP_OUTPUT_BYTES);

76. mapOutputRecordCounter =

77. reporter.getCounter(TaskCounter.MAP_OUTPUT_RECORDS);

78. fileOutputByteCounter = reporter

79. .getCounter(TaskCounter.MAP_OUTPUT_MATERIALIZED_BYTES);

80.

81. // compression

82. if (job.getCompressMapOutput()) {

83. Class<? extends CompressionCodec> codecClass =

84. job.getMapOutputCompressorClass(DefaultCodec.class);

85. codec = ReflectionUtils.newInstance(codecClass, job);

86. } else {

87. codec = null;

88. }

89.

90. // combiner

91. final Counters.Counter combineInputCounter =

92. reporter.getCounter(TaskCounter.COMBINE_INPUT_RECORDS);

93. combinerRunner = CombinerRunner.create(job, getTaskID(),

94. combineInputCounter,

95. reporter, null);

96. if (combinerRunner != null) {

97. final Counters.Counter combineOutputCounter =

98. reporter.getCounter(TaskCounter.COMBINE_OUTPUT_RECORDS);

99. combineCollector= new CombineOutputCollector<K,V>(combineOutputCounter, reporter, job);

100. } else {

101. combineCollector = null;

102. }

103. spillInProgress = false;

104. minSpillsForCombine = job.getInt(JobContext.MAP_COMBINE_MIN_SPILLS, 3);

105. //溢出文件的后台线程

106. spillThread.setDaemon(true);

107. spillThread.setName("SpillThread");

108. spillLock.lock();

109. try {

110. spillThread.start();

111. while (!spillThreadRunning) {

112. spillDone.await();

113. }

114. } catch (InterruptedException e) {

115. throw new IOException("Spill thread failed to initialize", e);

116. } finally {

117. spillLock.unlock();

118. }

119. if (sortSpillException != null) {

120. throw new IOException("Spill thread failed to initialize",

121. sortSpillException);

122. }

123. }

写入第一个<key,value>的状态

我们看一下写入第一个<key,value>的情况，首先放入key，在bufferindex的基础上累加key的字节数，然后放入value，继续累加bufferindex的字节数。接下来放入metadata，meta data一共包括4个整数，第一个int放valuestart，第二个int放keystart，第三个int放partion，第四个int放value的长度。为什么只有value的长度，没有key的长度？个人理解key的长度可以有valuestart – keystart得出，不需要额外的空间来存储key的长度。需要注意的是，bufindex和kvindex发生了变化，分别指向了下一个数据需要插入的地方。但是bufstart，endstart,kvstart,kvend都没有变化，bufferremaining相应地减少了meta data 和raw data占据的空间。

我们再来看一下对应这部分的代码：

[java] view plain copy

1. // serialize key bytes into buffer

2. //序列化key到buffer中

3. int keystart = bufindex;

4. keySerializer.serialize(key);

5. //如果序列化完key以后，bufindex<keystart了，由于循环缓冲区的原因，key在数组尾部存储了一部分，在数组头部也存储了一部分，

6. 需要将key往后偏移，保证key是连续的，不能发生一部分在尾部一部分在头部的情况。下面的“key跨边界的情况”章节会详细介绍该特殊情况

7. if (bufindex < keystart){

8. // wrapped the key; must make contiguous

9. bb.shiftBufferedKey();

10. keystart = 0;

11. }

12. // serialize value bytes into buffer

13. //序列化value到kvbuffer中

14. final int valstart= bufindex;

15. valSerializer.serialize(value);

16. // It's possible for records to have zero length, i.e. the serializer

17. // will perform no writes. To ensure that the boundary conditions are

18. // checked and that the kvindex invariant is maintained, perform a

19. // zero-length write into the buffer. The logic monitoring this could be

20. // moved into collect, but this is cleaner and inexpensive. For now, it

21. // is acceptable.

22. bb.write(b0, 0, 0);

23.

24. // the record must be marked after the preceding write, as the metadata

25. // for this record are not yet written

26. //得到valend，为写入meta data数据时做准备

27. int valend = bb.markRecord();

28. //recordCounter加1

29. mapOutputRecordCounter.increment(1);

30. //byteCounter加上key和value的字节长度

31. mapOutputByteCounter.increment(

32. distanceTo(keystart, valend, bufvoid));

33.

34. // write accounting info

35. //下面是写入kvmeta信息，就不做赘述了

36. kvmeta.put(kvindex + PARTITION, partition);

37. kvmeta.put(kvindex + KEYSTART, keystart);

38. kvmeta.put(kvindex + VALSTART, valstart);

39. kvmeta.put(kvindex + VALLEN, distanceTo(valstart, valend));

40. // advance kvindex

41. //偏移kvindex

42. kvindex= (kvindex- NMETA+ kvmeta.capacity())% kvmeta.capacity();

溢出文件

第一次达到spill的阈值

随着kvindex和bufindex的不断偏移，剩余的空间越来越小，当剩余空间不足时，就会触发spill操作。如上图，kvindex和bufindex之间的空间已经很小了。

重新划分equator，开始溢出

溢出文件开始前，需要先更新kvend、bufend,kvend 需要更新成kvindex + 4 int，因为kvindex始终指向下一个需要写入的meta data的位置，必须往后回退4 int 才是meta data真正结束的位置，如上图，kvend加了4int往顺时针方向偏移了。Kvstart指向最后一个meta data写入的位置。Bufstart标识着最后一个key 开始的位置，bufend 标识最第一个value的结束位置。Kvstart和kvend之间（黄色部分）是需要溢出的meta data。Bufstart和bufend之间（浅绿色）是需要溢出的raw data。溢出的时候，其他的缓存空间（深绿色）仍然可以写入数据，不会被溢出操作阻塞住。默认的Spiller是80%，也就是还有20%的空间可以在溢出的时候使用。

溢出开始前，需要确定新的equator，新的equator一定在kvend和bufend之间。新的equator一定要做到合适的划分，保证能写入更多的metadata和raw data。确定了equator后，我们需要更新bufindex和kvindex的位置，更新bufferremaining的大小，bufferremaining要选择equator到bufindex、kvindex较小的那个。任何一个用完了，都代表不能写入数据，这也说明了equator划分均匀的重要性。

溢出完成后的状态

在溢出完成后，空间都已经释放出来，溢出完成后的缓存状态就变成了上图：meta data从新的equator开始逆时针写入数据，raw data从新的equator开始顺时针写入数据。当剩余的空间又到了溢出的阈值时，再次划分equator，再次溢出文件。

下面看一下这部分对应的代码：

[java] view plain copy

1. //每次写入数据之前bufferremaining先减去16个字节的大小

2. bufferRemaining -= METASIZE;

3. if (bufferRemaining <= 0) {

4. // start spill if the thread is not running and the soft limit has been

5. // reached

6. //如果soft limit 达到了，就需要溢出文件

7. spillLock.lock();

8. try {

9. do {

10. if (!spillInProgress) {

11. final int kvbidx = 4 * kvindex;

12. final int kvbend = 4 * kvend;

13. // serialized, unspilled bytes always lie between kvindex and

14. // bufindex, crossing the equator. Note that any void space

15. // created by a reset must be included in "used" bytes

16. //已经序列化的，但是未进行spill的文件，总是在kvindex和bufindex之间（中间横跨equator），所以可以通过kvindex和bufindex计算出使用的字节数。

17. final int bUsed = distanceTo(kvbidx, bufindex);

18. final boolean bufsoftlimit = bUsed >= softLimit;

19. //注意这里，(kvbend + METASIZE) % kvbuffer.length ！= equator - (equator % METASIZE)，说明已经发生了spill操作（进行spill操作时，kvend会调整，equator会重新划分），而程序能够进来，说明溢出操作已经结束

20. if ((kvbend + METASIZE) % kvbuffer.length !=

21. equator - (equator % METASIZE)) {

22. // spill finished, reclaim space

23. //resetSPill中，就是将bufstart和bufend重置为equator，kvstart和kvend重置为第一条meta record的开始位置

24. esetSpill();

25. //重新计算bufferremaing

26. bufferRemaining = Math.min(

27. distanceTo(bufindex, kvbidx) - 2 * METASIZE,

28. softLimit - bUsed) - METASIZE;

29. continue;

30. } else if (bufsoftlimit && kvindex != kvend) {

31.

32. // spill records, if any collected; check latter, as it may

33. // be possible for metadata alignment to hit spill pcnt

34. //startSpill中，将kvend

35. startSpill();

36. final int avgRec = (int)

37. (mapOutputByteCounter.getCounter() /

38. mapOutputRecordCounter.getCounter());

39. // leave at least half the split buffer for serialization data

40. // ensure that kvindex >= bufindex

41. final int distkvi = distanceTo(bufindex, kvbidx);

42. final int newPos = (bufindex +

43. Math.max(2 * METASIZE - 1,

44. Math.min(distkvi / 2,

45. distkvi / (METASIZE + avgRec) * METASIZE)))

46. % kvbuffer.length;

47. setEquator(newPos);

48. bufmark = bufindex = newPos;

49. final int serBound = 4 * kvend;

50. // bytes remaining before the lock must be held and limits

51. // checked is the minimum of three arcs: the metadata space, the

52. // serialization space, and the soft limit

53. bufferRemaining = Math.min(

54. // metadata max

55. distanceTo(bufend, newPos),

56. Math.min(

57. // serialization max

58. distanceTo(newPos, serBound),

59. // soft limit

60. softLimit)) - 2 * METASIZE;

61. }

62. }

63. } while (false);

64. } finally {

65. spillLock.unlock();

66. }

67. }

Key跨边界的情况

Key可能存在跨越边界的情况

发生key跨边界的情况后，进行key偏移

在这里，我们讨论一种特殊情况的处理，就是key跨越数组边界的情况。因为我们使用字节数组来实现循环缓冲区，所以肯定会存在某些数据跨越数组边界的情况。对于value跨越边界的情况，我们无需处理。而对于key跨越边界的情况，我们需要处理。为什么？因为map任务在溢出文件时，需要按照key进行排序，排序就需要取出key的值比较大小，如果key跨边界的话，取值时就不方便了。那么如何处理呢？就是将key进行偏移，使得key从数组的头部开始存储，而数组的尾部存储key的部分完全空闲出来，不再存储数据。如上图：key进行偏移后，从数组坐标0开始存储，而原先尾部的空间（红色圈出来的）不再存储数据。

1 0