在云計算世界中，有一個概念最被認可，但卻很少有人理解。當被問及Apache Hadoop時，絕大部分企業(yè)都會將其看做是***的云計算數(shù)據(jù)模型。但是，大部分人都不知道Hadoop是什么，應當如何使用它或者它是否對他們有幫助。

Apache Hadoop是MapReduce計算模型的一個開源實施。MapReduce是由谷歌公司推廣開的，用于構建公司的互聯(lián)網(wǎng)索引。在其最初形式中，MapReduce被當做一種系統(tǒng)集群分布式工作的方法，開發(fā)出來。在這樣一個集群中，有一個把題(計算任務)分解成小片的“主”節(jié)點，而每一小片工作任務都被發(fā)送至一個“工作”節(jié)點以進行下一步處理。這種分割——分發(fā)的模式就是名稱中“map”部分的由來。當所有的“工作”節(jié)點都完成了分配到的任務時，將返回計算結果并組合或“reduce”以生成***的結果。

但是，MapReduce和Hadoop引人注目的地方在于把MapReduce的概念應用于大數(shù)據(jù)應用中，而不只是計算網(wǎng)格中的分布式處理任務。雖然MapReduce的最初目的和“網(wǎng)格計算”極為相似，不過這個概念也被應用于對跨多個系統(tǒng)的數(shù)據(jù)庫的訪問。人們將它看做是大數(shù)據(jù)典型模式，原因有二：出于便利性的考慮，大多數(shù)大數(shù)據(jù)都是在特定環(huán)境中被搜集和存儲的;通常來說，大數(shù)據(jù)都是過于龐大而無法集中在一個單一系統(tǒng)中。

Hadoop的核心組成部分是Hadoop分布式文件系統(tǒng)(HDFS)，這是一個專門為跨潛在巨大量分布式服務器進行虛擬化而設計的文件系統(tǒng)。實際上，Hadoop使用JobTrackers和TaskTrackers來完成映射和降維任務;使用合適的軟件組件，Hadoop就能夠在結構化數(shù)據(jù)和非結構化數(shù)據(jù)上正常運行，并且使用幾乎所有的編程語言作為其開發(fā)框架。它適用于絕大多數(shù)的計算平臺，只要能夠正確地組織好版本和工具，你就可以毫不麻煩地在Hadoop中安裝混合平臺。

因為Hadoop是圍繞著兩個HDFS、一個分布式數(shù)據(jù)模型、JobTrackers / TaskTrackers以及一個分布式編程模式而構建的，所以它可以說用于構建云計算應用程序的***框架。事實上，你可以將Hadoop看做是唯一真實、廣泛可用的云計算應用程序框架，因為它是特別為數(shù)據(jù)所在的分布式處理而設計的，它并不會把數(shù)據(jù)移回至完成處理數(shù)據(jù)的位置。在云計算中，這是一個關鍵要求，因為大規(guī)模數(shù)據(jù)遷移的成本令人難以置信的高昂，對計算資源的要求也是性能超密集型的。可以預見，隨著時間的推移，真正云計算應用程序的開發(fā)一定將從Hadoop發(fā)展而來。

Hadoop“***”框架的另一面

當然，Hadoop也有著其挑戰(zhàn)性。任何掩蓋復雜性數(shù)據(jù)的處理架構都會由于濫用而產(chǎn)生開發(fā)低效的風險。

為什么Apache Hadoop如此讓人著迷

Hadoop***的挑戰(zhàn)是數(shù)據(jù)組織。因為數(shù)據(jù)是分離的，所以在數(shù)據(jù)的分布式組件中可能構建需要相關性的請求。例如，設想有一個電子表格式的結構，其中一半容量在一個系統(tǒng)上，而另一半容量在另一個系統(tǒng)上。如果有一個請求要求測試不同系統(tǒng)上的兩組數(shù)據(jù)，實際上必須把整個數(shù)據(jù)庫進行遷移，以執(zhí)行這個請求的任務，從而使分布式數(shù)據(jù)和分布式處理的原理失去了作用。對于結構化數(shù)據(jù)來說，設計應用程序以避免這種類型的低效是相對容易的，但是對于非結構化數(shù)據(jù)或商業(yè)智能(BI)請求高度多樣化的應用來說，就可能會產(chǎn)生嚴重的性能問題。

由于這一風險，企業(yè)應用程序中大數(shù)據(jù)的實際應用程序經(jīng)常會綜合使用Hadoop和傳統(tǒng)工具。有些***型的Hadoop應用程序為Hadoop打造了“前端”以便于處理標準DBMS和數(shù)據(jù)采集應用程序至HDFS的信息。他們還在查詢數(shù)據(jù)庫中匯總Hadoop結果。在匯總數(shù)據(jù)中運行BI應用程序總是比在原始詳細大數(shù)據(jù)中運行相同的應用程序更為高效，而預處理可確保數(shù)據(jù)分布是***的。

Hadoop的另一個問題是，它往往是集中采用大規(guī)模計算資源的方法而不是通過使用高效處理的方法來解決大數(shù)據(jù)問題。尤其是結構化數(shù)據(jù)，有更好的基于DBMS機制可用于分發(fā)數(shù)據(jù)和請求處理;復雜任務可能會占用大量資源，因此作業(yè)調(diào)度是防止BI請求過度使用資源的關鍵，從而也就確保更多的實時任務能夠按計劃完成。在同一集群中混合BI和實時應用程序的大多數(shù)Hadoop用戶要么會調(diào)度作業(yè)以避免資源使用發(fā)生沖突，要么在集群中采用一種分配計算時間的方法以避免大型BI任務私下占用所有的資源。

Hadoop是一個范式變換，因此由訓練有素的專業(yè)團隊通過一系列精心設計的試運行步驟來進行具體實施是絕對至關重要的。有人認為單獨實施Hadoop將會把斷開的離散云計算數(shù)據(jù)資源連接成為一個統(tǒng)一的數(shù)據(jù)庫，這種觀點是極其錯誤和危險的。除非在提交生產(chǎn)以前就對替代品(尤其是數(shù)據(jù)分布的替代品)完成了大量周密的測試，否則即便是經(jīng)驗豐富的Hadoop開發(fā)人員也很難識別其中的陷阱。