Hadoop體系架構簡介

本文轉載自查看原文 2017-03-09 09:59 8240 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實質上是某個節點上的守護進程，而非節點本身。

大數據技術領域：