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

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

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

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

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

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

當然，Hadoop也有著其挑戰性。任何掩蓋復雜性數據的處理架構都會由于濫用而產生開發低效的風險。

為什么Apache Hadoop如此讓人著迷

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

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

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

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