[Hadoop]chukwa的簡單介紹

Apache 的開源專案 hadoop， 作為一個分散式儲存和計算系統，已經被業界廣泛應用。很多大型企業都有了各自基於 hadoop 的應用和相關擴充套件。當 1000+ 以上個節點的 hadoop 叢集變得常見時，叢集自身的相關資訊如何收集和分析呢？針對這個問題， Apache 同樣提出了相應的解決方案，那就是 chukwa。

概述
chukwa 的官方網站是這樣描述自己的： chukwa 是一個開源的用於監控大型分散式系統的資料收集系統。這是構建在 hadoop 的 hdfs 和 map/reduce 框架之上的，繼承了 hadoop 的可伸縮性和魯棒性。Chukwa 還包含了一個強大和靈活的工具集，可用於展示、監控和分析已收集的資料。
在一些網站上，甚至聲稱 chukwa 是一個“日誌處理/分析的full stack solution”。
說了這麼多，你心動了嗎？
我們先來看看 chukwa 是什麼樣子的：
[img]http://hiphotos.baidu.com/ops_bd/pic/item/8c111e2dbbb4447cd62af14b.jpg[/img]

chukwa 不是什麼
1. chukwa 不是一個單機系統. 在單個節點部署一個 chukwa 系統,基本沒有什麼用處. chukwa 是一個構建在 hadoop 基礎上的分散式日誌處理系統.換言之,在搭建 chukwa 環境之前,你需要先構建一個 hadoop 環境,然後在 hadoop 的基礎上構建 chukwa 環境,這個關係也可以從稍後的 chukwa 架構圖上看出來.這也是因為 chukwa 的假設是要處理的資料量是在 T 級別的.
2. chukwa 不是一個實時錯誤監控系統.在解決這個問題方面, ganglia,nagios 等等系統已經做得很好了,這些系統對資料的敏感性都可以達到秒級. chukwa 分析的是資料是分鐘級別的,它認為像叢集的整體 cpu 使用率這樣的資料,延遲幾分鐘拿到,不是什麼問題.
3. chukwa 不是一個封閉的系統.雖然 chukwa 自帶了許多針對 hadoop 叢集的分析項,但是這並不是說它只能監控和分析 hadoop.chukwa 提供了一個對大資料量日誌類資料採集、儲存、分析和展示的全套解決方案和框架,在這類資料生命週期的各個階段, chukwa 都提供了近乎完美的解決方案,這一點也可以從它的架構中看出來.

chukwa 是什麼
上一節說了很多 chukwa 不是什麼,下面來看下 chukwa 具體是幹什麼的一個系統呢?
具體而言, chukwa 致力於以下幾個方面的工作:
1. 總體而言, chukwa 可以用於監控大規模(2000+ 以上的節點, 每天產生資料量在T級別) hadoop 叢集的整體執行情況並對它們的日誌進行分析
2. 對於叢集的使用者而言: chukwa 展示他們的作業已經執行了多久,佔用了多少資源,還有多少資源可用,一個作業是為什麼失敗了,一個讀寫操作在哪個節點出了問題.
3. 對於叢集的運維工程師而言: chukwa 展示了叢集中的硬體錯誤,叢集的效能變化,叢集的資源瓶頸在哪裡.
4. 對於叢集的管理者而言: chukwa 展示了叢集的資源消耗情況,叢集的整體作業執行情況,可以用以輔助預算和叢集資源協調.
5. 對於叢集的開發者而言: chukwa 展示了叢集中主要的效能瓶頸,經常出現的錯誤,從而可以著力重點解決重要問題.

基本架構
有了一個感性的認識後,我們來看下它的構架, chukwa 的整體結構圖是下面這個樣子的:

[img]http://hiphotos.baidu.com/ops_bd/pic/item/fce9850fc4f77cc4087b8257.jpg[/img]
其中主要的部件為:
1. agents : 負責採集最原始的資料,併傳送給 collectors
2. adaptor : 直接採集資料的介面和工具,一個 agent 可以管理多個 adaptor 的資料採集
3. collectors 負責收集 agents 收送來的資料,並定時寫入叢集中
4. map/reduce jobs 定時啟動,負責把叢集中的資料分類、排序、去重和合並
5. HICC 負責資料的展示

相關設計
adaptors 和 agents
在每個資料的產生端(基本上是叢集中每一個節點上), chukwa 使用一個 agent 來採集它感興趣的資料,每一類資料通過一個 adaptor 來實現, 資料的型別(DataType?)在相應的配置中指定. 預設地, chukwa 對以下常見的資料來源已經提供了相應的 adaptor ： 命令列輸出、log 檔案和 httpSender等等. 這些 adaptor 會定期執行(比如每分鐘讀一次 df 的結果)或事件驅動地執行(比如 kernel 打了一條錯誤日誌). 如果這些 adaptor 還不夠用，使用者也可以方便地自己實現一個 adaptor 來滿足需求。

為防止資料採集端的 agent 出現故障，chukwa 的 agent 採用了所謂的 ‘watchdog’ 機制，會自動重啟終止的資料採集程式，防止原始資料的丟失。
另一方面, 對於重複採集的資料, 在 chukwa 的資料處理過程中,會自動對它們進行去重. 這樣,就可以對於關鍵的資料在多臺機器上部署相同的 agent,從而實現容錯的功能.
collectors
agents 採集到的資料,是儲存到 hadoop 叢集上的. hadoop 叢集擅長於處理少量大檔案，而對於大量小檔案的處理則不是它的強項，針對這一點，chukwa 設計了 collector 這個角色，用於把資料先進行部分合並，再寫入叢集，防止大量小檔案的寫入。
另一方面,為防止 collector 成為效能瓶頸或成為單點,產生故障, chukwa 允許和鼓勵設定多個 collector, agents 隨機地從 collectors 列表中選擇一個 collector 傳輸資料,如果一個 collector 失敗或繁忙,就換下一個 collector. 從而可以實現負載的均衡,實踐證明,多個 collector 的負載幾乎是平均的.
demux 和 archive
放在叢集上的資料,是通過 map/reduce 作業來實現資料分析的. 在 map/reduce 階段， chukwa 提供了 demux 和 archive 任務兩種內建的作業型別.
demux 作業負責對資料的分類、排序和去重. 在 agent 一節中,我們提到了資料型別(DataType?)的概念.由 collector 寫入叢集中的資料,都有自己的型別. demux 作業在執行過程中,通過資料型別和配置檔案中指定的資料處理類,執行相應的資料分析工作,一般是把非結構化的資料結構化,抽取中其中的資料屬性.由於 demux 的本質是一個 map/reduce 作業,所以我們可以根據自己的需求制定自己的 demux 作業,進行各種複雜的邏輯分析. chukwa 提供的 demux interface 可以用 java 語言來方便地擴充套件.
而 archive 作業則負責把同型別的資料檔案合併，一方面保證了同一類的資料都在一起，便於進一步分析, 另一方面減少檔案數量, 減輕 hadoop 叢集的儲存壓力。
dbadmin
放在叢集上的資料,雖然可以滿足資料的長期儲存和大資料量計算需求,但是不便於展示.為此, chukwa 做了兩方面的努力:
1. 使用 mdl 語言,把叢集上的資料抽取到 mysql 資料庫中,對近一週的資料,完整儲存,超過一週的資料,按資料離現在的時間長短作稀釋,離現在越久的資料,所儲存的資料時間間隔越長.通過 mysql 來作資料來源,展示資料.
2. 使用 hbase 或類似的技術,直接把索引化的資料在儲存在叢集上
到 chukwa 0.4.0 版本為止, chukwa 都是用的第一種方法,但是第二種方法更優雅也更方便一些.
hicc
hicc 是 chukwa 的資料展示端的名字.在展示端， chukwa 提供了一些預設的資料展示 widget，可以使用“列表”、“曲線圖”、“多曲線圖”、“柱狀圖”、“面積圖式展示一類或多類資料，給使用者直觀的資料趨勢展示。而且，在 hicc 展示端，對不斷生成的新資料和歷史資料，採用 robin 策略，防止資料的不斷增長增大伺服器壓力，並對資料在時間軸上“稀釋”，可以提供長時間段的資料展示
從本質上, hicc 是用 jetty 來實現的一個 web 服務端,內部用的是 jsp 技術和 javascript 技術.各種需要展示的資料型別和頁面的局都可以通過簡直地拖拽方式來實現,更復雜的資料展示方式,可以使用 sql 語言組合出各種需要的資料.如果這樣還不能滿足需求,不用怕,動手修改它的 jsp 程式碼就可以了.
其它資料介面
如果對原始資料還有新的需要，使用者還可以通過 map/reduce 作業或 pig 語言直接訪問叢集上的原始資料，以生成所需要的結果。chukwa 還提供了命令列的介面，可以直接訪問到叢集上資料。
預設資料支援
對於叢集各節點的cpu使用率、記憶體使用率、硬碟使用率、叢集整體的 cpu 平均使用率、叢集整體的記憶體使用率、叢集整體的儲存使用率、叢集檔案數變化、作業數變化等等 hadoop 相關資料,從採集到展示的一整套流程, chukwa 都提供了內建的支援,只需要配置一下就可以使用.可以說是相當方便的.
可以看出，chukwa 從資料的產生、收集、儲存、分析到展示的整個生命週期都提供了全面的支援。