MapReduce总结笔记

前言

学习分布式课程也有段时间了，学了不少东西，但总感觉还有些乱，不成体系，没有系统。可能是因为学的还不太好，理解的不够深，也有可能是因为没有学而思，然后就罔了。 今天花点时间总结总结MapReduce以及GFS。

整个MR的知识框架主要如下图所示。

下面的总结主要也是按照这个框架进行讲解。

一、MR Overview

MR是个分布式的计算框架， 相对来说，我觉得整个MR中最重要，也是最基础的就是paper中的figure1了。如下图所示

具体的执行流程如下：

1. 首先用户程序中的MR库（以库的形式被用户程序引入）会将InputFiles分割成M份16-64M大小的块，然后fork出一些供MR使用的进程，主要包括一个Master和多个worker。
2. Master 为中心化调度结点，负责整个MR系统的调度。它会从空闲的worker中找出M个worker（叫做Map worker），给其分配Map 任务；同样的，它也会从空闲的worker中找出R个worker（叫做Reduce worker），给其分配reduce任务。
3. Map worker从对应的inputFiles中读取数据，将其解析成一系列key/value pairs(这个具体解析的原则，我也不是很清楚，但我猜测应该是用户配置的)，然后把这些pairs传递给用户定义的map函数。map 函数将会产生immediate key/value pairs（中间键值存储对），它们暂时存储在内存中。
4. 这些数据会周期性的写入到本地磁盘中，并被partitioning函数分成R个部分（正好对应R个Reduce Worker）。同时这R个部分的位置会被返回到master中，用于传递给reduce worker。
5. 当所有的map任务完成之后，master会给reduce worker分配任务（带有其任务所要读取数据的位置信息），reduce worker接受到任务之后，按照master给的位置信息，利用remote read(一般是调用gfs文件系统的读取api)，读取数据。然后reduce需要根据key值进行排序，这样所有key相同的值就会被分在一组。（注意，这里一般都需要进行排序，因为不同的worker产生的中间键值对可能会映射到同一个reduce worker）.
6. reduce worker迭代访问排序后的数据，对于每一个unique key，将key和其对应的values传递给用户定义的reduce函数。 经过reduce函数的处理，最后会分别写入到输出文件中去
7. 所有的map任务和reduce任务完成后，master唤醒用户程序，此时MapReduce调用return 。成功完成调用后，mapreduce的输出可在R个输出文件中查看，用户不需要将R个文件合并，他们通常将这些文件作为另一个MapReduce调用的输入，或用其他分布式应用处理。

二、Example: WordCount

WordCount程序应该算是MR中的“helloWorld”了。其基本的实现过程如下图所示。

其伪代码可以如下所示：

基本的过程还是比较简单的，就不多说了。

三、Fault tolerance

3.1 worker failure

作为中心化调度结点的maser，其会定时ping所有的worker。当其发现map worker ping不通，master就会认为其已经over了，它会重启一个新的worker执行已经over的worker任务，无论其是否已经完成（completed）。

如果其发现reduce worker ping不通之后，master会根据reduce worker的任务是否已经完成，来决定是否要重启这个reduce 任务。因为reduce 任务的输出是保存在gfs中的，如果是已经处于已完成状态的reduce worker over了，在gfs中必定还存在其余的备份可以提供访问，所以其不需要重新启动任务。当然，如果reduce worker 任务还未完成就over了，那么我觉master还是需要重新启动的。

3.2 master failure

单节点的中心控制形成的一个状况是：要么就不over，要over整个系统就over。 所以MR系统假设maser是不会over的，如果master真的over了，系统只会终止操作，然后把错误返回给用户，让用户处理。

3.3 semantics in the presence of failures

论文中还提到了map()和reduce()函数的语义问题，关于这个，我暂时还没搞得太清楚，这里就不说了。

3.4 其他

这儿有两个关于failure的小问题，也贴在这儿了。

四、Performance

MR 在提高系统性能方面有一些优点，如下所示

4.1 network

Master尽量在有输入数据的那台机子上运行map worker程序。这样map worker可以直接从本地磁盘中读取输入数据，减少了网络开销。从某种方式来说，也算体现了分布式领域中的“移动计算比移动数据更有效”

4.2 good load balance

为了提高worker的利用率，一般MR在设计时会参照一个原则：
many more tasks than workers。
这样的话，整个系统相对来说任务较多，但是每个任务的量比较小。 那些完成的比较快的worker不会处于空闲状态，而会重新被分配一个新的任务，相对来说整个worker系统的利用率就上去了。

同时，对于系统中可能出现的“straggler”（也就是可能因为某台机器的内存啊
磁盘性能不是很好造成的迟迟不能完成任务的worker），系统会启动一些backup worker，来同时完成这个worker的任务，最终只要有其中的一个完成任务，那么系统就可以继续执行下去。相对来说，也提高了系统的性能。

五、Others

5.1 shuffle

关于论文涉及到的这个shuffle，这也算是个重点了，听说很多面试的时候都会问。先总结一下。

shufle，英文的意思是洗牌。MR中的shuffle从某种程度上说是对数据进行洗牌。下面这个博客讲的比较详细，就实行拿来主义了：

5.2 advantage and limit

advantege

1. Easy to program :屏蔽了内部细节（并发啊、错误啊等等），是用于易于实现分布式计算，其只要定义map()和reduce()函数。
2. Scales well:扩展性不错。

limits

1. No interaction or state
2. No iteration, no multi-stage pipelines
3. No real-time or streaming processing