mapreduce论文笔记

Map/reduce论文

 

即输入key/value和输出key/value不在同一个domain，而中间输出key/value和结果key/value在同一个domain。

 

 

框架将输入数据自动分割成M个split，在多个机器上调用Map。（并行map处理） 。产生中间结果后，使用分区函数将中间key分割为R个pieces（数量R和分区函数由用户提供）

 

处理流程：

1.    客户程序中的mapreduce库代码将输入文件分割成M个piece（一般16mb-64mb，用户可控制），在集群内启动多个执行实例。

2.    其中一个实例是特殊的，称为master。其他为worker，由master分配工作：M个map任务和R个reduce任务。

3.    被分配map任务的worker从相应的input split中读取数据，解析key/value对，将每个key/value传给用户定义的map函数。Map函数产生的中间key/value对保存在内存中。

4.    内存中key/value对定期写入R个本地文件（通过分区函数分成R个region），并将文件位置发送给master。

5.    master通知reduce worker中间文件位置，reduce worker通过RPC调用读取文件，并根据中间key排序。如果数据太多，要使用外部排序。

6.    reduce worker遍历经过排序的中间数据，对每一个唯一的中间key，将key和key对应的values集合传递给用户定义的reduce函数。Reduce函数的输出append到该reduce partition对应的结果文件中。（即最后会有R个输出文件）

7.    当所有map任务和reduce任务结束后，master唤醒用户程序，map/reduce调用结束，用户代码继续执行。

 

执行完毕后，用户一般不用合并R个输出文件，而是将他们作为输入传给下一组map/reduce调用

 

Master数据结构：

每个map/reduce 任务的状态：idle，in-progress,completed，以及worker机器（非idle任务）的标识。

 

容错：

Worker失效：

Master定期ping每个worker。若ping超时则标记该worker失效。该worker上完成的任何map任务被reset为初始idle状态，以便在其他worker上重新调度。该worker上in progress的map任务或reduce任务也被reset为idle。---已完成的map任务的worker失效需要重新执行，因为中间输出文件可能无法访问，而已完成reduce任务的worker失效则不需要重新执行，因为结果文件保存在global filesystem。

 

Map/reduce任务输出的自动提交（？？？）

 

 

 

master在调度Map任务时会考虑输入文件的位置信息，尽量将一个Map任务调度在包含相关输入数据拷贝的机器上执行

 

 

Combiner函数

在某些情况下，Map函数产生的中间key值的重复数据会占很大的比重，并且，用户自定义的Reduce函数满足结合律和交换律。在2.1节的词数统计程序是个很好的例子。由于词频率倾向于一个zipf分布(齐夫分布)，每个Map任务将产生成千上万个这样的记录<the,1>。所有的这些记录将通过网络被发送到一个单独的Reduce任务，然后由这个Reduce任务把所有这些记录累加起来产生一个数字。我们允许用户指定一个可选的combiner函数，combiner函数首先在本地将这些记录进行一次合并，然后将合并的结果再通过网络发送出去。

 

Combiner函数在每台执行Map任务的机器上都会被执行一次。一般情况下，Combiner和Reduce函数是一样的。Combiner函数和Reduce函数之间唯一的区别是MapReduce库怎样控制函数的输出。Reduce函数的输出被保存在最终的输出文件里，而Combiner函数的输出被写到中间文件里，然后被发送给Reduce任务。

 

3.6、备用任务

影响一个MapReduce的总执行时间最通常的因素是“落伍者”：在运算过程中，如果有一台机器花了很长的时间才完成最后几个Map或 Reduce任务，导致MapReduce操作总的执行时间超过预期。出现“落伍者”的原因非常多。比如：如果一个机器的硬盘出了问题，在读取的时候要经常的进行读取纠错操作，导致读取数据的速度从30M/s降低到1M/s。如果cluster的调度系统在这台机器上又调度了其他的任务，由于CPU、内 存、本地硬盘和网络带宽等竞争因素的存在，导致执行MapReduce代码的执行效率更加缓慢。我们最近遇到的一个问题是由于机器的初始化代码有bug， 导致关闭了的处理器的缓存：在这些机器上执行任务的性能和正常情况相差上百倍。

 

我们有一个通用的机制来减少“落伍者”出现的情况。当一个MapReduce操作接近完成的时候，master调度备用（backup）任务进程来执行剩下的、处于处理中状态（in-progress）的任务。无论是最初的执行进程、还是备用（backup）任务进程完成了任务，我们都把这个任务标记成为已经完成。我们调优了这个机制，通常只会占用比正常操作多几个百分点的计算资源。我们发现采用这样的机制对于减少超大MapReduce操作的 总处理时间效果显著。例如，在5.3节描述的排序任务，在关闭掉备用任务的情况下要多花44%的时间完成排序任务。

 

 

MapReduce库支持几种不同的格式的输入数据。比如，文本模式的输入数据的每一行被视为是一个key/value pair。key是文件的偏移量，value是那一行的内容。另外一种常见的格式是以key进行排序来存储的key/value pair的序列。每种输入类型的实现都必须能够把输入数据分割成数据片段，该数据片段能够由单独的Map任务来进行后续处理(例如，文本模式的范围分割必 须确保仅仅在每行的边界进行范围分割)。

 

 

MapReduce编程模型在Google内部成功应用于多个领域。我们把这种成功归结为几个方面：首先，由于MapReduce封装了并行处 理、容错处理、数据本地化优化、负载均衡等等技术难点的细节，这使得MapReduce库易于使用。即便对于完全没有并行或者分布式系统开发经验的程序员 而言；其次，大量不同类型的问题都可以通过MapReduce简单的解决。比如，MapReduce用于生成Google的网络搜索服务所需要的数据、用 来排序、用来数据挖掘、用于机器学习，以及很多其它的系统；第三，我们实现了一个在数千台计算机组成的大型集群上灵活部署运行的MapReduce。这个 实现使得有效利用这些丰富的计算资源变得非常简单，因此也适合用来解决Google遇到的其他很多需要大量计算的问题。

 

我们也从MapReduce开发过程中学到了不少东西。首先，约束编程模式使得并行和分布式计算非常容易，也易于构造容错的计算环境；其次，网络带宽是稀有资源。大量的系统优化是针对减少网络传输量为目的的：本地优化策略使大量的数据从本地磁盘读取，中间文件写入本地磁盘、并且只写一份中间文件也节约了网络带宽；第三，多次执行相同的任务可以减少性能缓慢的机器带来的负面影响，同时解决了由于机器失效导致的数据丢失问题。