您所在的位置 : IT客 » 程序開發 » JavaEE

分佈式計算Hadoop介紹

            在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要做的工作。

分佈式計算Hadoop介紹
圖1:MapReduce結構示意圖

上圖就是MapReduce大致的結構圖,在Map前還可能會對輸入的數據有Split(分割)的過程,保證任務並行效率,在Map之後還會有Shuffle(混合)的過程,對於提高Reduce的效率以及減小數據傳輸的壓力有很大的幫助。後面會具體提及這些部分的細節。

HDFS是分佈式計算的存儲基石,Hadoop的分佈式文件系統和其他分佈式文件系統有很多類似的特質。分佈式文件系統基本的幾個特點:

對於整個集羣有單一的命名空間。數據一致性。適合一次寫入多次讀取的模型,客戶端在文件沒有被成功創建之前無法看到文件存在。文件會被分割成多個文件塊,每個文件塊被分配存儲到數據節點上,而且根據配置會由複製文件塊來保證數據的安全性。分佈式計算Hadoop介紹
圖2:HDFS結構示意圖

上圖中展現了整個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的幾個設計特點(對於框架設計值得借鑑):

Block的放置:默認不配置。一個Block會有三份備份,一份放在NameNode指定的DataNode,另一份放在與指定 DataNode非同一Rack上的DataNode,最後一份放在與指定DataNode同一Rack上的DataNode上。備份無非就是爲了數據安 全,考慮同一Rack的失敗情況以及不同Rack之間數據拷貝性能問題就採用這種配置方式。心跳檢測DataNode的健康狀況,如果發現問題就採取數據備份的方式來保證數據的安全性。數據複製(場景爲DataNode失敗、需要平衡DataNode的存儲利用率和需要平衡DataNode數據交互壓力等情況):這裏先 說一下,使用HDFS的balancer命令,可以配置一個Threshold來平衡每一個DataNode磁盤利用率。例如設置了Threshold爲 10%,那麼執行balancer命令的時候,首先統計所有DataNode的磁盤利用率的均值,然後判斷如果某一個DataNode的磁盤利用率超過這 個均值Threshold以上,那麼將會把這個DataNode的block轉移到磁盤利用率低的DataNode,這對於新節點的加入來說十分有用。數據交驗:採用CRC32作數據交驗。在文件Block寫入的時候除了寫入數據還會寫入交驗信息,在讀取的時候需要交驗後再讀入。NameNode是單點:如果失敗的話,任務處理信息將會紀錄在本地文件系統和遠端的文件系統中。數據管道性的寫入:當客戶端要寫入文件到DataNode上,首先客戶端讀取一個Block然後寫到第一個DataNode上,然後由第 一個DataNode傳遞到備份的DataNode上,一直到所有需要寫入這個Block的NataNode都成功寫入,客戶端纔會繼續開始寫下一個 Block。安全模式:在分佈式文件系統啓動的時候,開始的時候會有安全模式,當分佈式文件系統處於安全模式的情況下,文件系統中的內容不允許修改也 不允許刪除,直到安全模式結束。安全模式主要是爲了系統啓動的時候檢查各個DataNode上數據塊的有效性,同時根據策略必要的複製或者刪除部分數據 塊。運行期通過命令也可以進入安全模式。在實踐過程中,系統啓動的時候去修改和刪除文件也會有安全模式不允許修改的出錯提示,只需要等待一會兒即可。

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

分佈式計算Hadoop介紹
圖3: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最早是爲了搜索引擎實現而開發的,後來才被用於分佈式計算框架中。海量數據被分割於多個節點,然後由每一個節點並行計算,將得出的結果歸併到輸出。同時第一階段的輸出又可以作爲下一階段計算的輸入,因此可以想象到一個樹狀結構的分佈式計算圖,在不同階段都有不同產出,同時並行和串行結合的計算也可以很好地在分佈式集羣的資源下得以高效的處理。

其實參看Hadoop官方文檔已經能夠很容易配置分佈式框架運行環境了,不過這裏既然寫了就再多寫一點,同時有一些細節需要注意的也說明一下,其實也就是這些細節會讓人摸索半天。Hadoop可以單機跑,也可以配置集羣跑,單機跑就不需要多說了,只需要按照Demo的運行說明直接執行命令即可。這裏主要重點說一下集羣配置運行的過程。

環境

7臺普通的機器,操作系統都是Linux。內存和CPU就不說了,反正Hadoop一大特點就是機器在多不在精。JDK必須是1.5以上的,這個切記。7臺機器的機器名務必不同,後續會談到機器名對於MapReduce有很大的影響。

部署考慮

正如上面我描述的,對於Hadoop的集羣來說,可以分成兩大類角色:Master和Slave,前者主要配置NameNode和 JobTracker的角色,負責總管分佈式數據和分解任務的執行,後者配置DataNode和TaskTracker的角色,負責分佈式數據存儲以及任務的執行。本來我打算看看一臺機器是否可以配置成Master,同時也作爲Slave使用,不過發現在NameNode初始化的過程中以及 TaskTracker執行過程中機器名配置好像有衝突(NameNode和TaskTracker對於Hosts的配置有些衝突,究竟是把機器名對應 IP放在配置前面還是把Localhost對應IP放在前面有點問題,不過可能也是我自己的問題吧,這個大家可以根據實施情況給我反饋)。最後反正決定一臺Master,六臺Slave,後續複雜的應用開發和測試結果的比對會增加機器配置。

實施步驟

頂一下
(0)
踩一下
(0)

發表評論:

昵稱: *
內容:
驗證碼:
rss· 投稿· 加入收藏· 手機版