MapReduce工作原理

通过 Client、JobTrask 和 TaskTracker 的角度来分析 MapReduce 的工作原理：

首先在客户端（Client）启动一个作业（Job），向 JobTracker 请求一个 Job ID。将运行作业所需要的资源文件复制到 HDFS 上，包括 MapReduce 程序打包的 JAR 文件、配置文件和客户端计算所得的输入划分信息。这些文件都存放在 JobTracker 专门为该作业创建的 文 件 夹 中 ， 文 件 夹 名 为 该 作 业 的 Job ID 。 JAR 文 件 默 认 会 有 10 个 副 本（mapred.submit.replication 属性控制）；输入划分信息告诉了 JobTracker 应该为这个作业启动多少个 map 任务等信息。

JobTracker 接收到作业后，将其放在一个作业队列里，等待作业调度器对其进行调度当作业调度器根据自己的调度算法调度到该作业时，会根据输入划分信息为每个划分创建一个 map 任务，并将 map 任务分配给 TaskTracker 执行。对于 map 和 reduce 任务，TaskTracker 根据主机核的数量和内存的大小有固定数量的 map 槽和 reduce 槽。这里需要强调的是：map 任务不是随随便便地分配给某个 TaskTracker 的，这里就涉及到上面提到的数据本地化（Data-Local）。TaskTracker 每隔一段时间会给 JobTracker 发送一个心跳，告诉 JobTracker 它依然在运行，同时心跳中还携带着很多的信息，比如当前 map 任务完成的进度等信息。当JobTracker 收到作业的最后一个任务完成信息时，便把该作业设置成“成功”。当 JobClient查询状态时，它将得知任务已完成，便显示一条消息给用户。

如果具体从 map 端和 reduce 端分析，可以参考上面的图片，具体如下：
Map 端流程：
1) 每个输入分片会让一个 map 任务来处理，map 输出的结果会暂且放在一个环形内存缓冲区中（该缓冲区的大小默认为 100M，由 io.sort.mb 属性控制），当该缓冲区快要溢出时（默认为缓冲区大小的 80%，由 io.sort.spill.percent 属性控制），
会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。

2) 在写入磁盘之前，线程首先根据 reduce 任务的数目将数据划分为相同数目的分区，也就是一个 reduce 任务对应一个分区的数据。这样做是为了避免有些 reduce 任务分配到大量数据，而有些 reduce 任务却分到很少数据，甚至没有分到数据的尴尬局面。其实分区就是对数据进行 hash 的过程。然后对每个分区中的数据进行排序，如果此时设置了 Combiner，将排序后的结果进行 Combine 操作，这样做的目的是让尽可能少的数据写入到磁盘。

3) 当 map 任务输出最后一个记录时，可能会有很多的溢出文件，这时需要将这些文件合并。合并的过程中会不断地进行排序和 Combine 操作，目的有两个：
 尽量减少每次写入磁盘的数据量；
 尽量减少下一复制阶段网络传输的数据量。
最后合并成了一个已分区且已排序的文件。为了减少网络传输的数据量，这里可以将数据压缩，只要将 mapred.compress.map.out 设置为 true 就可以了。

4) 将分区中的数据拷贝给相对应的 reduce 任务。分区中的数据怎么知道它对应的reduce 是 哪 个 呢 ？ 其 实 map 任 务 一 直 和 其 父 TaskTracker 保 持 联 系 ， 而TaskTracker 又一直和 JobTracker 保持心跳。所以 JobTracker 中保存了整个集群中的宏观信息。只要 reduce 任务向 JobTracker 获取对应的 map 输出位置就可以了。

Reduce 端流程：
1) Reduce 会接收到不同 map 任务传来的数据，并且每个 map 传来的数据都是有序的。如果 reduce 端接受的数据量相当小，则直接存储在内存中（缓冲区大小由mapred.job.shuffle.input.buffer.percent 属性控制，表示用作此用途的堆空间的
百 分 比 ）， 如 果 数 据 量 超 过 了 该 缓 冲 区 大 小 的 一 定 比 例 （ 由mapred.job.shuffle.merge.percent 决定），则对数据合并后溢写到磁盘中。
2) 随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，这样做是为了给后面的合并节省时间。其实不管在 map 端还是 reduce 端，MapReduce都是反复地执行排序，合并操作，所以排序是 hadoop 的灵魂。
3) 合并的过程中会产生许多的中间文件（写入磁盘了），但 MapReduce 会让写入磁盘的数据尽可能地少，并且最后一次合并的结果并没有写入磁盘，而是直接输入到reduce 函数。
在 Map 处理数据后，到 Reduce 得到数据之前，这个流程在 MapReduce 中可以看做是一个 Shuffle 的过程。在经过 mapper 的运行后，我们得知 mapper 的输出是这样一个 key/value 对。到底当前的 key 应该交由哪个 reduce 去做呢，是需要现在决定的。 MapReduce 提供Partitioner 接口，它的作用就是根据 key 或 value 及 reduce 的数量来决定当前的这对输出数据最终应该交由哪个 reduce task 处理。默认对 key 做 hash 后再以 reduce task 数量取模。默认的取模方式只是为了平均 reduce 的处理能力，如果用户自己对 Partitioner有需求，可以订制并设置到 job 上。