基于HBase的動態分組研究

李春煒

(中國人民武裝警察部隊指揮學院,天津 300250)

1 HBase分組對使用場景的影響

早期HBase是一個業務方一個集群,以業界標準物理機64核256G內存、硬盤SSD 512G*8為基準,至少需要10臺這種配置的機器才能保證集群穩定。多個業務共用一個集群會導致搶占網絡、搶占線程的情況,集群出現故障影響層面較大,導致多個非故障業務受到牽連。因此為每個業務配置一個集群或者多個非重要業務共用一個集群,再或者某些重要的業務使用獨立集群,其他非重要業務使用公共集群,能夠基本保證業務使用HBase的穩定性和避免資源浪費。不過隨著業務流量變動,或者業務暫時下線、新的業務加入、老的業務退出,如何對表進行相對合理的分組成為了新難題,基本都需要人工根據現有的集群情況、業務的重要性以及未來讀寫預期進行分組。且隨著時間推移,業務的擴縮容都是不可控的,純人工的時效性不能得到保障,往往是出了問題再解決,集群可用性風險增加,機器成本達不到理想狀態[1]。

2 基于HBase的動態分組

基于上述問題可以采用一套動態策略,通過調用HBase分組隔離功能RegionServer Grouping來實現對表的動態分組,以達到保障機器資源和降低業務風險的作用。

2.1 動態計數

每個業務在每個時段都有響應的讀寫請求,時間粒度粗則按天為單位,細則按秒為單位,基于HBase客戶端統計業務請求數或根據HBase服務端自帶的監控指標來計數,將統計到的數量上報到監控系統。當前業界普遍采用的監控系統有基于kafka的flink實現,本文不進行闡述。結合每個業務的請求數,我們就能依據趨勢圖來提前預判哪些業務應該臨時分到特定的分組,哪些業務應該長時間在某個分組里,具體的分析策略需要結合業務實際情況而定。

2.2 分組對機器的劃分

每個集群有一個default分組,不過合理的依據機器性能創建新的分組可以使機器的使用效益最大化。HBase最大的特性就是可水平擴展大數據存儲,無論是HDD磁盤,還是SSD磁盤理論上都是可以利用的。但由于RegionServer和DataNode是部署在一起的,磁盤的性能直接決定了RegionServer的讀寫能力,自然也成為了分組指標之一。除了磁盤,CPU和內存也是決定機器性能的重要指標。判斷一個分組是否合理,還可以分析監控指標,然后人為的或者動態的進行調整,指標和維度越多,越趨近合理[2]。

2.3 分組對業務的劃分

業務之間有優先級的高低。優先級高的業務必然要使用性能更好的分組;一些流量小,要求不高的業務,可以調低優先級使用性能一般的分組。除了主觀的調整外,業務分類、流量波峰波谷時間維度、寫入數據塊大小等都可作為業務評分的標準。主客相結合的評判對業務的定義顯得十分必要。

2.4 分組的降級

動態分組除了能進行常規的分組操作,面對突發事件,如跨機房網絡不通、機房斷電、機器故障等不可抗力的特殊場景,還可以立刻觸發分組策略對分組進行降級,保障系統的高可用。設計分組降級策略時,需要充分考慮到業務指標的重要性,是側重響應時間還是成本。

2.5 人工干預

對動態分組的研究就是為了解決人工使用中遇到的問題,使HBase系統更加完善。但當動態分組由于設計缺陷或者編碼錯誤導致系統沒有按照預期分組時,就需要人為進行干預,確保系統最高控制權在人的手中。

3 動態分組功能設計與應用

本文所研究的動態分組功能是基于實驗室特定局域網場景實現的,具體架構如圖1所示。

圖1 動態分組架構圖Fig.1 Dynamic grouping architecture diagram

3.1 定時任務模塊

該模塊是最終執行移動分組的模塊,通過定時獲取“策略模塊”計算出的信息來對業務進行移動分組。實驗采用spring quartz雙節點搭配zookeeper選舉master保障單節點執行調用RegionServer Grouping。執行后打印執行日志,方便跟蹤系統策略及狀態[3]。

3.2 上報模塊

3.2.1 基于HBase客戶端的上報

該上報采用異步分鐘級上報,通過HBase自帶依賴包Netty傳輸數據,以避免使用其他通信框架造成jar包沖突,ReportServer接收客戶端所上報的數據。上報的數據設置過期時間,可避免造成大量冷數據。本實驗設置為兩天,上報的數據格式為{＂clientId＂:＂00001＂,＂table Name＂:＂exampleTable＂,＂date＂:＂yyyyMMDDhh mm＂,＂expired Day＂:＂2＂,＂timeArrays＂:[qps,qps,qps…]},timeArrays存儲為每秒的QPS。服務端接收到數據之后解析并分析數據。

3.2.2 基于HBase服務端上報

HBase服務端上報包含RegionServer上報和DataNode上報,主要監控指標都集中在RegionServer上。實驗選用了常用的幾個指標:totalRequestCount、readRequest Count、writeRequestCount、numActiveHandler、numCallsIn GeneralQueue。不同的指標可以生成不同的策略,指標越多,策略的復雜度也越高[4]。將這些指標上報到實時分析模塊后進行分析,如圖2所示。

圖2 上報模塊交互圖Fig.2 Reporting module interaction diagram

3.3 實時分析模塊

依賴上報數據進行實時數據分析,為了保證模塊魯棒性將服務端接口接入kafka,利用flink消費kafka,訂閱生成報表方便管理人員對分組進行實時監控,同時將設定好的策略條件載入到flink 進行計算。實驗使用了一個簡單的閾值來觸發分組,超過設定好的QPS,該業務分組將被推送到定時任務模塊隊列,待定時任務執行后,將業務移動到新的分組,如圖3所示。

圖3 實時模塊圖Fig.3 Real-time module diagram

3.4 離線分析模塊

除了依據實時分析模塊對業務進行分組外,離線分析模塊和實時分析模塊一樣從kafka訂閱上報數據,然后根據數據倉庫中相關維度的數據表進行統計分析,從而使得某些策略的閾值更加精確合理,最后依據最初設置的權重來對現有策略進行更新,如圖4所示。

圖4 離線分析模塊圖Fig.4 Offline analysis module diagram

3.5 策略模塊

策略模塊是動態分組最核心的模塊,該模塊發揮的優劣直接決定了動態分組的價值。實驗根據業務復雜度設計了高中低三種策略。在相同的業務集群和應用場景設定下,三種策略的動態分組結果均不相同,經評估符合正常的分組邏輯。策略如下:

3.5.1 分組降級策略

分組降級策略采用單向不可逆的動態分組,將默認分組部分表移動到中等資源組,中等資源組部分表遇到瓶頸或者抖動繼續移動到唯一分組,如圖5所示。

圖5 分組降級策略圖Fig.5 Group downgrade strategy diagram

3.5.2 流量分析策略

流量分析策略采用雙向移動策略,分組粒度更細,是在分組降級策略基礎上進一步根據流量計數進行分組,按天按周甚至按月在流量低峰時移動,如圖6所示。

圖6 流量分析策略圖Fig.6 Traffic analysis strategy diagram

3.5.3 多維度動態調整策略

多維度動態調整策略除了采用上述兩種策略外,還采用了流量大小、region個數、壓縮格式、自定義表權重、表列數量、表value大小等策略。這些策略需要多維度組件結合具體的業務需求進行調整,在資源有限的情況下不推薦使用。

3.6 人機交互模塊

任何系統都不能堪稱完美,需要管理者對系統擁有絕對的控制權,因此人機交互模塊保證了人工對動態分組系統的直接干預。

當啟動動態分組功能,系統就能按照特定的時間對各個業務進行分析處理,并按照預期的策略進行分組調整。調整后系統繼續對分組的各個監控指標進行監控,并按天對指標進行離線分析,得出推薦策略供人工進行策略調整,整個動態分組功能實現閉環,最終趨近于最優狀態。

3.7 動態分組在局域網環境中的應用

實驗模擬業務流量成倍數增加或減少,動態分組功能啟動,按照業務復雜度從低到高進行橫向擴展,期間記錄了各個分組的使用情況如圖7所示。

圖7 分組狀態圖Fig.7 Group state diagram

動態分組系統成功調整了分組并且為業務分配新的分組。調整后機器利用率更加平均,業務平穩運行。

4 結語

本文針對當前業界對HBase分組使用進行了分析與對比,從現有HBase分組功能尋找出多種策略的動態分組方案,并實現了一個局域網的基于HBase的動態分組系統設計。實驗證明該方法能夠有效的對不同的業務場景進行相對合理的動態分組,保證集群穩定性,與常規的人工配置相比,可提高資源利用率,有較好的研究與推廣價值。