前言
打算跟着 MIT 的20年春季课程节奏一起通过4个 lab 来更加深刻和系统的来认识和实现分布式系统。我会坚持把每个学习节点和心得和笔记给记录下来。
每个 lec 之前一般要先看甩上来的论文，我之前虽然知晓大数据三驾马车论文大名，但是也从来没有仔细看过。这次花了2天认认真真看了 MapReduce 论文之后真是觉得即使放在现在，其实也不是非常过时的思考。 MR 目前也在服务 hive 等系统。
Abstract view of MapReduce
首先要理解 MR 模式背后的思想就是把问题分解成多个部分，然后切成片之后交由 map 模式的机器 reduce 模式的机器进行解决。
由于问题被分解，我们可以切成非常多份，同时交给多个 map 程序进行处理，处理完之后交给 reduce 程序进行结果输出。
就像下面课程里提到的一样
input is divided into M files
[diagram: maps generate rows of K-V pairs, reduces consume columns]
Input1 -> Map -> a,1 b,1 c,1
Input2 -> Map -> b,1
Input3 -> Map -> a,1 c,1
| | |
| | -> Reduce -> c,2
| -----> Reduce -> b,2
---------> Reduce -> a,2
MR calls Map() for each input file, produces set of k2,v2
"intermediate" data
each Map() call is a "task"
MR gathers all intermediate v2's for a given k2,
and passes them to a Reduce call
final output is set of <k2,v3> pairs from Reduce()
stored in R output files
[diagram: MapReduce API --
map(k1, v1) -> list(k2, v2)
reduce(k2, list(v2) -> list(k2, v3)]
可以看到这里就是将输入分成好几份（这里是三份）然后进行分别的统计，把它 Map 成 (key, 1) (key, 1) (k2, 1) (k3, 1) 这样的 最后 Reduce 对其进行汇总就生成了一个典型的 work count MR 程序。
MapReduce 解决了哪些问题
MR 帮助开发者隐藏了很多分布式软件背后的运行细节。MR 会去帮我们跟踪什么任务结束了，数据的 shuffle 计算转移，cover failures 。
MR 好编程同时 MR 有良好的扩展性，MR 除了在 shuffle 阶段都不会进行交互，所以我们要增加吞吐量，增加机器就好了，更多的机器带来更强大的并行算力。
通过高层次的 MR 抽象模型来拟合绝大多数的大数据计算场景。使其计算变得简单。
MapReduce 的运行细节
从论文直接摘要下来的图，MR 由 master 来分发任务。
需要输入的数据最先存储在 GFS 上，一般是三副本存储。所有的 worker 最好都同时运行 GFS 和 MR woker 这样可以方便从本地取到数据。
一般 MR 切分的任务会远远超出节点 worker 数量，比如 Map 任务会等前面任务执行完之后继续获得 master 分配的新任务进行执行。
在所有 Map 任务结束前不会有 Reduce 任务开始执行。当 Map 任务运行完成之后 master 会告诉 Reduce 任务中间数据在 Map worker 的本地磁盘位置，然后 Reduce 程序会通过 RPC 将中间数据取回进行计算最后输出最后的文件到 GFS ，一个 Reduce task 会输出一个 文件。
为了加快文件读取的速度，如果可以 Map 一般会读取 input 的本机副本以减少网络传输带来的消耗，根据经验将超大规模数据在网络中移来移去是消耗性能的注意问题之一。所以很多算法和框架都尽量避免此类情况的发生。
MR 如何解决负载均衡和容错问题
通过生成远远超过 woker 的任务，让速度快的机器多执行一些任务，速度慢的机器就是执行一些。上面有提到过在执行 MR 任务的时候会等到一个执行完成之后才会开始执行另外一个。如果一个机器执行得非常快，那么他会多执行一些任务，反之就少执行一些以达到均衡。
那么万一在执行 MR 任务的时候 crash 了呢？我们需要将整个程序重新开始一次以进行容错吗？答案是我们只需要将失败的 Map 和 Reduce 任务执行即可。因为 MR 的整个过程包括我们设计的 Map Reduce 函数需要是幂等和无状态的，这样无论我们运行多少次，只要保证输入的结果，我们能得到相同的输出结果。这对于 MR 很重要。
针对 Crash Recovery 分为两部分
Map worker 的 recovery
master 会周期性的 ping Map woker ，如果对方主机长时间没有回应，那么因为 Map woker 将中间数据保存到内存缓存并周期性的将其刷新到磁盘，所以如果 woker 不可以访问了，那么中间数据就丢失了。 master 会将该任务分配给其他有 input 副本的 GFS Map worker 进行 re-run。在此期间如果如果 Reduce 已经读取全部中间数据，那么继续执行没问题，但是如果这个时候 Reduce crash 了，那么会触发重新在其他节点执行失败的 Map 程序。
Reduce worker 的 recovery
如果任务已经执行完成，输出结果会存在 GFS 这没有问题。如果没有执行完，那么 master 会调度这个任务去其他节点上执行。
Reduce 如果输出 output 没有结束，那么它输出的文件是无法访问的临时文件。输出完成之后 Reduce 会调用系统的 rename 原语对文件进行重命名以表示完成。
最后丢出一些奇怪的 trobleshooting 问答
Other failures/problems:
* What if the master gives two workers the same Map() task?
perhaps the master incorrectly thinks one worker died.
it will tell Reduce workers about only one of them.
* What if the master gives two workers the same Reduce() task?
they will both try to write the same output file on GFS!
atomic GFS rename prevents mixing; one complete file will be visible.
* What if a single worker is very slow -- a "straggler"?
perhaps due to flakey hardware.
master starts a second copy of last few tasks.
* What if a worker computes incorrect output, due to broken h/w or s/w?
too bad! MR assumes "fail-stop" CPUs and software.
* What if the master crashes?
recover from check-point, or give up on job
Refenrece:
https://pdos.csail.mit.edu/6.824/schedule.html 6.824 Schedule: Spring 2020
https://pdos.csail.mit.edu/6.824/papers/mapreduce.pdf Mapreduce 论文
https://pdos.csail.mit.edu/6.824/notes/l01.txt 2020 Lecture 1: Introduction
https://pdos.csail.mit.edu/6.824/video/1.html feb4 Mapreduce 现场课程