大数据基础笔记(4)：为什么MapReduce这么设计

有了GFS这样的分布式存储，

• Google会用它来做什么？
• 给什么样的人用？
• 会遇到哪些问题？
• 如何解决（设计）？

1. 问题

问题	思考
1.GFS拿来做什么用？	搜索引擎网页分析、机器学习、信息聚类、生成报表、图计算等
2.给什么人用？	数据分析师，开发工程师等。重点是，这些人对分布式技术不了解
3.会遇到哪些问题？	由于使用者对GFS的分布式技术不是很了解，直接用GFS的门槛较高，因此需要提供一个简单易上手的框架(屏蔽底层复杂的细节)
4.如何解决（设计）？	下面开始分析

2. 分析

拿最简单的词频统计作为例子：

输入：一个英文网页，包含了莎士比亚的经典文章

处理：统计文章中出现频率最高的词

输出：返回频率最高的词，及其在文章中出现的次数

2.1 暴力解法

假设这篇文章为2000个单词，这个程序完全可以在单机搞定。处理的逻辑也很简单，这里不做展开。

2.2 数据量规模扩大

文章的规模这时变为2TB。

• 单机的内存无法满足
• 计算能力也超出范围

考虑用多台计算机，分布式计算来处理。如果把文章变成抓取的网页，这个问题就是Google可能会面对的实际问题，而且处理的要求会多种多样。

3. 解决思路

3.1 要求

既然考虑用多台计算机分布式计算来解决，那么：

1. 算法应该是可替换的，即将计算的函数作为模板，由用户提供；
2. 由于输入会被拆分发送到计算的服务器上，最好能将输入标准化，即处理的数据结构最好单一。否则，模板化很难实现。例如，对输入执行map函数统一处理为key-value。
3. 计算完毕，执行用户提供的函数实现汇总，得到最终结果。例如，对处理后的内容进行归纳，执行reduce函数。
4. 在这个过程中，可能需要优化。即不同节点处理的数据在执行归纳之前，需要根据需要进行分组。就像洗牌一样，在最后发牌时能根据需要方便地拿到自己想要的牌。例如，执行shuffle函数（混洗）。

3.2 用Map/Reduce统计词频的过程

4. 总结

与常见的应用框架类似，

• MapReduce抽象了分布式计算的基本流程；
• 提供了模板骨架，即接口；
• 屏蔽了用户不需要关心的底层细节。

这些思路在其他的系统设计案例中也会频繁遇到，可以对照总结。