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。