当前位置：首页 > article >正文

mit6824-01-MapReduce详解

article 2024/12/21 19:35:32

文章目录

MapReduce简述
编程模型
执行流程
- 执行流程
- 排序保证
- Combiner函数
- Master数据结构
容错性
- Worker故障
- Master故障
性能提升
- 定制分区函数
- 局部性
- 执行缓慢的worker(slow workers)
常见问题总结回顾
参考链接

MapReduce简述

MapReduce是一个在多台机器上并行计算大规模数据的软件架构。主要通过两个操作来实现：Map 和 Reduce：用于大规模数据集（大于1TB）的并行运算。

概念"Map（映射）“和"Reduce（归约）”，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（归约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。

编程模型

计算采用一组输入 K/V 对，并产生一组输出 K/V 对。MapReduce 库将计算表示为由用户编写的两个函数：

map()：根据输入生成一组中间 K/V 对。 MapReduce 库将所有具有相同 Key ki的 K/V 对传递给 Reduce 函数；reduce()：
将 ki对应的所有值合并成 Value Set，并能通过迭代器访问；

map-reduce经典举例即统计字母出现的次数，多个进程各自通过map函数统计获取到的数据片段的字母的出现次数；后续再通过reduce函数，汇总聚合map阶段下每个进程对各自负责的数据片段统计的字母出现次数。伪代码如下所示：

map(String key, String Value):
    // key: document name
    // value: document contents
    for each word w in value:
        EmitIntermediate(w, "1");
    
reduce(String key, Iterator values):
    // key: a word
    // value: a list of counts
    int result = 0;
    for each v in values:
        result += ParseInt(v);
    Emit(AsString(result));
   // map 函数发出每个单词及其出现次数。 reduce 函数统计特定单词发出的所有次数。

执行流程

MapReduce操作总执行流程如下：
在这里插入图片描述

Master进程，被称为coordinator协调器，负责orchestrate编排wokers，把map jobs分配给它们
reduce、map被称为task任务

MapReduce 库首先将输入文件 split 成 M 块，然后，它会在集群上启动该程序的多个副本；
其中一个副本是 Master（在 lab1 中称为 Coordinator），其余的是由 Master 分配工作的 Worker。有 M 个 map 任务和 R 个 reduce 任务要分配。 Master 为每个空闲的 Worker 分配一个任务；
map Worker 从输入数据中解析出 K/V 对，并将每一对传递给 map 函数，生成的中间 K/V 对并缓存在内存中；
缓冲的 K/V 对定期被写入本地磁盘，由分区函数划分为 R 个区域。Master 获取这些缓冲对的位置并负责将这些位置转发给 reduce Worker；
当 Master 通知 reduce Worker 这些位置时，它使用 RPC 从 map Worker 的本地磁盘读取缓冲数据。当 reduce Worker 读取所有中间数据时，它会根据中间键对其进行排序，以便将所有出现的相同键组合在一起；
reduce Worker 迭代排序的中间数据，对于遇到的每个唯一中间键，它将键和相应的中间值集传递给用户的 reduce 函数。 reduce 函数输出 append 到对应分区的最终文件中；
当所有的 map 任务和 reduce 任务都完成后，Master 唤醒用户程序，从 MapReduce 调用中返回；

排序保证

MapReduce 保证在给定的分区内，中间 K/V 对以 Key 递增顺序进行排列。从而保证每个分区的输出文件也是有序的——这在输出文件需要支持按键随机访问查找时很有用，同时可以对不同文件使用归并排序。具体实现时机：

Map Worker 中最后进行一次排序。

Combiner函数

在某些情况下，Map 函数产生的中间 key 值的重复数据会占很大的比重（例如词频统计，将产生成千上万的 <the, 1> 记录）。用户可以自定义一个可选的 Combiner 函数，Combiner 函数首先在本地将这些记录进行一次合并，然后将合并的结果再通过网络发送出去。
在这里插入图片描述
Combiner 函数的代码通常和 Reduce 函数的代码相同，启动这个功能的好处是可以减少通过网络发送到 Reduce 函数的数据量。

Master数据结构

Master 存储所有任务的状态（ idle 、 in-progress 或 completed ）和分配给所有工作机器执行的任务，以及由 map 任务生成的 R 个中间文件区域的位置和大小。当 map 任务完成时，对此位置和大小信息的更新被递增地推送给 reduce Worker。

容错性

Worker故障

Master 周期性地 ping 每个 Worker，如果 Worker 超时未回应，则将其标记为 Failed。
Worker 故障容错遵循以下原则：

map 任务被 Worker 完成后将重置为 idle 状态，以便调度给其他 Worker；

Failed Worker 未完成的任何任务将重置为 idle 状态；
Failed Worker 已完成的 map 任务将重新执行，因为它们的输出存储在故障机器的本地磁盘上，无法访问；
Failed Worker 已完成的 reduce 任务无需重新执行，因为它们的输出存储在全局文件系统中；
当一个 map 任务因 WorkerA 失败转而由 WorkerB 执行，所有 reduce Worker 会收到重新执行的通知，任何尚未从 Worker A 读取数据的 reduce 任务将从 Worker B 读取数据；

Master故障

对于Master故障，我查到的资料显示：

Master 故障：中止整个 MapReduce 运算，重新执行。一般很少出现 Master 故障。

Google当初设计MapReduce时设计协调器不允许失败。如果协调器真的失败了，整个job（包含具体的多个map、reduce步骤task）需要重新运行。在这篇论文中，没有谈论到协调器失败后他们的应对方式。

（协调器不允许失败）这使得容错性很难做得更高，因为它维护一些工作状态（每个map、reduce函数执行的状态），在论文的库中，协调器不能失败。

后面会谈论一些技术手段，可以实现协调器容错，他们可以这么做却不打算，原因是他们认为比起协调器，运行map函数的上千个机器中崩溃一台的概率更高（也就是收益和成本不成正比，所以暂时没有实现协调器容错的打算）。

性能提升

定制分区函数

MapReduce 库的用户可以自定义分区函数来应对不同应用场景。例如，使用 hash(Hostname(urlkey)) % R 作为分区函数可以使来自同一主机的所有 URL 最终出现在同一个输出文件中。

局部性

就近原则：
Google发表该 paper 时，网络带宽是一个相当匮乏的资源。Master 在调度 Map 任务时会考虑输入文件的位置信息，尽量将一个 Map 任务调度在包含相关输入数据拷贝的机器上执行；如果找不到，Master 将尝试在保存输入数据拷贝的附近的机器上执行 Map 任务。

需要注意的是，新的讲座视频提到，随着后来 Google 的基础设施的扩展和升级，他们对这种存储位置优化的依赖程度降低了。

执行缓慢的worker(slow workers)

MapReduce操作所用总时间受短板效应影响：
比如GFS也在同一台机器上运行占用大量的机器周期或带宽，或硬件本身问题，导致worker执行map/reduce很慢。慢的worker被称为straggler，当剩下几个map/reduce任务没有执行时，协调者会另外分配相同的map/reduce任务到其他闲置worker上运行，达到backup task（备份任务）的效果（因为函数式，map/reduce以相同输入执行最后会产生相同输出，所以执行多少次都不会有问题）。

通过backup task，性能不会受限于最慢的几个worker，因为有更快的worker会领先它们完成task（map或reduce）。这是应对straggler的普遍做法，通过replicate tasks复制任务，获取更快完成task的输出结果，处理了tail latency尾部延迟问题。

常见问题总结回顾

在远程读取进程中，文件是否会传输到reducer？

会。map函数产生的中间结果存放在执行map函数的worker机器的磁盘上，而之后解调器分配文件给reducer执行reduce函数时，中间结果数据需要通过网络传输到reducer机器上。这里其实很少有网络通信，因为一个worker在一台机器上，而每台机器同时运行着worker进程和GFS进程。worker运行map产生中间结果存储在本地，而之后协调器给worker分配文件以执行reduce函数时，才需要通过网络获取中间结果数据，最后reduce处理完在写入GFS，写入GFS的动作也往往需要通络传输。

协调器是否负责对数据进行分区，并将数据分发到每个worker或机器上？

不是的。mapreduce运行用户程序，这些输入数据在GFS中。（也就是说协调器告知worker从GFS取哪些数据进行map，后续协调器又告知worker从哪些worker机器上获取中间结果数据进行reduce，最后又统一写入到GFS中）

排序是如何工作的？比如谁负责排序，如何排序？

中间结果数据传递到reduce函数之前，mapreduce库进行一些排序。比如所有的中间结果键a、b、c到一个worker。比如(a,1) (b,1) (c,1) (a,1) 数据，被排序成(a,1) (a,1) (b,1) (c,1) 后才传递给reduce函数。

map是否会被执行两次？

如果coordinator没有收到worker反馈task任务完成，那么会coordinator重新分配worker要求执行task（可能分配到同一个worker，重点是task会被重新执行）
或许没反馈task执行done完成的worker是遇到网络分区等问题，并没有宕机，或者协调者不能与worker达成网络通信，但实际上worker仍然在运行map任务，它正在产生中间结果。

同一个map可以被运行两次。 被执行两次是能够接受的（幂等性问题），正是map和reduce属于函数式(functional)的原因之一。如果map/reduce是一个funcitonal program，那么使用相同输入运行时，产生的输出会是相同的（也就是保证幂等）。

reduce能够被执行两次吗？

reduce和map出于相同的原因，从容错的角度上看，执行reduce函数和map函数并没有太大区别。需要注意的是，这时候可能有两个reducer同时有相同的输出文件需要写入GFS，它们首先在全局文件系统GFS中产生一个中间文件，然后进行atomic rename原子重命名，将文件重命名为实际的最终名称。因为在GFS中执行的重命名是原子操作，最后哪个reducer胜出并不重要，因为reduce是函数式的，它们最终输出的数据都是一样的。