在SIP專案設計的過程中，對於它龐大的日誌在開始時就考慮使用任務分解的多執行緒處理模式來分析統計，在我從前寫的文章《Tiger Concurrent Practice —日誌分析並行分解設計與實現》中有所提到。但是由於統計的內容暫時還是十分簡單，所以就採用Memcache作為計數器，結合MySQL就完成了訪問控制以及統計的工作。然而未來，對於海量日誌分析的工作，還是需要有所準備。現在最火的技術詞彙莫過於“雲端計算”，在Open API日益盛行的今天，網際網路應用的資料將會越來越有價值，如何去分析這些資料，挖掘其內在價值，就需要分散式計算來支撐海量資料的分析工作。

回過頭來看，早先那種多執行緒，多工分解的日誌分析設計，其實是分散式計算的一個單機版縮略，如何將這種單機的工作進行分拆，變成協同工作的叢集，其實就是分散式計算框架設計所涉及的。在去年參加BEA大會的時候，BEA和VMWare合作採用虛擬機器來構建叢集，無非就是希望使得計算機硬體能夠類似於應用程式中資源池的資源，使用者無需關心資源的分配情況，從而最大化了硬體資源的使用價值。分散式計算也是如此，具體的計算任務交由哪一臺機器執行，執行後由誰來彙總，這都由分散式框架的Master來抉擇，而使用者只需簡單地將待分析內容提供給分散式計算系統作為輸入，就可以得到分散式計算後的結果。

Hadoop是Apache開源組織的一個分散式計算開源框架，在很多大型網站上都已經得到了應用，如亞馬遜、Facebook和Yahoo等等。對於我來說，最近的一個使用點就是服務整合平臺的日誌分析。服務整合平臺的日誌量將會很大，而這也正好符合了分散式計算的適用場景(日誌分析和索引建立就是兩大應用場景)。

什麼是Hadoop?

搞什麼東西之前，第一步是要知道What(是什麼)，然後是Why(為什麼)，最後才是How(怎麼做)。但很多開發的朋友在做了多年專案以後，都習慣是先How，然後What，最後才是Why，這樣只會讓自己變得浮躁，同時往往會將技術誤用於不適合的場景。

Hadoop框架中最核心的設計就是：MapReduce和HDFS。MapReduce的思想是由Google的一篇論文所提及而被廣為流傳的，簡單的一句話解釋MapReduce就是“任務的分解與結果的彙總”。HDFS是Hadoop分散式檔案系統(Hadoop Distributed File System)的縮寫，為分散式計算儲存提供了底層支援。

MapReduce從它名字上來看就大致可以看出個緣由，兩個動詞Map和Reduce，“Map(展開)”就是將一個任務分解成為多個任務，“Reduce”就是將分解後多工處理的結果彙總起來，得出最後的分析結果。這不是什麼新思想，其實在前面提到的多執行緒，多工的設計就可以找到這種思想的影子。不論是現實社會，還是在程式設計中，一項工作往往可以被拆分成為多個任務，任務之間的關係可以分為兩種：一種是不相關的任務，可以並行執行;另一種是任務之間有相互的依賴，先後順序不能夠顛倒，這類任務是無法並行處理的。回到大學時期，教授上課時讓大家去分析關鍵路徑，無非就是找最省時的任務分解執行方式。在分散式系統中，機器叢集就可以看作硬體資源池，將並行的任務拆分，然後交由每一個空閒機器資源去處理，能夠極大地提高計算效率，同時這種資源無關性，對於計算叢集的擴充套件無疑提供了最好的設計保證。(其實我一直認為Hadoop的卡通圖示不應該是一個小象，應該是螞蟻，分散式計算就好比螞蟻吃大象，廉價的機器群可以匹敵任何高效能的計算機，縱向擴充套件的曲線始終敵不過橫向擴充套件的斜線)。任務分解處理以後，那就需要將處理以後的結果再彙總起來，這就是Reduce要做的工作。

上圖就是MapReduce大致的結構圖，在Map前還可能會對輸入的資料有Split(分割)的過程，保證任務並行效率，在Map之後還會有Shuffle(混合)的過程，對於提高Reduce的效率以及減小資料傳輸的壓力有很大的幫助。後面會具體提及這些部分的細節。歡迎加入大資料交流群：658558542 一起吹水交流學習

HDFS是分散式計算的儲存基石，Hadoop的分散式檔案系統和其他分散式檔案系統有很多類似的特質。分散式檔案系統基本的幾個特點：

對於整個叢集有單一的名稱空間。

資料一致性。適合一次寫入多次讀取的模型，客戶端在檔案沒有被成功建立之前無法看到檔案存在。

檔案會被分割成多個檔案塊，每個檔案塊被分配儲存到資料節點上，而且根據配置會由複製檔案塊來保證資料的安全性。

上圖中展現了整個HDFS三個重要角色：NameNode、DataNode和Client。NameNode可以看作是分散式檔案系統中的管理者，主要負責管理檔案系統的名稱空間、叢集配置資訊和儲存塊的複製等。NameNode會將檔案系統的Meta-data儲存在記憶體中，這些資訊主要包括了檔案資訊、每一個檔案對應的檔案塊的資訊和每一個檔案塊在DataNode的資訊等。DataNode是檔案儲存的基本單元，它將Block儲存在本地檔案系統中，儲存了Block的Meta-data，同時週期性地將所有存在的Block資訊傳送給NameNode。Client就是需要獲取分散式檔案系統檔案的應用程式。這裡通過三個操作來說明他們之間的互動關係。

檔案寫入：

Client向NameNode發起檔案寫入的請求。

NameNode根據檔案大小和檔案塊配置情況，返回給Client它所管理部分DataNode的資訊。

Client將檔案劃分為多個Block，根據DataNode的地址資訊，按順序寫入到每一個DataNode塊中。

檔案讀取：

Client向NameNode發起檔案讀取的請求。

NameNode返回檔案儲存的DataNode的資訊。

Client讀取檔案資訊。

檔案Block複製：

NameNode發現部分檔案的Block不符合最小複製數或者部分DataNode失效。

通知DataNode相互複製Block。

DataNode開始直接相互複製。

最後再說一下HDFS的幾個設計特點(對於框架設計值得借鑑)：

1、Block的放置：預設不配置。一個Block會有三份備份，一份放在NameNode指定的DataNode，另一份放在與指定DataNode非同一Rack上的DataNode，最後一份放在與指定DataNode同一Rack上的DataNode上。備份無非就是為了資料安全，考慮同一Rack的失敗情況以及不同Rack之間資料拷貝效能問題就採用這種配置方式。

2、心跳檢測DataNode的健康狀況，如果發現問題就採取資料備份的方式來保證資料的安全性。

3、資料複製(場景為DataNode失敗、需要平衡DataNode的儲存利用率和需要平衡DataNode資料互動壓力等情況)：這裡先說一下，使用HDFS的balancer命令，可以配置一個Threshold來平衡每一個DataNode磁碟利用率。例如設定了Threshold為10%，那麼執行balancer命令的時候，首先統計所有DataNode的磁碟利用率的均值，然後判斷如果某一個DataNode的磁碟利用率超過這個均值Threshold以上，那麼將會把這個DataNode的block轉移到磁碟利用率低的DataNode，這對於新節點的加入來說十分有用。

4、資料交驗：採用CRC32作資料交驗。在檔案Block寫入的時候除了寫入資料還會寫入交驗資訊，在讀取的時候需要交驗後再讀入。

5、NameNode是單點：如果失敗的話，任務處理資訊將會紀錄在本地檔案系統和遠端的檔案系統中。

6、資料管道性的寫入：當客戶端要寫入檔案到DataNode上，首先客戶端讀取一個Block然後寫到第一個DataNode上，然後由第一個DataNode傳遞到備份的DataNode上，一直到所有需要寫入這個Block的NataNode都成功寫入，客戶端才會繼續開始寫下一個Block。

7、安全模式：在分散式檔案系統啟動的時候，開始的時候會有安全模式，當分散式檔案系統處於安全模式的情況下，檔案系統中的內容不允許修改也不允許刪除，直到安全模式結束。安全模式主要是為了系統啟動的時候檢查各個DataNode上資料塊的有效性，同時根據策略必要的複製或者刪除部分資料塊。執行期通過命令也可以進入安全模式。在實踐過程中，系統啟動的時候去修改和刪除檔案也會有安全模式不允許修改的出錯提示，只需要等待一會兒即可。歡迎加入大資料交流群：658558542 一起吹水交流學習

下面綜合MapReduce和HDFS來看Hadoop的結構：

在Hadoop的系統中，會有一臺Master，主要負責NameNode的工作以及JobTracker的工作。JobTracker的主要職責就是啟動、跟蹤和排程各個Slave的任務執行。還會有多臺Slave，每一臺Slave通常具有DataNode的功能並負責TaskTracker的工作。TaskTracker根據應用要求來結合本地資料執行Map任務以及Reduce任務。

說到這裡，就要提到分散式計算最重要的一個設計點：Moving Computation is Cheaper than Moving Data。就是在分散式處理中，移動資料的代價總是高於轉移計算的代價。簡單來說就是分而治之的工作，需要將資料也分而儲存，本地任務處理本地資料然後歸總，這樣才會保證分散式計算的高效性。

為什麼要選擇Hadoop?

說完了What，簡單地說一下Why。官方網站已經給了很多的說明，這裡就大致說一下其優點及使用的場景(沒有不好的工具，只用不適用的工具，因此選擇好場景才能夠真正發揮分散式計算的作用)：

可擴充套件：不論是儲存的可擴充套件還是計算的可擴充套件都是Hadoop的設計根本。

經濟：框架可以執行在任何普通的PC上。

可靠：分散式檔案系統的備份恢復機制以及MapReduce的任務監控保證了分散式處理的可靠性。

高效：分散式檔案系統的高效資料互動實現以及MapReduce結合Local Data處理的模式，為高效處理海量的資訊作了基礎準備。

使用場景：

個人覺得最適合的就是海量資料的分析，其實Google最早提出MapReduce也就是為了海量資料分析。同時HDFS最早是為了搜尋引擎實現而開發的，後來才被用於分散式計算框架中。海量資料被分割於多個節點，然後由每一個節點平行計算，將得出的結果歸併到輸出。同時第一階段的輸出又可以作為下一階段計算的輸入，因此可以想象到一個樹狀結構的分散式計算圖，在不同階段都有不同產出，同時並行和序列結合的計算也可以很好地在分散式叢集的資源下得以高效的處理。歡迎加入大資料交流群：658558542 一起吹水交流學習

結語

為了幫助大家讓學習變得輕鬆、高效，給大家免費分享一大批資料，幫助大家在成為大資料工程師，乃至架構師的路上披荊斬棘。在這裡給大家推薦一個大資料學習交流圈：658558542 歡迎大家進群交流討論，學習交流，共同進步。

當真正開始學習的時候難免不知道從哪入手，導致效率低下影響繼續學習的信心。

但最重要的是不知道哪些技術需要重點掌握，學習時頻繁踩坑，最終浪費大量時間，所以有有效資源還是很有必要的。

最後祝福所有遇到瓶疾且不知道怎麼辦的大資料程式設計師們，祝福大家在往後的工作與面試中一切順利。