Hadoop发展历史

Hadoop这个名字不是一个缩写，它是一个虚构的名字。该项目的创建者，Doug Cutting如此解释Hadoop的得名：”这个名字是我孩子给一头吃饱了的棕***大象命名的。我的命名标准就是简短，容易发音和拼写，没有太多的意义，并且不会被用于别处。小孩子是这方面的高手。Googol就是由小孩命名的。”
Hadoop及其子项目和后继模块所使用的名字往往也与其功能不相关，经常用一头大象或其他动物主题(例如：”Pig”)。较小的各个组成部分给与更多描述性(因此也更俗)的名称。这是一个很好的原则，因为它意味着可以大致从其名字猜测其功能，例如，jobtracker 的任务就是跟踪MapReduce作业。
从头开始构建一个网络搜索引擎是一个雄心勃勃的目标，不只是要编写一个复杂的、能够抓取和索引网站的软件，还需要面临着没有专有运行团队支持运行它的挑战，因为它有那么多独立部件。同样昂贵的还有：据Mike Cafarella和Doug Cutting估计，一个支持此10亿页的索引需要价值约50万美元的硬件投入，每月运行费用还需要3万美元。 不过，他们相信这是一个有价值的目标，因为这会开放并最终使搜索引擎算法普及化。
Nutch项目开始于2002年，一个可工作的抓取工具和搜索系统很快浮出水面。但他们意识到，他们的架构将无法扩展到拥有数十亿网页的网络。在 2003年发表的一篇描述Google分布式文件系统(简称GFS)的论文为他们提供了及时的帮助，文中称Google正在使用此文件系统。 GFS或类似的东西，可以解决他们在网络抓取和索引过程中产生的大量的文件的存储需求。具体而言，GFS会省掉管理所花的时间，如管理存储节点。在 2004年，他们开始写一个开放源码的应用，即Nutch的分布式文件系统(NDFS)。
2004年，Google发表了论文，向全世界介绍了MapReduce。 2005年初，Nutch的开发者在Nutch上有了一个可工作的MapReduce应用，到当年年中，所有主要的Nutch算法被移植到使用MapReduce和NDFS来运行。
Nutch中的NDFS和MapReduce实现的应用远不只是搜索领域，在2006年2月，他们从Nutch转移出来成为一个独立的Lucene 子项目，称为Hadoop。大约在同一时间，Doug Cutting加入雅虎，Yahoo提供一个专门的团队和资源将Hadoop发展成一个可在网络上运行的系统(见后文的补充材料)。在2008年2月，雅虎宣布其搜索引擎产品部署在一个拥有1万个内核的Hadoop集群上。
2008年1月，Hadoop已成为Apache顶级项目，证明它是成功的，是一个多样化、活跃的社区。通过这次机会，Hadoop成功地被雅虎之外的很多公司应用，如Last.fm、Facebook和《纽约时报》。(一些应用在第14章的案例研究和Hadoop维基有介绍，Hadoop维基的网址为 http://wiki.apache.org/hadoop/PoweredBy。)
有一个良好的宣传范例，《纽约时报》使用亚马逊的EC2云计算将4 TB的报纸扫描文档压缩，转换为用于Web的PDF文件。 这个过程历时不到24小时，使用100台机器运行，如果不结合亚马逊的按小时付费的模式(即允许《纽约时报》在很短的一段时间内访问大量机器)和 Hadoop易于使用的并行程序设计模型，该项目很可能不会这么快开始启动。
2008年4月，Hadoop打破世界纪录，成为最快排序1TB数据的系统。运行在一个910节点的群集，Hadoop在209秒内排序了1 TB的数据(还不到三分半钟)，击败了前一年的297秒冠军。同年11月，谷歌在报告中声称，它的MapReduce实现执行1TB数据的排序只用了68 秒。 在2009年5月，有报道宣称Yahoo的团队使用Hadoop对1 TB的数据进行排序只花了62秒时间。
构建互联网规模的搜索引擎需要大量的数据，因此需要大量的机器来进行处理。Yahoo！Search包括四个主要组成部分：Crawler，从因特网下载网页；WebMap，构建一个网络地图；Indexer，为最佳页面构建一个反向索引；Runtime(运行时)，回答用户的查询。WebMap是一幅图，大约包括一万亿条边(每条代表一个网络链接)和一千亿个节点(每个节点代表不同的网址)。创建和分析此类大图需要大量计算机运行若干天。在 2005年初，WebMap所用的基础设施名为Dreadnaught，需要重新设计以适应更多节点的需求。Dreadnaught成功地从20个节点扩展到600个，但需要一个完全重新的设计，以进一步扩大。Dreadnaught与MapReduce有许多相似的地方，但灵活性更强，结构更少。具体说来，每一个分段(fragment)，Dreadnaught作业可以将输出发送到此作业下一阶段中的每一个分段，但排序是在库函数中完成的。在实际情形中，大多数WebMap阶段都是成对存在的，对应于MapReduce。因此，WebMap应用并不需要为了适应MapReduce而进行大量重构。
Eric Baldeschwieler(Eric14)组建了一个小团队，我们开始设计并原型化一个新的框架(原型为GFS和MapReduce，用C++语言编写)，打算用它来替换Dreadnaught。尽管当务之急是我们需要一个WebMap新框架，但显然，标准化对于整个Yahoo! Search平台至关重要，并且通过使这个框架泛化，足以支持其他用户，我们才能够充分运用对整个平台的投资。
与此同时，我们在关注Hadoop(当时还是Nutch的一部分)及其进展情况。2006年1月，雅虎聘请了Doug Cutting，一个月后，我们决定放弃我们的原型，转而使用Hadoop。相较于我们的原型和设计，Hadoop的优势在于它已经在20个节点上实际应用过。这样一来，我们便能在两个月内搭建一个研究集群，并着手帮助真正的客户使用这个新的框架，速度比原来预计的快许多。另一个明显的优点是Hadoop 已经开源，较容易(虽然远没有那么容易！)从雅虎法务部门获得许可在开源方面进行工作。因此，我们在2006年初设立了一个200个节点的研究集群，我们将WebMap的计划暂时搁置，转而为研究用户支持和发展Hadoop。

本文转自追光的猫博客51CTO博客，原文链接http://blog.51cto.com/ql0722/1656010如需转载请自行联系原作者

00_yatou