论文摘要-MapReduce: Simplified Data Processing on Large Clusters

MIT 分布式系统 6.248 第一讲涉及该论文。
课程页面（内含原文pdf链接）：http://nil.csail.mit.edu/6.824/2022/schedule.html
本文是对该论文的粗略理解摘要。

1.介绍

背景：近五年出现了很多涉及大规模原始数据的计算需求。这些计算概念上很简单，但由于数据量巨大，往往需要分布式处理才能把处理时间缩短到可接受范围内。实现分布式处理的过程中出现了一些复杂问题，包括 并行计算、分发数据、失败处理。

在MapReduce模型中，Map函数和Reduce函数的内部处理逻辑由用户自定义，其余关于并行处理、容错、数据分发和负载平衡的复杂细节，都由MapReduce系统处理，对用户不可见。

2.基本编程模型

MapReduce模型的使用者把他们所需要执行的计算用Map和Reduce这两个函数来表示

• Map：接受一个输入数据，将其转化为键值对（被称为 半成品键值对）转化的逻辑由用户自定义。半成品键值对会被传递给Reduce函数。
• Reduce：将键相同的键值对合并。

例子：

• 分布式查找(Distributed Grep) ：Map函数遍历待查找数据，生成<查找目标，含匹配目标的行>形式的半成品键值对，Reduce函数把所有半成品键值对原封不动地复制到输出。
• 统计URL访问频率：Map函数处理网页请求日志，生成<URL, 1>形式的半成品键值对，Reduce函数把所有键相同的键值对累加合并，得到<URL, 出现总次数>。

3.MapReduce针对谷歌大规模计算机集群的定制化实现

输入会被自动地分为M份，调用在不同机器上的Map函数并行处理。
半成品键值对的键(key)会被分为R份，调用在不同机器上的Reduce函数并行处理（R和分割函数都由用户指定）。

当用户程序调用MapReduce函数时，总体执行流程如下：

1. MapRedue库自动把输入文件分成M份，每一份一般是16MB~64MB（用户可以通过调节参数来控制每份的大小）。然后库会在机器集群上启动这个程序的许多副本。
2. 这些程序副本中，有一个特别的主副本。其他副本都是工人副本，被这个主副本分配工作。按照上面提到的划分方式，会有M个Map任务和R个Reduce任务需要分配。主副本选出空闲的工人副本，给它分配一个Map任务或一个Reduce任务。
3. 被分配到Map任务的工人副本会读取相应的输入，根据用户定义的Map函数，处理出半成品键值对，这些半成品键值对缓存在工人副本的机器的内存中。
4. 被缓存的半成品键值对会被逐渐地写入本地磁盘，并根据分割函数，分成R份。每一份在本地磁盘上的存储位置都会传给主副本，主副本负责把这些位置转发给处理Reduce任务的工人副本。
5. 当处理Reduce任务的工人副本接收到存储位置信息，它通过远程过程调用(RPC)，从所有Map任务工人副本的本地磁盘上，读取自己负责的半成品键值对信息。全部读完以后，它会把半成品键值对按键进行排序，以便把所有键相同的数据合并到一起。（如果半成品键值对数据太大，内存里装不下，会使用外部排序）。
6. 处理Reduce任务的工人副本迭代排序后的半成品键值对，对每一个键值，调用用户实现的Reduce函数处理，并把处理结果拼接在自己的输出文件的后面。
7. 所有Map任务和Reduce任务都处理完后，主副本唤醒用户程序。

整个过程成功执行完以后，会有R个输出文件（每个Reduce任务会有一个输出文件，文件名由用户指定）。一般来说不需要把这R个输出文件合并为一个，因为往往需要把这些文件作为输入再次调用MapReduce或者把它们用于其他的、可以处理碎片输入的 分布式任务。

主副本中保存的数据结构

• 每个Map任务和Reduce任务的状态（未开始/处理中/已完成），非空闲任务的执行机器身份。
• 对于已完成的Map任务，半成品键值对被划分为R份，分别保存这R份的存储位置和大小。

容错机制
MapReduce库利用成百上千台机器处理巨量数据，虽然单台机器的故障概率不高，但同时使用这么多机器，某几台出现故障的情况几乎是不可避免的，所以需要容错机制。

• 工人副本故障：
  主副本会周期性地Ping每个工人副本，如果一定时间内没有回复，主副本就会把这个工人副本标记为故障。把这个副本负责的任务状态标记为"未开始"，使其能被重新调度。
  如果是负责Map任务的机器故障，它已完成的任务也会被重新执行，因为结果保存在其本地磁盘中，如果它故障了，其完成的任务结果无法再读取。
  如果是负责Reduce任务的机器故障，它已完成的任务就不用重新执行了，因为输出文件不是保存在本地磁盘，是保存在通用的文件系统中。
  Map任务失败重分配这一行为，会告知给所有执行Reduce任务的机器，因为它们需要把数据读取转向新的工人副本。
  这样的处理下，MapReduce对大规模的工人机器故障也是有一定弹性的。

• 主副本故障：
  因为主副本只运行在一台机器上，故障概率很小，所以在本论文的实现中，如果主副本故障就直接放弃这次任务。
  可以考虑的优化方向是：按一定的周期写入保存点，如果主副本故障导致任务失败，可以直接从上一个保存点开始。

任务颗粒度
如上所述，在Map阶段，任务会被分为M份；在Reduce阶段，任务会被分为R份。理想情况下，M和R应该远大于集群中工人机器的数量，因为这样能提升负载均衡性;同时,当一台工人机器故障时，将任务重新分配执行的损失更小。
但M和R的大小在实际情况下是受限的，因为主副本需要做 O(M+R)个分配决策、保存O(M*R)个状态信息（每个Map任务会有R个输出，每个输出的状态信息都需要保存）。
另外，R是由用户根据他们的计算需求以及需要多少个输出文件指定的。
出于这两个原因，M和R的数量一般无法到达理想情况。
实际情况下，M的大小一般根据输入文件的大小决定，应使得分割后的每份文件大小在16MB~64MB之间；而R应该工人机器数量的一个较小的倍数（例如2000台工人机器的情况下，R取5000）

备份任务
“落后者”是拖慢一个任务总完成时间的一个常见因素：最后几个Map或Reduce任务中，有一台机器花费了格外长的时间才完成（可能是由于磁盘故障、网络带宽、有别的任务竞争CPU资源、缓存失效等很多因素），导致整体执行时间延长。
本论文的实现中，使用了备份任务的机制来减轻“落后者”的影响。当任务接近结束时，主副本会调度所有正在执行的任务的备份执行，原任务或备份任务中，只要有一个完成，就把该任务标记为已完成。
这个机制经过调整后，可以做到只多耗费一点计算资源，就显著缩短整体执行时间。