与其他系统相比

MapReduce似乎采用的是一种蛮力方法。每个查询需要处理整个数据集——或至少 数据集的很大一部分。反过来想，这也正是它的能力。MapReduce是一个批量查询处理器，并且它能够在合理的时间范围内处理针对整个数据集的即时(ad hoc)査询。它改变了我们对数据的传统看法，并且解放了以前存储在磁带和磁盘上的数据。它赋予我们对数据进行创新的机会。那些以前需要很长时间处理才能获得结果的问题现在已经迎刃而解，但也引发了新的问题和见解。

例如，Rackspace的邮件部门Mailtrust,使用Hadoop处理邮件日志。他们写的即席査询是找出用户的地理分布。他们是这么描述的： “这些数振是非常有用的，我们每月运行一次MapReduce任务来帮助我们决定哪些 RackSpace数据中心需要添加新的邮件服务器。”

通过整合数百GB的数据，并用MapReduce分析这些数据，Rackspace的工程师们从中了解到以前没有留意的数据，并且，他们可以运用这些信息改善现有的服务。 第16章将详细介绍RackSpace公司是如何运用Hadoop的。

关系型数据库管理系统

我们为什么不能使用数据库来对大量磁盘上的大规模数据进行批量分析呢？我们为什么需要MapReduce?

这些问题的答案来自磁盘的另一个发展趋势：寻址时间的提高远远慢于传输速率的提高。寻址是将磁头移动到特定磁盘位置进行读写操作的过程。它是导致磁盘操作延迟的主要原因，而传输速率取决于磁盘的带宽。

如果数据的访问模式中包含大量的磁盘寻址，那么读取大量数据集所花的时间势必会更长(相较于流式数据读取模式)，流式读取主要取决于传输速率。另一方面，如果数据库系统只更新一小部分记录，那么传统的B树更有优势(关系型数据库中使用的一种数据结构，受限于寻址的比例）。但数据库系统更新大部分数据时，B树的效率比MapReduce低得多，因为需要使用“排序/合并”(sort/merge)来重建数据库。

在许多情况下，可以将MapReduce视为关系型数据库管理系统的补充。两个系统之间的差异如表1-1所示。MapReduce比较适合以批处理的方式处理需要分析整个 数据集的问题，尤其是即席分析。RDBMS适用于“点査询”（point query)和更新，数据集被索引后，数据库系统能够提供低延迟的数据检索和快速的少量数据更新。MapReduce适合一次写入、多次读取数据的应用，而关系型数据库更适合持续更新的数据集。

MapReduce和关系型数据库之间的另一个区别在于它们所操作的数据集的结构化程度。结构化数据(structured data)是具有既定格式的实体化数据，诸如XML文档 或满足特定预定义格式的数据库表。这是RDBMS包括的内容。另一方面，半结构化数据(semi-structured data)叫比较松散，虽然可能有格式，但经常被忽略，所以它只 能用作对数据结构的一般指导。例如，一张电子表格，其结构是由单元格组成的网格，但是每个单元格自身可保存任何形式的数据。非结构化数据(unstructured data)没有什么特别的内部结构，例如纯文本或图像数据。MapReduce对于非结构化或半结构化数据非常有效，因为在处理数据时才对数据进行解释。换句话说：MapReduce输入的键和值并不是数据固有的属性，而是由分析数据的人员来选择的。

关系型数据往往是规范的(normalized)，以保持其数据的完整性且不含冗余。规范化给MapReduce带来了问题，因为它使记录读取成为异地操作，然而MapReduce 的核心假设之一就是，它可以进行(髙速的)流式读写操作。

Web服务器日志是一个典型的非规范化数据记录(例如，每次都需要记录客户端主机全名，导致同一客户端全名可能会多次出现），这也是MapReduce非常适合用于分析各种日志文件的原因之一。

MapReduce是一种线性可伸缩的编程模型。程序员编写两个函数，分别为map函数和reduce函数一每个函数定义一个键/值对集合到另一个键/值对集合的映射。这些函数无需关注数据集及其所用集群的大小，因此可以原封不动地应用到小规模数据集或大规模的数据集上。更重要的是，如果输入的数据量是原来的两倍，那么 运行的时间也需要两倍。但是如果集群是原来的两倍，作业的运行仍然与原来一样快。SQL査询一般不具备该特性。

但是在不久的将来，关系型数据库系统和MapReduce系统之间的差异很可能变得模糊。关系型数据库都开始吸收MapReduce的一些思路（如Aster DATA的和GreenPlum的数据库），另一方面，基于MapReduce的髙级査询语言(如Pig和Hive) 使Mapreduce的系统更接近传统的数据库编程方式。

网格计算

髙性能计算(High Performance Computing, HPC)和网格计算(Grid Computing)组织多年来一直在研究大规模数据处理，主要使用类似于消息传递接口（Message Passing Interface,MPI)的API。从广义上讲，高性能计算的方法是将作业分散到集 群的各台机器上，这些机器访问由存储区域网络(SAN)组织的共享文件系统。这比 较适用于计算密集型的作业，但如果节点需要访问更大量的数据(几百个GB的数据，这时MapReduce开始发挥其优势），那么很多计算节点会由于网络带宽的瓶颈问题而空闲下来等待数据。

MapReduc会尽量在计算节点上存储数据，以实现数据的本地快速访问。数据本地化(data locality)特性是MapReduce的核心特征，并因此而获得良好的性能。意识到网络带宽是数据中心环境最珍贵的资源（到处复制数据很容易耗尽网络带宽）之后，MapReduce通过显式网络拓扑结构尽力保留网络带宽。注意，这种排列方式并未降低MapReduce的计算密集型的数据分析能力。

MPI赋予了程序员极大的控制能力，但是需要程序员显式控制数据流机制，包括通过C语言构造低层次的功能模块(例如套接字）和高层次的数据分析算法。而MapReduce则在更高层次上执行任务，即程序员仅从键/值对函数的角度考虑任务的执行，这样数据流是隐含的。

在大规模分布式计算环境下，协调各进程间的执行是一个很大的挑战。最困难的是合理地处理系统部分失效问题————在不知道一个远程进程是否已失效的情况下————同时还需要继续完成整个计算。MapReduce让程序员无需考虑系统的部分失效问题，因为自身的系统实现能够检测到失败的map或reduce任务，并让正常运行的机器重新执行这些失败的任务。正是由于采用了无共享（shared-nothing）框架，所以 MapReduce才能够实现失败检测，这意味着各个任务之间彼此独立。（这里讲得过于简单了一点，因为MapReduce系统本身控制着mapper的输出结果传给reducer 的过程；这种情况下，重新运行reducer比重新运行mapper更需要格外小心，因为reducer需要获取必要的mapper的输出结果，如果没有获得必要的输出结果，必须再次运行相关mapper重新生成输出结果。）因此，从程序员的角度来看，任务的执行顺序是无关紧要的。相比之下，MPI程序必须显式地管理自身的检查点 和恢复机制，尽管更多的控制权交给了程序员，但也加大了编程的难度。

MapReduce听起来似乎是一个相当严格的编程模型，而且在某种意义上看，它的确如此：用户被限定于使用具有特定关联的键/值对，mapper和reducer彼此间可做的协调非常有限(每个mapper将键/值对传给reducer)。由此自然会联想到一个问题：能用该编程模型做一些有用或不普通的事情吗？

答案是肯定的。MapReduce是由谷歌的工程师开发的，用于构建搜索引擎的索引，并且他们证明了它能够一次又一次地解决这一索引问题。MapReduce的灵感 来自于传统的函数式编程、分布式计算和数据库社区，此后该模型在其他行业有着很多其他的应用。我们惊喜地发现，有许多算法可以使用MapReduce来表达，从图像图形分析到各类基于图像分析的问题，再到机器学习算法。当然，它不能解决所有问题，但它确实是一个比较通用的数据处理工具。

志愿计算

人们第一次听说Hadoop和MapReduce的时候，经常会问：“它们和SETI@home 有什么不同？” SETI,全称为Search for Extra-Terrestrial Intelligence(搜寻外星智慧），执行着一个称为SETI@home的项目(http://setiathome.berkeley.edu)。在该项目中，志愿者把自己计算机CPU的空闲时间贡献出来分析无线天文望远镜的数据，借此寻找外星智慧生命信号。SETI@home因拥有大量志愿者而非常出名，其 他还有Great Internet Mersenne Prime search(捜索大素数）与Folding@home项目（了 解蛋白质构成及其与疾病之间的关系）。

志愿计算项目将他们试图解决的问题分成多个块，每个块称为一个工作单元(work unit)并将它们发到世界各地的电脑上进行分析。例如，SETI@home的工作单元是 约0.35 MB的无线电望远镜数据，分析这样的数据，一台普通计算机需要数小时 或数天。完成分析后，结果被发送回服务器，之后客户端获得另一个工作单元。为 防止欺骗，每个工作单元被送到3台不同的机器上执行，且至少收到两个相同结果才被接受。

虽然表面上看起来，SETI@home与MapReduce比较相似(将问题分为独立的块，然后进行并行计算），但依旧还有很多显著的差异。SETI@home问题是CPU高度密集的，比较适合在全世界成千上万的计算机上运行，因为用于计算的时间会远大于工作单元数据的传输时间。志愿者贡献的是CPU周期，而非网络带宽。

MapReduce的设计目标是服务于那些只需数分钟或数小时即可完成的作业，并且运行于内部通过髙速网络连接的单一数据中心内，并且该数据中心内的计算机需要由可靠的、定制的硬件构成。相比之下，SETl@home则需要在接入互联网的不可信的计算机上长期运行，这些计算机具有不同网络带宽，且对数据本地化没有要求。