虽然Google的MapReduce论文很老了（十多年），但只要还没看，就值得一看。

概要

MapReduce是一种重视容错性的分布式并行计算模式，它把分布式并行计算分为map和reduce两个阶段：

• map: 把输入数据集切分成很多份（1份可包含很多records），传给map函数做转换处理（每次处理1条record，得出1条结果），结果集被输出到文件
• reduce: 读取map的结果集，传给reduce函数做归约处理（每次处理1条record，更新一条共享的结果），结果集被输出到文件

数据通常是key-value格式的，像HashMap，key关联着value。key是连接map和reduce的纽带，reduce通过key来拉取相关的map结果，把关联某个key的一批values归约成一个收敛的结果。

每台机器是一个node。map和reduce都可以在很多worker node上运行。1个任务=1个函数+1组输入数据，任务被分配到worker node上运行。有一个中央的调度器，叫做master node，来进行全局调度，给worker node分配任务。

示意图就不贴了，到处可见的WordCount例子也不写了，别人写过的我一般不写。请参考网络资料。例如这篇就挺好：https://mr-dai.github.io/mapr...

参考好了吗？继续吧！

优化

论文指出它是为大量廉价机器组成的环境而设计的，环境特点是：机器特别多，机器性能参差不齐，有的机器会突然坏掉。论文的很多优化都是在解决这种环境所特有的问题，这在当时是开创性的，因为一般的分布式并行技术都还在研究一组性能均等的高性能机器，不能容忍某台机器变慢或故障。现在工业界都是用MapReduce的方式在搞，因为多数企业的环境都是论文里说的这种。

Google推出MapReduce论文时已经考虑周密了，给出了很多优化点：
Map阶段:

1. 一开始先把输入数据集切分成M片，每片一般16~64MB
2. map完成时通知master，master记录所有map的完成情况和文件位置
3. map tasks要切得小而多，建议远大于机器数，容易负载均衡（3个task分给2个node，均衡度肯定不如13个task分给2个node）
4. map tasks尽量分配到靠近数据的node，以节省带宽
5. 用combine函数做本地预合并，以减小map的输出结果集

Reduce阶段：

1. reducer从mapper node下载输入文件
2. reduce先写临时文件，完成时用原子的文件重命名操作
3. reduce用lazy iterator读取输入，以节省内存

全阶段：

1. map输出到本地文件，reduce输出到全局文件
2. map和reduce都可有多个副本同时重复执行，谁快就用谁的结果（即使有个副本突然变慢，也有别的副本在跑）
3. 总有一些落后进程，增加百分之几的备用资源，就能加速扫除长尾，节省百分之几十的时间
4. 调度器尽量把任务分配给空闲的worker，因此速度快的worker自然会处理更多tasks
5. 遇到错误的record，写标记到master，再有task遇到时跳过它

注释：
这种“总有一些落后进程”的现象叫做尾部延迟放大(tail delay amplification)，分布式数据库执行查询的scatter/gatter模式也有此问题。
Google的解法相当于task rebalance，来个比喻：让先进员工帮助落后员工完成积压的任务，以保证全团队的项目按时完成。
我们要知道，“计算易移动，数据难移动”，我们总是倾向于把计算移动到另一处，而不是把数据移过去。
MapReduce就是移动了计算，并且把计算尽可能移动到数据附近。task rebalance只移动计算，无需移动数据，所以才管用。
而分布式数据库在执行查询时，把计算分发到data node上，如果有的data node反应慢，就没有办法，因为数据不好移。