1.2　Hadoop生態介紹

1.2.1　Hadoop簡介

Hadoop起源于Apache Nutch，后者是一個開源的網絡搜索引擎，本身也是Lucene項目的一部分。

Hadoop這個名字不是一個縮寫，它是一個虛構的名字。該項目的創建者Doug Cutting如此解釋Hadoop的得名：“這個名字是我孩子給一頭吃飽了的棕黃色大象起的名字。我的命名標準就是簡短、容易發音和拼寫，沒有太多的意義，并且不會被用于別處。小孩子是這方面的高手。Googol就是由小孩命名的。”（Google來源于Googol一詞。GooGol指的是10的100次冪（方），代表互聯網上的海量資源。公司創建之初，肖恩·安德森在搜索該名字是否已經被注冊時，將Googol誤打成了Google。）

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和《紐約時報》。一些應用在Hadoop維基網站上有介紹，Hadoop維基的網址為http://wiki.apache.org/hadoop/PoweredBy。

有一個良好的宣傳范例，《紐約時報》使用亞馬遜的EC2云計算將4TB的報紙掃描文檔壓縮，轉換為用于Web的PDF文件。這個過程歷時不到24小時，使用100臺機器同時運行。如果不結合亞馬遜的按小時付費的模式（即允許《紐約時報》在很短的一段時間內訪問大量機器）和Hadoop易于使用的并行程序設計模型，該項目很可能不會這么快開始啟動。

2008年4月，Hadoop打破世界紀錄，成為最快排序1TB數據的系統，運行在一個910個節點的集群上，Hadoop在209秒內排序了1 TB的數據（還不到3.5分鐘），擊敗了前一年費時297秒的冠軍。同年11月，谷歌在報告中聲稱，它的MapReduce實現了執行1 TB數據的排序只用68秒。2009年5月，有報道稱Yahoo的團隊使用Hadoop對1 TB的數據進行排序，只花了62秒。

構建互聯網規模的搜索引擎需要大量的數據，因此需要大量的機器來進行處理。Yahoo！Search包括四個主要組成部分：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月，雅虎聘請了Doug Cutting，一個月后，決定放棄自己的原型，轉而使用Hadoop。相較于雅虎自己的原型和設計，Hadoop的優勢在于它已經在20個節點上實際應用過。這樣一來，雅虎便能在兩個月內搭建一個研究集群，并著手幫助真正需要的客戶使用這個新的框架，速度比原來預計的要快許多。另一個明顯的優點是Hadoop已經開源，較容易（雖然遠沒有那么容易）從雅虎法務部門獲得許可。因此，雅虎在2006年初設立了一個200個節點的研究集群，他們將WebMap的計劃暫時擱置，轉而為研究用戶支持和發展Hadoop。