Hadoop--Map与Reduce

最近一直在学习Hadoop相关的生态，本文记录下关于Hadoop下MapReduce的一些运作机制以及背后的原理。

MapReduce流程

网上找的一张MapReduce流程图，个人认为过程是很清晰的，那么理解MapReduce就要深入到每一个过程，也是文章后面分析的步骤。

HDFS

在HDFS的写流程中，一个大文件上传会被拆分成对应的block块，默认是128M，分散到不同的机器中，也就对应着图中的 split ，一般情况下为了保证Map能够完全并行，每一个block对应一个Map程序处理，一个10T的文件就会有80个Map程序处理。

Map

一般情况下Map task的数量远远大于Reduce task，因此Map端是整个执行的主力，为了保证Map高效的并行，该任务的Application Master会尽可能保证data local原则（Map端尽可能处理本地的block），当无法保证时会进一步尝试同一机架上的block处理，尽可能的减少传输带来的损耗。

Map的处理是技术人员写的逻辑，以wordcount为例，Map处理后产生的是一个个单词与数量的键值对 <good,1> <and,1> <good,1> <zero,1> ... ，存放在内存中（mapreduce.task.io.sort.mb）。

Map shuffle

在Map流程中产生的中间结果是存放在内存中，当内存使用率达到一定比率（mapreduce.map.sprt.spill.percent），会通过后台进程写入到磁盘中，这个过程叫 spill 。 spill 是由单独的线程完成处理，在 spill 过程中内存满了则会造成map阻塞。在写磁盘之前，当前线程会根据Reduce的数量设置分区，然后把内存中的数据写入到分区中，这个过程也会对内存中的数据进行合并以及排序，之后如果存在combine则会执行combine逻辑，先本地reduce尽可能的减少生成文件大小。

当Map结束后对应的结果是一堆已经分区且有序的溢出文件，此时会把这些文件做一个归并，归并的过程也会根据配置执行combine来减少生成文件大小，最后拼装成最终结果。

以上述wordcount为例，在没有分区的情况下，执行map shuffle后为 <and,1> <good,1,1> <zero,1> ，如果有对应的combine逻辑，则结果进一步被整理 <and,1> <good,2> <zero,1>

Reduce shuffle

Map端结束后在对应的Map task机器上生成对应的结果文件，Reduce shuffle要做的第一件事就是根据Reduce任务配置，聚集对应的数据分区，简单点说就是去各各Map机器上拿自己所需要的数据，这里无法避免要涉及网络传输，因此在传输前一般会启用压缩，降低网络压力。默认情况下当已执行完的Map task大于总Map的5%时就开始执行copy逻辑汇集结果。当拿到数据之后Reduce shuffle就会归并对应的数据集，最终的归并结果转交给Reduce处理。

Reduce

Reduce的处理是技术人员定义的业务逻辑，最终输出到指定位置目录。

其他问题

如何优化MapReduce？

从上述流程来分析，Map端是业务处理的重点，且Map task的数量往往又远大于Reduce task数量，更容易依赖并行进行更多的计算。

1. 根据文件block数量设置一个合理的Map task数量，该目的是为了减少网络传输的消耗。
2. 减少Map任务的内存使用，对于单一的Map，Hadoop是串行调用，不存在并发，因此可以使用全局变量等方式重用对象。
3. 使用combine，combine相当于Map本地的reduce，利用map数量的优势，可以大幅度减少Reduce的压力。
4. 压缩输出结果，在Reduce shuffle过程中会去不同的Map机器上获取文件，那么性能瓶颈就在网络IO上，因此压缩会让传输更加效率。

为什么Map端排序Reduce端也要排序？

这个问题说说个人的理解，首先对于大量数据 排序 本身就是一件困难的事情，因此Hadoop必须提供排序功能，但是可以做成可拔插设计，虽然并不可以，不是所有的结果都需要排序。

Map端排序默认使用的是快排，Reduce端使用的是归并，当结果到达Reduce端是已经是有序状态了，那么Reduce端只需要合并有序集，排序的绝大部分压力被Map端分担了起来，这个也是两次排序的目的。