Hadoop发展简史
Hadoop是Apache Lucene创始人Doug Cutting创建的，Lucene是一个广泛使用的文本搜索系统库。Hadoop起源于ApaCheNutCh，一个开源的网络搜索引擎，它本身也是Lucene项目的一部分。
Hadoop名字的起源
Hadoop这个名字不是一个缩写，它是一个虚构的名字。该项目的创建者Doug Cutting如下解释Hadoop这一名称的来历：
这个名字是我的孩子给一头吃饱了的棕黄色大象取的。我的命名标准是简短，容易发音和拼写，没有太多的含义，并且不会被用于别处。小孩子是这方面的高手。googol就是小孩子起的名字。
Hadoop的子项目及后续模块所使用的名称也往往与其功能不相关，通常也以大象或其他动物为主题取名(例如“Pig”）。较小一些的组件，名称通常具有较好的描述性(也因此更俗）。这个原则很好，这意味着你可以通过它的名字大致猜测它的功能，例如，jobtracker用于跟踪MapReduce作业。
从头开始构建一个网络搜索引擎是一个雄心勃勃的计划，不仅是因为编写一个爬取并索引网页的软件比较复杂，更因为这个项目需要一个专门的团队来实现————项目中包含许多需要随时修改的组件。同时，构建这样一个系统的代价非常髙————据Mike Cafarella Cutting估计，一个支持10亿网页的索引系统单是硬件上的投入就髙达50万美元，另外每月运行维护费用也髙达3万美元。不过，他们认为这项工作仍然是值得的，因为它开创了优化搜索引擎算法的平台。
Nutch项目始于2002年，一个可以运行的网页爬取工具和搜索引擎系统很快“浮出水面”。但后来，开发者认为这一架构可扩展度不够，不能解决数十亿网页的搜索问题。2003年发表的一篇论文为此提供了帮办，文中描述的是谷歌产品架构， 该架构称为谷歌分布式文件系统，简称GFS。GFS或类似的架构，可以解决他们在网页爬取和索引过程中产生的超大文件的存储需求。特别关键的是，GFS能够节省系统管理(如管理存储节点)所花的大量时间。在2004年，他们开始着手实现一个开源的实现，即Nutch的分布式文件系统(NDFS)。
2004年，谷歌发表论文向全世界介绍他们的MapReduce系统。2005年初，Nutch 的开发人员在Nutch上实现了一个MapReduce系统，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS来运行。
Nutch的NDFS和MapReduce实现不只是适用于搜索领域。在2006年2月，开发人员将NDFS和MapReduce移出Nutch形成Lucene的一个子项目，称为 Hadoop。大约在同一时间，Doug Cutting加入雅虎，雅虎为此组织了一个专门的团队和资源，将Hadoop发展成一个能够处理Web数据的系统。在2008年2月，Yahoo!宣布其搜索引擎使用的索引是在一个拥有1万个内核的Hadoop集群上构建的。
2008年1月，Hadoop已成为Apache的顶级项目，证明了它的成功、多样化、活跃性。到目前为止，除Yahoo！之外，还有很多公司使用了Hadoop，例如Last.fm、Facebook和《纽约时报》等。
《纽约时报》是一个很好的宣传范例，他们将扫描往年报纸获得的4TB存档文件通过亚马逊的EC2云计算转换成PDF文件，并上传到网上。整个过程使用了100 台计算机，历时不到24小时。如果不将亚马逊的按小时付费的模式(即允许《纽约时报》短期内访问大量机器)和Hadoop易于使用的并发编程模型结合起来，该项目很可能不会这么快开始启动并完成。
2008年4月，Hadoop打破世界纪录，成为最快的TB级数据排序系统。通过一个 910节点的群集，Hadoop在209秒内(不到三分半钟）完成了对1TB数据的排序，击败了前一年的297秒冠军。同年11月，谷歌在报告中声称，它的MapRedUCe对1TB数据排序只用了68秒。本书第1版出版的时候(2009年5月），有报道称Yahoo！的团队使用Hadoop对1TB数据进行排序只花了62秒。
Yahoo!的 Hadoop
构建互联网规模的搜索引擎需要大量的数据，因此需要大量的机器来进行处理。Yahoo! Search有4个主要组成部分：Crawler,从网页服务器爬取网页； WebMap,构建一个已知网页的链接图；Indexer,为最佳页面构建一个反向索 引；Runtime,处理用户的查询。WebMap构建的链接图非常大，大约包括一万 亿条边(每条边代表一个网页链接)和一千亿个节点(每个节点代表不同的网址)。创建并分析如此大的图需要大量计算机运行若干天。2005年初，WabMap所用的底层架构称为Dreadnaught,需要重新设计使其可以扩展到更多的节点。 Dreadnaught成功地从20个节点扩展到600个，但需要一个完全重新的设计，才能进一步扩大。Dreadnaught与MapReduce在很多方面都很相似，但灵活性更强且结构更松散。具体说来，Dreadnaught工作的每一个片断(fragment,也称“分块”)都可以输送到下一阶段的各个片断继续执行，而排序是通过库函数完成的。但实际情形是，大多数WebMap阶段是两两构成一对，并对应于一个 MapReduce。因此，WebMap应用不需要做大量的重构操作，便可以适应 MapReduce。
Eric Bladeschwieler(EricI4)组建了一个小团队，于是我们开始设计并在GFS和 MapReduce上用C++来建立一个新框架的原型,最后用它来取代 Dreadnaught。尽管我们的当务之急是需要一个WebMap新框架，但更清楚的 是，标准化Yahoo! Search的批处理平台对我们更重要。使平台更通用以便支持其他用户，才能够更好地实现新平台的均衡性投资。
与此同时，我们关注Hadoop(当时还是Nutch的一部分)及其进展情况。2006年 1月，Yahoo!聘请了 Doug Cutting。一个月后，我们决定放弃我们的原型，转而采用Hadoop。与我们的原型和设计相比，Hadoop的优势在于它已经在20个节点上实际应用过(Nutch)。这样一来，我们便能在两个月内搭建一个研究集群，并能够更快地帮助我们的客户使用这个新的框架。另一个显著的优点是Hadoop已经开源，较容易(尽管也不是太容易！）从Yahoo！法务部门获得许可对该开源系统进行进一步研究。因此，我们在2006年初构建了一个200个节点的研究集群，并将WebMap的计划暂时搁置，转而为研究用户使用Hadoop提供支持以及进一步开发。
