xxxfreesexmoves-haodiaocao这里只有精品视频-欧美性受黑人性爽-欧美性受xxxxxx黑人xyx性爽|www.jsyyzsb.com

關于我們
新書資訊
新書推薦

Hadoop權威指南(第3版)

Hadoop權威指南(第3版)

定     價：¥99

中 教 價：¥62.37  (6.30折）

庫 存 數： 0

  • 作者：（美）Tom White
  • 出版時間：2015/1/1
  • ISBN：9787302370857
  • 出 版 社：清華大學出版社
  • 中圖法分類：TP274-62 
  • 頁碼：716
  • 紙張：膠版紙
  • 版次：3
  • 開本：16開
  • 商品庫位：
9
7
3
8
7
7
0
3
8
0
5
2
7
購買數量：     

準備好釋放數據的強大潛能了嗎？借助于這本《Hadoop權威指南》，你將學習如何使用Apache Hadoop構建和維護穩定性高、伸縮性強的分布式系統。本書是為程序員寫的，可幫助他們分析任何大小的數據集。本書同時也是為管理員寫的，幫助他們了解如何設置和運行Hadoop集群。

 

本書通過豐富的案例學習來解釋Hadoop的幕后機理，闡述了Hadoop如何解決現實生活中的具體問題。第3版覆蓋Hadoop的最新動態，包括新增的MapReduce API，以及MapReduce2及其靈活性更強的執行模型（YARN）。

 

 

傳統的關系型數據庫

MapReduce

數據大小

GB

PB

數據存取

交互式和批處理

批處理

更新

多次讀/寫

一次寫入，多次讀取

結構

靜態模式

動態模式

完整性

高

低

橫向擴展

非線性的

線性的

 

MapReduce和關系型數據庫之間的另一個區別在于它們所操作的數據集的結構化程度。結構化數據(structureddata)是具有既定格式的實體化數據，如XML文檔或滿足特定預定義格式的數據庫表。這是RDBMS包括的內容。另一方面，半結構化數據(semi-structured data)比較松散，雖然可能有格式，但經常被忽略，所以它只能作為對數據結構的一般性指導。例如電子表格，它在結構上是由單元格組成的網格，但是每個單元格內可以保存任何形式的數據。非結構化數據(unstructureddata)沒有什么特別的內部結構，例如純文本或圖像數據。MapReduce對非結構化或半結構化數據非常有效，因為它是在處理數據時才對數據進行解釋。換句話說，MapReduce輸入的鍵和值并不是數據固有的屬性，而是由分析數據的人來選的。^

關系型數據往往是規范的(normalized)，以保持其數據的完整性且不含冗余。規范給MapReduce帶來了問題，因為它使記錄讀取成為非本地操作，而MapReduce的核心假設之一偏偏就是可以進行(高速的)流讀寫操作。^

Web服務器日志是典型的非規范化數據記錄(例如，每次都需要記錄客戶端主機全名，這會導致同一客戶端的全名可能多次出現)，這也是MapReduce非常適用于分析各種日志文件的原因之一。^

MapReduce是一種線性的可伸縮編程模型。程序員要寫兩個函數，分別為map函數和reduce函數，每個函數定義從一個鍵值對集合到另一個鍵值對集合的映射。這些函數不必關注數據集及其所用集群的大小，可以原封不動地應用于小規模數據集或大規模的數據集。更重要的是，如果輸入的數據量是原來的兩倍，那么運行時間也需要兩倍。但如果集群是原來的兩倍，作業的運行速度卻仍然與原來一樣快。SQL查詢一般不具備該特性。^

但是，在不久的將來，關系型數據庫系統和MapReduce系統之間的差異很可能變得模糊。關系型數據庫都開始吸收MapReduce的一些思路(如Aster Data的數據庫和GreenPlum的數據庫)，另一方面，基于MapReduce的高級查詢語言(如Pig和Hive)使傳統數據庫的程序員更容易接受MapReduce系統。[6]^

1.3.2  網格計算^

高性能計算(High Performance Computing，HPC)和網格計算(Grid Computing)組織多年以來一直在研究大規模數據處理，主要使用類似于消息傳遞接口(MessagePassing Interface，MPI)的API。從廣義上講，高性能計算采用的方法是將作業分散到集群的各臺機器上，這些機器訪問存儲區域網絡(SAN)所組成的共享文件系統。這比較適用于計算密集型的作業，但如果節點需要訪問的數據量更龐大 (高達幾百GB，MapReduce開始施展它的魔法)，很多計算節點就會因為網絡帶寬的瓶頸問題不得不閑下來等數據。^

MapReduc盡量在計算節點上存儲數據，以實現數據的本地快速訪問。[7]數據本地化(datalocality)特性是MapReduce的核心特征，并因此而獲得良好的性能。意識到網絡帶寬是數據中心環境最珍貴的資源(到處復制數據很容易耗盡網絡帶寬)之后，MapReduce通過顯式網絡拓撲結構來保留網絡帶寬。注意，這種排列方式并沒有降低MapReduce對計算密集型數據進行分析的能力。^

雖然MPI賦予程序員很大的控制權，但需要程序員顯式控制數據流機制，包括用C語言構造底層的功能模塊(例如套接字)和高層的數據分析算法。而MapReduce則在更高層次上執行任務，即程序員僅從鍵值對函數的角度考慮任務的執行，而且數據流是隱含的。^

在大規模分布式計算環境下，協調各個進程的執行是一個很大的挑戰。最困難的是合理處理系統的部分失效問題——在不知道一個遠程進程是否掛了的情況下——同時還需要繼續完成整個計算。有了MapReduce，程序員不必操心系統部分失效的問題，因為它自己的系統實現能夠檢測到并重新執行那些失敗的map或reduce任務。正因為采用的是無共享(shared-nothing)框架，MapReduce才能夠實現失敗檢測，這意味著各個任務之間是彼此獨立的。[8]因此，從程序員的角度來看，任務的執行順序無關緊要。相比之下，MPI程序必須顯式管理自己的檢查點和恢復機制，雖然賦予程序員的控制權加大了，但編程的難度也增加了。^

MapReduce聽起來似乎是一個相當嚴格的編程模型，而且在某種意義上看的確如此：限定用戶使用有特定關聯的鍵值對，mapper和reducer彼此間的協調非常有限(每個mapper將鍵值對傳給reducer)。由此，我們自然聯想到一個問題：能用這個編程模型做一些有用或實際的事情嗎？^

答案是肯定的。MapReduce由谷歌的工程師開發，用于構建搜索引擎的索引，而且，事實已經證明它能夠一次又一次地解決這個問題(MapReduce 的靈感來自于傳統的函數式編程、分布式計算和數據庫社區)，但此后，該模型在其他行業還有著很多其他的應用。我們欣喜地發現，有很多算法都可以用MapReduce來表達，從圖像圖形分析到各種各樣基于圖像分析的問題，再到機器學習算法。[9]當然，它也不是包治百病的靈丹妙藥，不能解決所有問題，但它真的是一個很通用的數據處理工具。^

我們將在第16章介紹Hadoop的一些典型應用。^


1.3.3  志愿計算^

人們第一次聽說Hadoop和MapReduce的時候，經常會問這個問題：“它們和SETI@home有什么不同？”SETI全稱為Searchfor Extra-Terrestrial Intelligence(搜索外星智能)，項目名稱為SETI@home(http://setiathome.berkeley.edu)。在該項目中，志愿者把自己計算機CPU的空閑時間貢獻出來分析無線天文望遠鏡的數據，借此尋找外星智慧生命信號。SETI@home因為擁有龐大的志愿者隊伍而非常出名，其他還有“搜索大素數”(Great Internet MersennePrime Search)項目與Folding@home項目(了解蛋白質構成及其與疾病之間的關系)。^

志愿計算項目將問題分成很多塊，每一塊稱為一個工作單元(work unit)，發到世界各地的計算機上進行分析。例如，SETI@home的工作單元是0.35 MB無線電望遠鏡數據，要對這等大小的數據量進行分析，一臺普通計算機需要幾個小時或幾天時間才能完成。完成分析后，結果發送回服務器，客戶端隨后再獲得另一個工作單元。為防止欺騙，每個工作單元要發送到3臺不同的機器上執行，而且收到的結果中至少有兩個相同才會被接受。^

從表面上看，SETI@home與MapReduce好像差不多(將問題分解為獨立的小塊，然后并行進行計算)，但事實上還是有很多明顯的差異。SETI@home問題是CPU高度密集的，比較適合在全球成千上萬臺計算機上運行，[10]因為計算所花的時間遠遠超過工作單元數據的傳輸時間。也就是說，志愿者貢獻的是CPU周期，而不是網絡帶寬。^

MapReduce有三大設計目標：(1)為只需要短短幾分鐘或幾個小時就可以完成的作業提供服務；(2)運行于同一個內部有高速網絡連接的數據中心內；(3)數據中心內的計算機都是可靠的、定制的硬件。相比之下，SETI@home則是在接入互聯網的不可信的計算機上長時間運行，這些計算機的網絡帶寬不同，對數據本地化也沒有要求。^


1.4  Hadoop發展簡史^

Hadoop是Apache Lucene創始人Doug Cutting創建的，Lucene是一個應用廣泛的文本搜索系統庫。Hadoop起源于開源的網絡搜索引擎Apache Nutch，它本身也是Lucene項目的一部分。^

Hadoop的得名

Hadoop不是縮寫，它是一個生造出來的詞。Hadoop之父Doug Cutting這樣解釋Hadoop的來歷：

“這個名字是我的小孩給他的毛絨象玩具取的。我的命名標準是好拼讀，含義寬泛，不會被用于其他地方。小孩子是這方面的高手。Googol就是小孩子起的名字。”

 

Hadoop的子項目及后續模塊所使用的名稱也往往與其功能不相關，通常也以大象或其他動物為主題取名(例如Pig)。較小一些的組件，名稱通常都有較好的描述性(因此也更流俗)。這個原則很好，意味著我們可以望文知義，例如jobtracker[11]，一看就知道它是用來跟蹤MapReduce作業的。

 

從頭打造一個網絡搜索引擎是一個雄心勃勃的計劃，不只是因為寫爬蟲程序很復雜，更因為必須有一個專職團隊來實現——項目中包含許許多多需要隨時修改的活動部件。同時，構建這樣的系統代價非常高——據Mike Cafarella和Doug Cutting估計，一個支持10億網頁的索引系統，單是硬件上的投入就高達50萬美元，另外還有每月高達3萬美元的運維費用。[12]不過，他們認為這個工作仍然值得投入，因為它開創的是一個優化搜索引擎算法的平臺。^

Nutch項目開始于2002年，一個可以運行的網頁爬取工具和搜索引擎系統很快面試。但后來，開發者認為這一架構的靈活性不夠，不足以解決數十億網頁的搜索問題。一篇發表于2003年的論文為此提供了幫助，文中描述的是谷歌產品架構，該架構稱為“谷歌分布式文件系統”，簡稱GFS。[13]GFS或類似的架構，可以解決他們在網頁爬取和索引過程中產生的超大文件的存儲需求。特別關鍵的是，GFS能夠節省系統管理(如管理存儲節點)所花的大量時間。在2004年，他們開始著手做開源版本的實現，即Nutch分布式文件系統(NDFS)。^

2004年，谷歌發表論文向全世界介紹他們的MapReduce系統。[14]2005年初，Nutch的開發人員在Nutch上實現了一個MapReduce系統，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS來運行。^

Nutch的NDFS和MapReduce實現不只適用于搜索領域。在2006年2月，開發人員將NDFS和MapReduce移出Nutch形成Lucene的一個子項目，命名為Hadoop。大約在同一時間，Doug Cutting加入雅虎，雅虎為此組織了專門的團隊和資源，將Hadoop發展成能夠處理Web數據的系統(參見后面的補充材料“Hadoop在雅虎“)。在2008年2月，雅虎宣布，雅虎搜索引擎使用的索引是在一個擁有1萬個內核的Hadoop集群上構建的。[15]^

2008年1月，Hadoop已成為Apache的頂級項目，證明了它的成功、多樣化和生命力。到目前為止，除雅虎之外，還有很多公司在用Hadoop，例如Last.fm、Facebook和《紐約時報》等。第16章和Hadoop 維基頁面(英文)介紹了一些案例(http://wiki.apache.org/hadoop/PoweredBy)。^

《紐約時報》的案例廣為流傳，他們把1851 年到 1980 年的存檔掃描之后得到4 TB的文件并用亞馬遜的EC2云服務將文件存為PDF格式放到網上共享。[16]整個過程一共使用了100臺計算機，所花的時間不到24小時。如果沒有亞馬遜的按小時付費模式(即允許《紐約時報》短期內訪問大量機器)和Hadoop好用的并發編程模型珠聯璧合，這個項目不太可能這么快就啟動和完成。^

2008年4月，Hadoop打破世界紀錄，成為最快的TB級數據排序系統。在一個910節點的群集，Hadoop在209 秒內(不到3.5分鐘)完成了對1TB數據的排序，擊敗了前一年的297秒冠軍(詳情參見15.5節的補充材料“ApacheHadoop的TB級數據處理”)。同年11月，谷歌在報告中聲稱，它的MapReduce對1 TB數據排序只用了68秒。[17]2009年5月本書第1版出版的時候，有報道稱雅虎有一個的團隊使用 Hadoop對1 TB數據進行排序只花了62秒。^

從那以后，Hadoop躍升為企業主流的部署系統。在工業界，Hadoop已經是公認的大數據通用存儲和分析平臺，這一事實主要體現在大量直接使用或者間接輔助Hadoop系統的產品如雨后春筍般大量涌現。一些大公司也發布Hadoop發行版本，包括EMC，IBM，Microsft和Oracle以及一些專注于Hadoop的公司，如Cloudera，Hortonworks[18]和MapR。^

Hadoop在雅虎^

作者：Owen O’Melly

^

構建互聯網規模的搜索引擎離不開大量的數據，因此也離不開大量的機器來處理巨量的數據。雅虎搜索引擎(Yahoo！Search)有4個主要組成部分：Crawler，從網頁服務器爬取網頁；WebMap，構建一個已知網頁的鏈接圖；Indexer，為最佳頁面構建一個反向索引；Runtime，處理用戶的查詢。WebMap生成的鏈接圖非常大，大約包括一萬億(1012)條邊(每條邊代表一個網頁鏈接)和一千億(1011)個節點(每個節點代表不同的網址)。創建并分析如此大的圖需要大批計算機很多天長時間運行。到2005年初，WebMap用的底層架構Dreadnaught需要重新設計以便日后擴展到更多的節點。^

Dreadnaught從20個節點成功擴展到600個，但需要完全重新設計才能進一步擴大。Dreadnaught與MapReduce在很多方面都很相似，但靈活性更強，結構也更松散。說具體點，一個Dreadnaught作業的每一個片斷(fragment，也稱“分塊”)都可以輸送到下一階段的各個片段繼續執行，排序則是通過庫函數來完成的。但實際情形是，大多數WebMap階段是兩兩一對，對應于MapReduce。因此，WebMap應用不需要做大量重構操作就可以適應MapReduce。

Eric Baldeschwieler(Eric14)組建了一個小團隊，于是我們開始設計并在GFS和MapReduce上用C++來建立一個新框架的原型，并打算用它來取代Dreadnaught。盡管我們的當務之急是需要一個新的WebMap框架，但更清楚的是，建立雅虎搜索引擎批處理平臺的標準對我們更重要。使平臺更通用以便支持其他用戶，才能夠更好地實現新平臺的均衡性投資。

與此同時，我們也關注在Hadoop(當時也是Nutch的一部分)及其進展情況。2006年1月，雅虎聘請了Doug Cutting。一個月后，我們決定放棄原型，轉而采用 Hadoop。與我們的原型和設計相比，Hadoop的優勢在于它已經在20 個節點上實際應用過(Nutch)。這樣一來，我們便能在兩個月內搭建一個研究集群并能夠以很快的速度幫助我們的客戶使用這個新的框架。另一個顯著的優點是Hadoop已經開源，比較容易(盡管也不是想象的那么容易！)從雅虎法務部門獲得許可對該開源系統進行進一步研究。因此，我們在2006年初建立了一個200節點的研究集群并暫時擱置WebMap計劃，轉而為研究用戶提供Hadoop支持和優化服務。

Hadoop大事記

2004年

Doug Cutting和Mike Cafarella實現了HDFS和MapReduce的初版

2005年12月

Nutch移植到新框架，Hadoop在20個節點上穩定運行

2006年1月

Doug Cutting加入雅虎

2006年2月

Apache Hadoop項目正式啟動，支持MapReduce和HDFS獨立發展

2006年2月

雅虎的網格計算團隊采用Hadoop

2006年4月

在188個節點上(每節點10 GB)運行排序測試集需要47.9個小時)

2006年5月

雅虎建立了一個300個節點的Hadoop研究集群

2006年5月

在500個節點上運行排序測試集需要42個小時(硬件配置比4月份的更好)

2006年11月

研究集群增加到600個節點

 

 


 

 

2006年12月

排序測試集在20個節點上運行1.8個小時，100個節點上運行3.3小時，500個節點上運行5.2小時，900個節點上運行7.8個小時

2007年1月

研究集群增加到900個節點

2007年4月

研究集群增加到兩個集群1000個節點

2008年4月

在900個節點上運行1 TB排序測試集僅需209秒，成為全球最快

2008年10月

研究集群每天裝載10 TB的數據

2009年3月

17個集群共24 000個節點

2009年4月

在每分鐘排序中勝出，59秒內排序500 GB(在1400個節點上)和173分鐘內排序100 TB數據(在3400個節點上)

      

 


[1] Gantz等人2008年3月發表的文章“The Diverse and Exploding Digital Universe”(紛繁多樣并不斷膨脹的數字世界)，網址為http://china.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf。^

[2] http://www.intelligententerprise.com/showArticle.jhtml?articleID=207800705；http://mashable.com/ 2008/10/15/facebook-10-billion-photos/；http://blog.familytreemagazine.com/insider/ Inside+Ancestrycoms+TopSecret+Data+Center.aspx；http://www.archive.org/about/faqs.php；
http://www.interactions.org/cms/?pid=1027032。^

[3] 編注：更多詳細介紹可以參見阮一峰的博客文章“微軟的MyLifeBits項目”，網址為http://www.ruanyifeng.com/blog/2007/12/mylifebits.html。^

[4] 引自Anand Rajaraman發表的文章“Netflix Challenge”(Negfix挑戰大賽)，網址為 http://anand.typepad.com/datawocky/2008/03more-data-usual.html。在這個挑戰大賽中，Netflix公司公開自己的用戶評分數據，讓研究者根據這些數據對用戶沒有看過的電影預測評分，誰最先比現有系統好10%，誰就能贏得100萬美元的獎金。Alon Halevy，Peter Norvig(谷歌研究主管)和Fernando Pereira在他們的一篇文章中也提出了類似的觀點，題為“TheUnreasonable Effectiveness of Data”(數據的非理性效果)，發表于IEEE Intelligent Systems 2009年3/4月合刊。

[5] 這些規格對應的是希捷的ST-41600n硬盤。

[6]  2007年1月，數據庫理論專家David J. DeWitt和Michael Stonebraker發表的論文引發一場激烈的口水大戰，論文標題為“MapReduce: A major step backwards”(MapReduce：一個巨大的倒退)，原文可參見http://databasecolumn.vertica.com/ database-innovation/mapreduce a-major-step-backwards，中文版可參考http://wap.oschina.net/question/17793_31108)。在文中，他們認為MapReduce不宜取代關系型數據庫。許多評論認為這是一種錯誤的比較，詳情可參見Mark C. Chu-Carroll的文章“Databasesare hammers; MapReduce is a screwdriver”(如果說數據庫是錘子，MapReduce則是螺絲刀)，英文版網址為http://scienceblogs.com/goodmath/2008/01 databases_are_hammers_mapreduc.php，中文版可以參考http://blog.csdn.net/ wanghai__/article/details/5954108。DeWitt與Stonebraker以“再說MapReduce”一文對其他人的觀點進行了闡述，原文可參見http://databasecolumn.vertica.com/database-innovation/mapreduce-ii，他們對其他人的主要觀點進行了闡述。

[7]  1998年圖靈獎得主Jim Gray在2003年3月發表的“DistributedComputing Economics”(分布式計算經濟學)一文中，率先提出這個結論：數據處理應該在離數據本身比較近的地方進行，因為這樣有利于降低成本，尤其是網絡帶寬消費所造成的成本。原文網址為http://research.microsoft.com/apps/pubs/default.aspx?id=70001。

[8] 這里講得太簡單了一點，因為MapReduce 系統本身控制著mapper輸出結果傳給reducer的過程，所以在這種情況下，重新運行reducer比重新運行mapper更要小心，因為reducer需要獲取必要的mapper輸出結果，如果沒有，必須再次運行對應的mapper，重新生成輸出結果。

[9] Apache Mahout(http://mahout.apache.org/)是一個在Hadoop上運行的機器學習類庫(例如分類和聚類算法)。

[10] 2008年1月，SETI@home發表評論說每天使用320 000臺計算機處理300 GB數據，同時他們也在做其他的一些數據計算，原文參見http://www.planetary.org/programs/ projects/setiathome/setiathome_20080115。

[11] 在本書中我們使用小寫的jobtracker來代表實體(泛稱)，用駝峰體JobTracker來表示對Java類的實現。

[12] Mike Cafarella和Doug Cutting在2004年4月發表在ACM Queue上的文章“Building Nutch: Open Source Search”，網址為http://queue.acm.org/detail.cfm?id=988408。

[13] Sanjay Ghemawat，Howard Gobioff和Shun-Tak Leung在2003年10月發表的文章“The Google File System”，網址為http://labs.google.com/papers/gfs.html。

[14] 參見Jeffrey Dean和Sanjay Ghemawat 2004年12月發表的文章“MapReduce: Simplified Data Processing on Large Clusters”(MapReduce: 大型集群的數據簡化處理)，網址為http://labs.google.com/papersmapreduce.html。

[15] 參見2008年2月19日發表的文章“雅虎發布全球最大的Hadoop產品應用”(Yahoo!Lauches World’s Largest Hadoop ProductionApplications)，網址為http://developer. yahoo.com/blogs/hadoop/posts/2008/ 02/yahoo-worlds-largest-production-hadoop/。

[16] 參見Derek Gottfrid在 2007年11月1日發表的文章“Self-service, Prorated Super Computing Fun!”(自助式比例分配超級計算的樂趣！)，網址為http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/。

[17] 全文參見2008年11月21日的文章“Sorting 1PB with MapReduce”(MapReduce處理1 PB數據)，網址為http://googleblog.blogspot.com/2008/11/sorting-1pb-with-mapreduce.html。

[18] 編者注：該公司是雅虎的幾個核心開發人員創辦的，主要提供Hadoop支持和咨詢服務，他們已經與微軟在2011年建立戰略合作關系，幫助微軟將Hadoop移植到Wiondows Server和Azure。

 你還可能感興趣
 我要評論
您的姓名   驗證碼： 圖片看不清？點擊重新得到驗證碼
留言內容