Hadoop體系架構簡介

　　今天跟一個朋友在討論hadoop體系架構，從當下流行的Hadoop+HDFS+MapReduce+Hbase+Pig+Hive+Spark+Storm開始一直講到HDFS的底層實現，MapReduce的模型計算，到一個雲盤如何實現，再到Google分佈式史上那最偉大的三篇文章。

　　這幾個名詞剛問到初學者的時候確定會一臉懵逼包括我本身，整個Hadoop家族成員不少，「勢力」很龐大，下面畫個圖，簡單歸納下。

 

 

到這裏本文內容已結束，下文是摘自網絡上一些比較經典或者淺顯易懂的相關文字，有興趣的繼續往下看。對初學者來講，若是上圖能大概看懂，那下面的內容能更有利於你理解。

 

Google的分佈式計算三駕馬車：

Hadoop的創始源頭在於當年Google發佈的3篇文章，被稱爲Google的分佈式計算三駕馬車。

Google File System（中文，英文）用來解決數據存儲的問題，採用N多臺廉價的電腦，使用冗餘（也就是一份文件保存多份在不一樣的電腦之上）的方式，來取得讀寫速度與數據安全並存的結果。

Map-Reduce說穿了就是函數式編程，把全部的操做都分紅兩類，map與reduce，map用來將數據分紅多份，分開處理，reduce將處理後的結果進行歸併，獲得最終的結果。可是在其中解決了容錯性的問題。

BigTable是在分佈式系統上存儲結構化數據的一個解決方案，解決了巨大的Table的管理、負載均衡的問題。

 

Doug Cutting：

Doug Cutting以前是一個很是有名的開源社區的人，創造了nutch與lucene（如今都是在Apache基金會下面的），nutch以前就實現了一個分佈式的爬蟲抓取系統。等Google的三駕馬車發佈後，Doug Cutting一看，挖靠這麼厲害的技術，因而就實現了一個DFS(distributed file system)與Map-Reduce（大牛風範啊），集成進了Nutch，做爲Nutch的一個子項目存在。那時，是2004年左右。

在互聯網這個領域一直有這樣的說法：

「若是老二沒法打敗老大，那麼就把老大賴以生存的東西開源吧」

當年與Google仍是處在強烈競爭關係的Yahoo!因而招了Doug兄進來，把老大賴以生存的DFS與Map-Reduce開源了。開始了Hadoop的童年時期。差很少在2008年的時候，Hadoop纔算逐漸成熟。

 

GFS+MapReduce+Bigtable之間的關係：

知乎上有個回答的很形象：

Hadoop是不少組件的集合，主要包括但不限於MapReduce，HDFS，HBase，ZooKeeper。MapReduce模仿了Google MapReduce，HDFS模仿了Google File System，HBase模仿了Google BigTable，ZooKeeper或多或少模仿了Google Chubby（沒有前3個出名），因此下文就只提MapReduce、HDFS、HBase、ZooKeeper吧。

簡單來說，

• HDFS和HBase是依靠外存（即硬盤）的分佈式文件存儲實現和分佈式表存儲實現。HDFS是一個分佈式的「雲存儲」文件系統，它會把一個文件分塊並分別保存，取用時分別再取出、合併。重要的是，這些分塊一般會在3個節點（即集羣內的服務器）上各有1個備份，所以即便出現少數節點的失效（如硬盤損壞、掉電等），文件也不會失效。若是說HDFS是文件級別的存儲，那HBase則是表級別的存儲。HBase是表模型，但比SQL數據庫的表要簡單的多，沒有鏈接、彙集等功能。HBase的表是物理存儲到HDFS的，好比把一個表分紅4個HDFS文件並存儲。因爲HDFS級會作備份，因此HBase級再也不備份。
• MapReduce則是一個計算模型，而不是存儲模型；MapReduce一般與HDFS緊密配合。舉個例子：假設你的手機通話信息保存在一個HDFS的文件callList.txt中，你想找到你與同事A的全部通話記錄並排序。由於HDFS會把callLst.txt分紅幾塊分別存，好比說5塊，那麼對應的Map過程就是找到這5塊所在的5個節點，讓它們分別找本身存的那塊中關於同事A的通話記錄，對應的Reduce過程就是把5個節點過濾後的通話記錄合併在一塊並按時間排序。MapReduce的計算模型一般把HDFS做爲數據來源，不多會用到其它數據來源好比HBase。
• ZooKeeper自己是一個很是牢靠的記事本，用於記錄一些概要信息。Hadoop依靠這個記事原本記錄當前哪些節點正在用，哪些已掉線，哪些是備用等，以此來管理機羣。

相比較而言，

• Storm自己主要是一個分佈式環境下的實時數據計算模型，沒有外存存儲部分。Storm的應用場景是，數據來的特別快、而且要求隨來隨處理。好比Twitter服務器自身每秒收到來自全世界的推能達幾千條，而且要求收到後還需當即索引，以供查詢。這用傳統的方法乃至Hadoop都是比較難的，由於外存的使用會帶來較大的延遲，這時能夠用Storm。Storm節點對內存中的數據進行操做，而後流出數據到下一個節點，以此來維繫節點間的協做、達到高速協同處理。
• Storm有一個總的控制節點Nimbus來與ZooKeeper交流、進行集羣管理。
• Storm尚未作到數據備份，這是它的不足（2013年Update: 較新的Storm已引入了類事務的概念，會有重作的操做來保證數據的處理）。

因此，Hadoop和Storm都是分佈式環境下的計算平臺，不過前者依賴外存，適應批處理情形，後者依賴內存，適應實時處理、超低延遲、無需大量存儲數據情形。前類出現的時間較早（03年GFS的論文），後類出現的時間較晚（10年Yahoo! S4的論文）。我不大讚同「Storm改進了Hadoop的缺點」的說法——這種說法有點像「輪船改進了汽車的哪些缺點」——由於它們自己即不太同類。Storm和Hadoop有不少類似也有不少區別，適用的場景是不同的，主要取決於使用者本身的需求。

*上面不少敘述方法是爲了讀者的更好理解，不盡徹底準確，好比HBase是有內存緩衝機制的，並不是只依賴外存，再好比Nimbus實質上是某個節點上的守護進程，而非節點自己。

 

大數據技術領域：

 

 

大數據平臺架構：

 

 

數據處理基礎架構

 

技術架構

 

 

參考文獻:

分佈式系統漫談—Google三駕馬車: GFS,mapreduce,Bigtable

大數據Hadoop核心架構HDFS+MapReduce+Hbase+Hive內部機理詳解

爲何Hadoop將必定會是分佈式計算的將來

多圖技術貼：深刻淺出解析大數據平臺架構

HDFS的運行原理

MapReduce框架詳解

http://www.oschina.net/p/hbase