基于熱點訪問的分布式數據庫HBase負載均衡算法研究

李峻屹

(陜西警官職業學院，信息技術系， 陜西，西安 710021)

0 引言

隨著信息技術的普及，日常生活中的各個領域都離不開信息化系統，系統運行需要進行海量數據的存儲及讀取操作，單一計算機無法實現高效處理，在這種背景下分布式數據庫應運而生。分布式數據庫將物理上集中的數據庫分散為多個數據存儲單元存儲于多個存儲節點之中，利用網絡將存儲節點連接起來組成分布式數據庫。這種方式具有更高的處理性能，但由于每個節點的訪問頻率不同容易導致部分節點負載過重、性能下降甚至崩潰。因此，需要設計良好的負載均衡策略，利用均衡分配提升分布式數據庫的穩定性。本研究以HBase開源分布式數據庫為例，研究一種改進的負載均衡算法，以此規避節點崩潰風險、提升分布式數據庫的安全性。

1 核心理論及技術簡介

1.1 HBase簡介

HBase是利用BigTable思想實現分布式面向列的數據庫，在Hadoop上實現了類似于BigTable的存儲功能，具有多維、稀疏、持久化映射等特性，在非結構化數據的存儲方面具有高可靠性、高性能以及高伸縮性，在大規模集群中應用廣泛[1]。

1.2 HBase數據格式

某種意義上來講HBase可以看作巨大的表，通過行鍵Rowkey、列族ColumnFamily、時間戳Timestamp等實現信息檢索，在缺失時間戳的情況下默認返回最新數據。利用JSON數據格式可直觀展示HBase數據模型，JSON格式可表示為[2-3]

RowKey{

ColumnFamilyA{

ColumnX：

t2 value2

t1 value1

ColumnY：

t1 value4

}

ColumnFamilyB{

t2 value3

}

}

HBase分布式數據庫在結構上包括客戶端Client、分布式服務組件ZooKeeper、主服務器Master、Region Server服務器以及文件系統hdfs 5個部分組成。總體架構如圖1所示。其中,Client負責與Master、Region Server進行通信，ZooKeeper負責節點監控狀況感知、同步及配置管理等服務，Master負責集群負載均衡管理，Region Server Cluster負責Region的讀寫，實現數據處理。Region是HBase中的基本單元，由Store組成，分布于集群的各個節點之中，每個Region擴大到一定大小之后會進行自動拆分。Store作為Region的存儲單元主要包括MemStore和StoreFile。接收到寫入請求時，數據線寫入MemStore，達到閾值后再存入HFile[4-5]。

圖1 HBase架構

1.3 負載均衡分類

目前市面上存在多種負載均衡產品，從不同的側重點實現不同場景下的均衡算法，常用的負載均衡技術包括以下幾類。

(1) 軟件和硬件。硬件方式主要是增加節點數量，一方面增加了成本,另一方面也造成資源浪費；軟件方式主要是利用均衡算法進行負載分配，成本低且易實現。

(2) 本地和全局。本地方式是節點均在本地，通過設備搭建排除節點故障；全局方式則是節點處于不同位置，適用于各地均存在設備的大型公司。

(3) 網絡。網絡層是OSI的7層網絡模型根據不同層面制定不同的負載策略。

(4) 鏈路。將網絡中多條鏈路看做一條，根據IP匹配運營商接口進行分流。

因此，綜合對比之下，本研究采用軟件方式利用算法實現HBase分布式數據庫的負載均衡。

2 HBase原有負載策略及缺陷

2.1 HBase原有負載策略

HBase原有負載策略主要調整集群節點的Region數量來實現。首先，篩選出負載過重或空閑的節點。然后，利用迭代的方式調整節點Region進行交換或者遷移，根據判定因素保留有效調整，在調整后各節點的數值近似時完成負載均衡。通過使用空間總和、節點數量計算單個節點在均衡后的目標空間使用率如式(1)[6-7],

(1)

式中,avgcnt為空間利用率，regioncount為區域空間，servercount為節點數量，利用配置項slop計算閾值的上限ceil與下限floor：

floor=Math.fioor(avg_cnt×(1-slop))

(2)

ceil=Math.ceil(avg_cnt×(1+slop))

(3)

以此上下限閾值進行篩選，將篩選出的節點作為一個邏輯新集群，利用遷移計劃表記錄Region的遷移及交換情況。設目前集群狀態值為cost，cost值的計算包括3個影響因素：

(4)

圖2 原有策略算法流程

2.2 原有策略缺陷

HBase的原負載策略必須是3個重要環節都不出差錯才能實現均衡，在策略上存在缺陷：首先，節點篩選過程必須找出全部的空閑及過載節點;其次，需要根據當前準確負載情況才能確定判定因素;最后，迭代方式的選擇需考慮計算過程中的潛在問題，但它只考慮分布式數據庫集群節點的空間負載情況，未考慮節點存在熱點訪問的情況。

3 基于熱點訪問改進的負載均衡算法設計與實現

3.1 改進算法流程

針對原有策略的缺陷，基于熱點訪問對負載均衡算法進行改進。首先根據熱點訪問負載情況篩選出需要調整的節點，然后再進行region調整。與此同時，判定因素也基于熱點訪問進行確定，迭代時以不破壞已有環境為前提逐步進行調整與優化。改進的方面主要包括以下幾點。

(1) 信息采集時既需要收集region count，也需要收集節點的request數，并且記錄region與request的關系。

(2) 針對原算法中最終集群以及初始集群里未篩選到的節點，再次計算request per second值以及floor_req、ceil_req值如式(5)～式(7)：

(5)

floorreq=avgreq×(1-reqslop)

(6)

ceilreq=avgreq×(1+reqslop)

(7)

其中,server_count為節點數量，floorreq、ceilreq為是否需要進行負載調整的閾值下限與上限，avg_req為空間利用率負載，reqslop為配置項。

(3) 計算集群狀態cost值時，除了region遷移成本和region本地化成本之外還要考慮熱點訪問的負載情況，采用加權平方和進行計算[8-9]，即：

(8)

(4) 選擇策略時cost值計算依然沿用原有方式：計算新的cost值與前值比較，保留有效調整存于遷移計劃表。

(5) 重復改進策略直至迭代次數，按照遷移計劃表執行即可[10-11]。

整體改進后基于熱點訪問的負載均衡算法流程如圖3所示。

圖3 基于熱點訪問改進的算法流程

3.2 算法實現

在算法實現上基于熱點訪問的負載均衡算法主要包括采集模塊、處理模塊及迭代模塊3個部分。首先，采集模塊負責收集節點的count數、request數并與region對應；其次，處理模塊負責計算閾值對節點進行篩選并將request值進行記錄，request表結構如表1所示。其中,第一橫行為region_id，regionx_x代表節點，第二行為region在上一時段的request數量，最后一行為region在當前時段的request計數器，隨讀寫次數而增加。在一個采集時段結束之后，利用request cnt數據更新request值并將request cnt置為0。最后，迭代模塊計算cost值并實現數值對比后選擇策略進行迭代[12-13]。

表1 request表結構

4 改進算法效果驗證

4.1 驗證環境準備

為了驗證改進負載均衡算法的有效性及算法的均衡效果，通過虛擬機VMware搭建Hadoop集群環境進行測試，版本采用HBase1.2.6，各個節點Master、S1、S2、S3分別分配置20G空間、1G內存。

采用原負載策略與基于熱點訪問改進的算法進行對比分析，利用同樣的shell讀寫數據，確保2種算法的初始數據一致[6]。

4.2 驗證結果對比分析

對3個節點分別寫入數據，采集region與request值，得到在負載均衡前后2種算法各個節點的region count數量與request數量對比結果如圖4和圖5所示。

圖4 region count值對比結果

圖5 request值對比結果

由圖4可知，未執行負載均衡前各節點的region count數量相差較大，進行負載均衡后2種算法都達到了較好的均衡效果。由圖5可知，若利用shell腳本只對S1節點讀寫數據(即S1節點處于熱點訪問)時，原策略不能達到均衡狀態，而改進的算法各節點的request值相差不大，均衡效果更好，性能更為優異[14-15]。

5 總結

本研究分析了HBase數據格式及系統架構，通過比較當前負載產品的優缺點，最終選擇軟件方式對HBase數據庫進行負載均衡，根據原有策略的缺陷提出了基于熱點訪問的改進算法。經過驗證與分析，改進算法負載均衡效果更佳。但也有不足之處，改進算法是以集群中各節點的性能一致為前提，未考慮節點自身性能的差異。后續將繼續研究節點性能的評估算法，改進算法在節點自身性能不同情況下的均衡策略。