理论上，只需要写一个Map函数和一个Reduce函数。
实际上，在使用的背后，要理解框架究竟干了什么，即如何处理核心的容错与性能问题。
1. 容错需要处理哪些场景
需求前提：
- 大量数据中，个别数据出错不影响整体结果。例如1亿条数据，错了10条，不影响大局；
- 计算成本，重新发送比分析更高效。例如，重新在chunk server上计算一个64M的数据块，比起对整个结果重新分析排序要划算得多。
| 场景 | 措施 |
|---|---|
| 1.MapReduce是C/S架构，那么Master Server失败，要怎么处理？ | 整个任务失败，最好能自恢复 |
| 2.Map或Reduce函数在Chunk Server上执行失败，要怎么处理？ | 换台chunk server，重新执行 |
| 3.海量数据中，出现个别数据Map或Reduce执行失败，要怎么处理？ | 记录出错的行号，跳过 |
2. 性能还有哪些可以优化的
背景：与GFS类型，在论文发表的时候，网络带宽是主要的瓶颈。
解决思路：分析整个数据传输链条，减少传输的环节。
可能的办法有：减少传输次数，能局域网就不走互联网，在Map与Reduce函数的结果传递方式上想办法等。
| 思路 | 方法 |
|---|---|
| 1.就近传递 | 计算时找同一台机器上的数据。如果找不到，就找附近机器上的数据 |
| 2.快者优先 | 如果MapReduce程序（本身也是数据）比要计算的数据小的多，比如10k vs 64M，那么把程序送到数据所在的机器上更快速 |
| 3.缩小中间数据 | 在Map与Reduce函数处理的过程中，加上中间函数Combiner。考虑到2/8原则，把数据量大的结果先行进行合并。比如1亿条中，有8千万是10个主要网站的信息。那么合并后key/value的数据量会显著减少 |
总结
容错还是要结合业务来做，哪些是必须保证正确率的，哪些是可以允许重试、脏数据的。从Google的业务来看，MapReduce是可以满足“网页数据分析”这个场景的。但不是每种业务都允许这样的策略。
性能优化，除了程序本身的（算法）效率，还要关注硬件、网络。当然，这里也能理解为什么Google在招聘中对算法的高要求了，这与业务本身的关系很大。处理海量数据，算法的效率做不到极致，带来的就是计算资源和商业机会的浪费。对于操作系统、硬件、网络的基础是否牢固，也决定了最终方案设计的质量。
计算的基础确实非常重要。
