初识Hadoop

　　【图书连载】古代，人们用牛来拉重物。当一头牛拉不动一根圆木时，他们不曾想过培育更大更壮的牛。同样，我们也不需要尝试开发超级计算机，而应试着结合使用更多计算机系统。

　　——格蕾斯·霍珀

　　数据!数据!

　　我们生活在数据时代!很难估计全球以电子方式存储的数据总量有多少，但IDC的一项预测曾指出，“数字宇宙”(digital universe) 项目统计得出，2006年的数据总量为0.18 ZB，并预测在2011年，数据量将达到1.8 ZB。[1] 1 ZB 等于1021 字节，或等于1000 EB，1 000 000 PB，或是大家更熟悉的10亿TB 的数据!这相当于世界上每人一个磁盘驱动器所能容纳数据的数量级。

　　数据“洪流”有很多来源。以下面列出的部分为例。[2]

　　纽约证券交易所每天产生1 TB 的交易数据。

　　Facebook存储着约100 亿张照片，约1 PB 存储容量。

　　Ancestry.com，一个家谱网站，存储着2.5 PB 数据。

　　The Internet Archive(互联网档案馆)存储着约2 PB 的数据，并以每月至少

　　20 TB的速度增长。

　  瑞士日内瓦附近的大型强子对撞机每年产生约15 PB 的数据。

　　此外还有大量数据。但是你可能会想它对自己有何影响。大部分数据严密保存(locked up)在一些大型互联网公司(如搜索引擎公司)，或科学机构，或金融机构，难道不是吗?难道所谓的“大数据”的出现会影响到较小的组织或个人?

　　我认为是这样的。以照片为例，我妻子的祖父是一个狂热的摄影爱好者。成年之后，他经常拍照片。整个照片集，包括普通胶片、幻灯片、35 mm胶片，在扫描成高解析度图片之后，大约有10 GB。相比之下，2008年我家用数码相机拍摄的 照片就有5 GB。我家照片数据的生成速度是我妻子祖父的35 倍!并且，这个速度还在不断增加，因为拍摄照片变得越来越容易了。

　　更一般的情况是，个人数据的产生量正在快速地增长。微软研究院的MyLifeBits项目(http://research.microsoft.com/en-us/projects/mylifebits/default.aspx)显示，在不久的将来，将普及个人信息档案。MyLifeBits是这样的一个实验：获取并存储个人与外界的联系情况(电话、邮件和文件)，以供后期访问。收集的数据中包括每分钟拍摄的照片等，其数据量达到每月1 GB左右。当存储成本下降得足够多，以至于可以存储连续音频和视频时，未来MyLifeBits项目所存储的数据量将是现在的许多倍。

　　目前的趋势是保存每个人成长过程中产生的所有数据，但更重要的是，计算机产生的数据可能比个人产生的更多。机器日志、RFID检测器、传感器网络、车载GPS 和零售交易数据等——所有这些都将使数据量显著增加。

　　公开发布的数据量也在逐年增加。组织或企业，不仅需要管理好自己的数据，更需要从其他组织或企业的数据中获取有价值的信息，以便在未来获得更大的成功。

　　这方面的先锋，如Public Data Sets on Amazon Web Services、Infochimps.org和theinfo.org，正在培育“信息共享系统”(information commons)，任何人都可以在此自由下载和分析这些数据(例如通过AWS 平台实现共享，并以合理的价格收费)。不同来源的信息混合处理后，将带来意外的效果和今天难以想象的应用。

　　以Astrometry.net项目为例，这是一个观察和分析Flickr网站上天文小组所拍星空照片的项目。该项目分析每一张照片，并辨别出该图片是天空或其他天体(例如恒星和银河系等)的哪一部分。该项目表明，如果可用的数据足够多(在本例中，为加有标签的图片数据)，这些数据可用于数据创建者也想象不到的一些应用(例如，图片分析)。

　　曾有这么一句话：“大量的数据胜于好的算法。” 意思是说对于某些应用 (譬如基于先前偏好进行电影和音乐推荐)，不论你的算法有多好，大量可用的数据总能带来更好的推荐效果。[3]

　　现在，我们已经有了大量的数据，这对我们来说是个好消息。不幸的是，我们当下正纠结于存储和分析这些数据。

　　[1] 来自Gantz等所写的文章“The Diverse and Exploding Digital Universe”(March 2008)，网址为http://www.emc.com/collateral/analyst-reports/diverse-exploding-digital- universe.pdf。

　　[2] 来源为http://www.intelligententerprise.com/showArticle.jhtml?articleID=207800705，http://mashable.com/2008/10/15/facebook-10-billion-photos/，http://blog.familytreemagazine. com/insider/Inside+Ancestrycoms+TopSecret+Data+Center.aspx，http://www.archive.org/ about/faqs.php和http://www.interactions.org/cms/?pid=1027032。

　　[3] 引自Anand Rajaraman的文章“Netflix Challenge”(http://anand.typepad.com/datawocky/ 2008/03/ more-data-usual.html)。Alon Halevy，Peter Norvig和 Fernando Pereira在他们的文章中也给出了相似的观点，文章标题为“The Unreasonable Effectiveness of Data”(IEEE Intelligent Systems, March/April 2009)。

　　数据存储与分析

　　我们遇到的问题很简单：多年来磁盘存储容量快速增加的同时，其访问速度——磁盘数据读取速度——却未能与时俱进。1990年，一个普通磁盘可存储1370 MB的数据并拥有4.4 MB/s的传输速度，[1]因此，读取整个磁盘中的数据只需要5分钟。20年后，1 TB的磁盘逐渐普及，但其数据传输速度约为100 MB/s，因此读取整个磁盘中的数据需要约两个半小时。

　　读取一个磁盘中所有的数据需要很长的时间，写甚至更慢。一个很简单的减少读取时间的办法是同时从多个磁盘上读取数据。试想，如果我们拥有100个磁盘，每个磁盘存储1%的数据，并行读取，那么不到两分钟就可以读取所有数据。

　　仅使用磁盘容量的1%似乎很浪费。但是我们可以存储100个数据集，每个数据集1 TB，并实现共享磁盘的访问。可以想象，该类系统的用户会很乐意使用磁盘共享访问以便缩短数据分析时间;并且，从统计角度来看，用户的分析工作会在不同的时间点进行，所以互相之间的干扰不会太大。

　　尽管如此，但要实现对多个磁盘数据的并行读写，还有更多的问题要解决。

　　第一个需要解决的问题是硬件故障。一旦使用多个硬件，其中任一硬件发生故障的概率将非常高。避免数据丢失的常见做法是使用备份：系统保存数据的冗余复本，在发生故障后，可以使用数据的另一可用复本。例如，冗余磁盘阵列(RAID)就是按这个原理实现的，另外，Hadoop的文件系统，即HDFS(Hadoop Distributed FileSystem)也是一类，不过它采取的方法稍有不同。详见后文描述。

　　第二个问题是大多数分析任务需要以某种方式结合大部分数据共同完成分析任务，即从一个磁盘读取的数据可能需要和从另外99个磁盘中读取的数据结合使用。各种分布式系统允许结合多个来源的数据并实现分析，但保证其正确性是一个非常大的挑战。MapReduce提出了一个编程模型，该模型将上述磁盘读写的问题进行抽象，并转换为对一个数据集(由键/值对组成)的计算。后文将详细讨论该模型，需要指出的是，该计算由map和reduce两部分组成，而只有这两部分提供对外的接口。与HDFS类似，MapReduce自身也具有较高的可靠性。

　　简而言之，Hadoop提供了一个可靠的共享存储和分析系统。HDFS实现存储，而MapReduce实现分析处理。纵然Hadoop还有其他功能，但这两部分是它的核心。

　　[1] 这些规格针对的是Seagate ST-41600n。

　　与其他系统相比

　　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适合一次写入、多次读取数据的应用，而关系型数据库更适合持续更新的数据集。

　　表1-1. 关系型数据库和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 的系统更接近传统的数据库编程方式。[1]

　　[1] 2007年1月，David J. DeWitt和Michael Stonebraker发表的论文“MapReduce: A major step backwards”(http://databasecolumn.vertica.com/database-innovation/mapreduce- a-major-step-backwards)引起了人们的争论。在文中，他们认为MapReduce不适合替代关系型数据库。许多评论认为这是一种错误的比较(参见Mark C. Chu-Carroll的文章“Databasesare hammers; MapReduce is a screwdriver”(http://scienceblogs.com/ goodmath/2008/01/databases_are_hammers_mapreduc.php)及DeWitt与Stonebraker 的回复“MapReduce II”(http://databasecolumn.vertica.com/database-innovation/mapreduce-ii)，他们对评论的主要观点进行了阐述。

　　网格计算

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

　　MapReduc会尽量在计算节点上存储数据，以实现数据的本地快速访问。[1]数据本地化(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来表达，从

　　图像图形分析到各类基于图像分析的问题，再到机器学习算法。[2]当然，它不能解决所有问题，但它确实是一个比较通用的数据处理工具。

　　我们将在第16章介绍Hadoop的一些典型应用。

　　[1] Jim Gray首先支持在存储数据附近的机器上进行计算。参见“Distributed Computing

　　Economics”(March 2003), 网址为http://research.microsoft.com/apps/pubs/default.aspx? id=70001。

　　[2] Apache Mahout(http://mahout.apache.org/)是一个在Hadoop上运行的机器学习类库(例如分类和聚类算法)。

　　志愿计算

　　人们第一次听说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高度密集的，比较适合在全世界成千上万的计算机上运行，[1]因为用于计算的时间会远大于工作单元数据的传输时间。志愿者贡献的是CPU周期，而非网络带宽。

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

　　[1] 2008年1月，SETI@home发表评论说每天使用320 000台计算机处理300 GB数据，同时他们也在做其他的一些数据计算，http://www.planetary.org/programs /projects/setiathome/setiathome_20080115。

　　Hadoop发展简史

　　Hadoop是Apache Lucene创始人Doug Cutting创建的，Lucene是一个广泛使用的文本搜索系统库。Hadoop起源于Apache Nutch，一个开源的网络搜索引擎， 它本身也是Lucene项目的一部分。

　　Hadoop名字的起源

　　Hadoop这个名字不是一个缩写，它是一个虚构的名字。该项目的创建者 Doug Cutting如下解释Hadoop这一名称的来历：

　　“这个名字是我的孩子给一头吃饱了的棕黄色大象取的。我的命名标准是简 短，容易发音和拼写，没有太多的含义，并且不会被用于别处。小孩子是这方面的高手。Googol就是小孩子起的名字。”

　　Hadoop的子项目及后续模块所使用的名称也往往与其功能不相关，通常也以 大象或其他动物为主题取名(例如“Pig”)。较小一些的组件，名称通常具有较好的描述性(也因此更俗)。这个原则很好，这意味着你可以通过它的名字大致猜测它的功能，例如，jobtracker[1]用于跟踪MapReduce作业。

　　从头开始构建一个网络搜索引擎是一个雄心勃勃的计划，不仅是因为编写一个爬取并索引网页的软件比较复杂，更因为这个项目需要一个专门的团队来实现——项目中包含许多需要随时修改的组件。同时，构建这样一个系统的代价非常高——据Mike Cafarella和Doug Cutting估计，一个支持10亿网页的索引系统单是硬件上的投入就高达50万美元，另外每月运行维护费用也高达3万美元。[2]不过，他们认为这项工作仍然是值得的，因为它开创了优化搜索引擎算法的平台。

　　Nutch项目始于2002年，一个可以运行的网页爬取工具和搜索引擎系统很快“浮出水面”。但后来，开发者认为这一架构可扩展度不够，不能解决数十亿网页的搜索问题。2003年发表的一篇论文为此提供了帮助，文中描述的是谷歌产品架构，该架构称为谷歌分布式文件系统，简称GFS。[3]GFS或类似的架构，可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。特别关键的是，GFS能够节省系统管理(如管理存储节点)所花的大量时间。在2004年，他们开始着手实现一个开源的实现，即Nutch的分布式文件系统(NDFS)。

　　2004年，谷歌发表论文向全世界介绍他们的MapReduce系统。[4]2005年初，Nutch的开发人员在Nutch上实现了一个MapReduce系统，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS来运行。

　　Nutch的NDFS和MapReduce实现不只是适用于搜索领域。在2006年2月， 开发人员将NDFS和MapReduce移出Nutch形成Lucene的一个子项目，称为 Hadoop。大约在同一时间， Doug Cutting加入雅虎，雅虎为此组织了一个专门的团队和资源，将Hadoop发展成一个能够处理Web数据的系统(见第11页的补充材料)。在2008年2月，Yahoo!宣布其搜索引擎使用的索引是在一个拥有1万个内核的Hadoop 集群上构建的。[5]

　　2008年1月，Hadoop已成为Apache的优异项目，证明了它的成功、多样化、活跃性。到目前为止，除Yahoo!之外，还有很多公司使用了Hadoop，例如Last.fm、 Facebook和《纽约时报》等。第16章和Hadoop wiki都介绍了一些案例，Hadoop wiki的网址为http://wiki.apache.org/hadoop/PoweredBy。

　　《纽约时报》是一个很好的宣传范例，他们将扫描往年报纸获得的4 TB存档文件通过亚马逊的EC2云计算转换成PDF文件，并上传到网上。[6]整个过程使用了100台计算机，历时不到24小时。如果不将亚马逊的按小时付费的模式(即允许《纽约时报》短期内访问大量机器)和Hadoop 易于使用的并发编程模型结合起来，该项目很可能不会这么快开始启动并完成。

　　2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统。通过一个910节点的群集，Hadoop在209 秒内(不到三分半钟) 完成了对1 TB数据的排序，击败了前一年的297秒冠军(详情参见第553页的“Apache Hadoop TB级数据排序”小节)。同年11月，谷歌在报告中声称，它的MapReduce对1 TB数据排序只用了68秒。[7]本书第1版出版的时候(2009年5月)，有报道称Yahoo!的团队使用 Hadoop对1 TB数据进行排序只花了62秒。

　　[1] Mike Cafarella和Doug Cutting的文章“Building Nutch: Open Source Search”(ACM Queue, April 2004)，网址为http://queue.acm.org/detail.cfm?id=988408。

　　[2] Sanjay Ghemawat，Howard Gobioff和Shun-Tak Leung的文章“The Google File System”(October 2003)，网址为http://labs.google.com/papers/gfs.html。

　　[3] 本书中我们使用小写形式(如jobtracker)来表示对实体的应用，代码形式(如JobTracker)来表示对Java类的实现。

　　[4] Jeffrey Dean和Sanjay Ghemawat的文章“MapReduce: Simplified Data Processing on Large Clusters”(December 2004)，网址为http://labs.google.com/papers/mapreduce.html。

　　[5] 参见“Yahoo! Lauches World’s Largest Hadoop ProductionApplications”(Feb. 19, 2008)，网址为http://developer.yahoo.com/blogs/hadoop/posts/2008/02/yahoo-worlds-largest-production-hadoop/。

　　[6] Derek Gottfrid的文章“Self-service, Prorated Super Computing Fun!”(Nov. 1，2007)，网址为http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/。

　　[7] “Sorting 1PB with MapReduce”(Nov. 21，2008)，http://googleblog.blogspot.com/2008/11/ sorting-1pb-with-mapreduce.html。

　　Yahoo!的Hadoop

　　构建互联网规模的搜索引擎需要大量的数据，因此需要大量的机器来进行处理。Yahoo!Search有4个主要组成部分：Crawler，从网页服务器爬取网页;WebMap，构建一个已知网页的链接图;Indexer，为非常好的页面构建一个反向索引;Runtime，处理用户的查询。WebMap构建的链接图非常大，大约包括一万亿条边(每条边代表一个网页链接)和一千亿个节点(每个节点代表不同的网址)。创建并分析如此大的图需要大量计算机运行若干天。2005年初，WebMap所用的底层架构称为Dreadnaught，需要重新设计使其可以扩展到更多的节点。Dreadnaught 成功地从20个节点扩展到600个，但需要一个完全重新的设计，才能进一步扩大。Dreadnaught与MapReduce在很多方面都很相似，但灵活性更强且结构更松散。具体说来，Dreadnaught工作的每一个片断(fragment，也称“分块“)都可以输送到下一阶段的各个片断继续执行，而排序是通过库函数完成的。但实际情形是，大多数WebMap阶段是两两构成一对，并对应于一个MapReduce。因此，WebMap应用不需要做大量的重构操作，便可以适应MapReduce。

　　Eric Baldeschwieler(Eric14)组建了一个小团队，于是我们开始设计并在GFS和MapReduce上用C++来建立一个新框架的原型，最后用它来取代Dreadnaught。尽管我们的当务之急是需要一个WebMap新框架，但更清楚的是，标准化Yahoo! Search的批处理平台对我们更重要。使平台更通用以便支持其他用户，才能够更好地实现新平台的均衡性投资。

　　与此同时，我们关注Hadoop(当时还是Nutch的一部分)及其进展情况。2006年1月，Yahoo!聘请了Doug Cutting。一个月后，我们决定放弃我们的原型，转而采用 Hadoop。与我们的原型和设计相比，Hadoop的优势在于它已经在20 个节点上实际应用过(Nutch)。这样一来，我们便能在两个月内搭建一个研究集群，并能够更快地帮助我们的客户使用这个新的框架。另一个显著的优点是Hadoop已经开源，较容易(尽管也不是太容易!)从Yahoo!法务部门获得许可对该开源系统进行进一步研究。因此，我们在2006年初构建了一个200个节点的研究集群，并将WebMap的计划暂时搁置，转而为研究用户使用Hadoop提供支持以及进一步开发。

　　Hadoop大事记

　　l 2004年——由Doug Cutting 和Mike Cafarella实现了现在HDFS和MapReduce的最初版本。

　　l 2005年12月——Nutch移植到新框架，Hadoop在20 个节点上稳定运行。

　　l 2006年1月——Doug Cutting加入Yahoo!。

　　l 2006年2月——Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。

　　l 2006年2月——Yahoo!的网格计算团队采用Hadoop。

　　l 2006年4月——在188个节点上(每个节点10 GB)运行排序测试集需要47.9个小时。

　　l 2006年5月——Yahoo!建立了一个300个节点的Hadoop研究集群。

　　l 2006年5月——在500个节点上运行排序测试集需要42个小时(硬件配置比4月的更好)。

　　l 2006年11月——研究集群增加到600个节点。

　　l 2006年12月——排序测试集在20个节点上运行1.8个小时，100个节点上运行3.3小时，500个节点上运行5.2小时，900个节点上运行7.8个小时。

　　l 2007年1月——研究集群增加到900个节点。

　　l 2007年4月——研究集群增加到两个1000个节点的集群。

　　l 2008年4月——在900个节点上运行1 TB排序测试集仅需209秒，成为世界最快。

　　l 2008年10月——研究集群每天装载10 TB的数据。

　　l 2009年3月——17个集群总共24 000台机器。

　　l 2009年4月——赢得每分钟排序，59 秒内排序500 GB(在1400个节点上)和173分钟内排序100 TB 数据(在3400个节点上)。

　　(作者：Owen O’Melly)

　　Apache Hadoop和Hadoop生态圈

　　尽管Hadoop因MapReduce及其分布式文件系统(HDFS，由NDFS改名而来)而出名，但Hadoop这个名字也用于一组相关项目的统称，这些相关项目都使用这个基础平台进行分布式计算和海量数据处理。

　　本书所提到的大多数核心项目都受Apache软件基金会支持，该基金会对开源软件项目的组织提供支持，其中包括最初的HTTP Server项目。随着Hadoop生态圈的成长，出现了越来越多的项目，其中不乏一些非Apache主管的项目，这些项目对 Hadoop是个很好的补充，或提供一些更高层的抽象。

　　本书所提到的Hadoop项目简述如下。

　　Common

　　一组分布式文件系统和通用I/O的组件与接口(序列化、Java RPC和持久化数据结构)。

　　Avro

　　一种支持高效、跨语言的RPC以及永久存储数据的序列化系统。

　　MapReduce

　　分布式数据处理模型和执行环境，运行于大型商用机集群。

　　HDFS

　　分布式文件系统，运行于大型商用机集群。

　　Pig

　　一种数据流语言和运行环境，用以检索非常大的数据集。Pig 运行在MapReduce和HDFS的集群上。

　　Hive

　　一个分布式、按列存储的数据仓库。Hive管理HDFS中存储的数据，并提供基于 SQL的查询语言(由运行时引擎翻译成MapReduce作业)用以查询数据。

　　HBase

　　一个分布式、按列存储数据库。HBase使用HDFS作为底层存储，同时支持MapReduce的批量式计算和点查询(随机读取)。

　　ZooKeeper

　　一个分布式、可用性高的协调服务。ZooKeeper提供分布式锁之类的基本服务用于构建分布式应用。

　　Sqoop

　　在数据库和HDFS之间高效传输数据的工具。