虽然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阶段:
- 一开始先把输入数据集切分成M片，每片一般16~64MB
- map完成时通知master，master记录所有map的完成情况和文件位置
- map tasks要切得小而多，建议远大于机器数，容易负载均衡（3个task分给2个node，均衡度肯定不如13个task分给2个node）
- map tasks尽量分配到靠近数据的node，以节省带宽
- 用combine函数做本地预合并，以减小map的输出结果集
Reduce阶段：
- reducer从mapper node下载输入文件
- reduce先写临时文件，完成时用原子的文件重命名操作
- reduce用lazy iterator读取输入，以节省内存
全阶段：
- map输出到本地文件，reduce输出到全局文件
- map和reduce都可有多个副本同时重复执行，谁快就用谁的结果（即使有个副本突然变慢，也有别的副本在跑）
- 总有一些落后进程，增加百分之几的备用资源，就能加速扫除长尾，节省百分之几十的时间
- 调度器尽量把任务分配给空闲的worker，因此速度快的worker自然会处理更多tasks
- 遇到错误的record，写标记到master，再有task遇到时跳过它
注释：
这种“总有一些落后进程”的现象叫做尾部延迟放大(tail delay amplification)，分布式数据库执行查询的scatter/gatter模式也有此问题。
Google的解法相当于task rebalance，来个比喻：让先进员工帮助落后员工完成积压的任务，以保证全团队的项目按时完成。
我们要知道，“计算易移动，数据难移动”，我们总是倾向于把计算移动到另一处，而不是把数据移过去。
MapReduce就是移动了计算，并且把计算尽可能移动到数据附近。task rebalance只移动计算，无需移动数据，所以才管用。
而分布式数据库在执行查询时，把计算分发到data node上，如果有的data node反应慢，就没有办法，因为数据不好移。
