在Hadoop框架中最著名的就是MapReduce组件，它的处理逻辑来源于谷歌的旧三驾马车之一——MapReduce。

MapReduce是解决问题并行任务的一种模型，将一个可拆解的任务分散到多个计算节点进行计算，最后合并计算结果。

例如，现在需要解决一个问题：尽可能以比较快的速度统计一个图书馆在书架上一共陈列了多少本书。

图 统计图书馆的书

一种方法是，找一个在数数方面有超高本领的人，由他一个人来完成;另一种方法是，雇用一大批资质平庸的负责统计图书数量的人和一个负责分配任务的人，由分配任务的人负责划分区域，确保每个人都分到一部分要统计的书架，不重不漏。然后对所有的人下发开始统计的指令，统计图书的人将自己负责的区域统计完成记录到纸上，所有统计图书的人上交统计结果后，负责分配任务的人将所有人的统计结果进行累加，得到图书统计的结果。如果中途有人因为一些意外原因发生计数终止，那么就再派一个人前去重新完成他未完成的工作任务。

不难想象，如果方法得当，后一种方法要比前一种方法靠谱一些。

这个有超高本领的人是不是容易被找到，他一个人会不会有失误，他的薪水要求是不是太高，这些问题的可控性会变得非常不好。而资质平庸的人通常在市场供应方面不会让我们那么担心，只要统计的方法论和调度方式没有问题，不仅这种方式的风险更小，而且成本更低，速度更快，MapReduce就是这样一种并行机制。

下面从辩证的角度来看这种机制的优点和缺点。优点如下：

(1)隐藏大量技术细节。开发人员不需要关注容灾管理、负载均衡和并行计算实现的代码部分，只需要调用相关的API，设置参数即可。

(2)可伸缩性好。在Map阶段，可以实现每增加一台服务器就将计算能力接入到集群里，而且能实现在集群运行时添加计算节点(一般用在线扩容这个技术名词来描述这一特点)。缺点如下

(1)实时性差。和磁盘交互频繁，中间要多次将计算结果保存到磁盘，使实时计算能力大打折扣。

(2)编程习惯需要适应。需要将在学习《数据结构》或者算法理论中学习到的算法实现方式转换成为MapReduce方式，编程时需要特意构建这种程序逻辑。而且这种方式的局限性导致并非所有的问题都适合用MapReduce方式进行解决。

虽然有不少缺点，但是Hadoop仍然是目前离线计算的利器。