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、非死book和《紐約時報》。(一些應用在第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。