基于HBase的健康大數據平臺性能優化及應用

王勇++尹鵬飛++李娟

摘要：健康大數據已被納入國家大數據戰略布局，如何能夠收集有效的健康數據，構建高性能、高可靠性、低成本和具有良好可擴展性的健康大數據平臺至關重要。傳統的單純利用Hadoop、HBase無法滿足復雜的業務需求和實時查詢的要求，同時性能方面也存在一些問題。分析了HBase的底層原理，對HBase的讀寫性能進行優化。借助Phoenix提供的SQL接口來操控HBase，可方便對集群和數據進行管理。Phoenix針對HBase也提出了一系列優化方案。利用HBase和Phoenix的特性構建高性能的健康大數據平臺。實驗結果表明，優化后的健康大數據系統具有更好的讀寫性能，能夠更好地滿足大數據發展需求。

關鍵詞：健康大數據；HBase；分布式數據庫；負載預測

DOIDOI：10.11907/rjdk.171146

中圖分類號：TP319文獻標識碼：文章編號：16727800（2017）010014604

0引言

通過移動互聯網、智能設備和物聯網技術，人們能夠隨時追蹤記錄自己當前的生理健康指標、運動狀況、飲食情況和其它生活習慣，這些數據的收集能夠幫助挖掘出更有價值的醫療信息。然而，技術的發展仍無法跟上數據增長的速度。對于大規模數據的存儲、管理和實時查詢仍然面臨很多問題，同時健康監測數據也缺乏統一標準，使大量數據無法共享利用，這無疑會影響健康監測大數據的發展進程。

本文對健康監測數據的存儲與管理進行研究，根據健康監測數據的數據表示模型和數據形態，采用HBase大數據平臺研究健康監測數據的存儲與組織形式，實現了健康大數據的存儲和管理，并提供高并發的讀寫性能與可擴展性。

HBase是參照Google Bigtable實現的NoSQL數據庫，有著天然的大數據存儲優勢[1]。它具有強一致性、隨機讀寫、面向列，以及可動態修改、可水平伸縮的特性[2]。HBase支持范圍查詢以及行事務，可在廉價PC Server上搭建大規模的結構化存儲集群。HBase非常適合于構建高性能的健康大數據平臺。然而，HBase還處在高速發展時期，仍有一些問題需要解決。Apache的Phoenix為人們操作HBase提供了更加便捷的溝通方式，其提供了標準的SQL和JDBC API的力量與完整的ACID事務的能力和后期綁定的靈活性。目前，關于HBase性能的優化和研究還存在著諸多現實問題，缺乏關鍵技術支持。本文重點研究了基于健康數據存儲的HBase集群的性能優化與應用，并采用HBase1.0.2版本、phoenix4.8版本進行分析實驗，旨在提供一個高性能、高可用的健康大數據存儲和管理平臺。

1健康大數據平臺分析與優化

1.1健康數據模型設計

中華人民共和國國家衛生和計劃生育委員會于2011年8月發布了《城鄉居民健康檔案基本數據集》，規定了城鄉居民健康檔案基本數據集的元數據屬性和數據元目錄。通過研究與分析該數據集，構建了統一的健康檔案存儲模型，并轉化成HBase的數據模型，進行數據庫的設計與實現。

選取《高血壓患者隨訪數據元專用屬性》作為案例進行研究分析。表1是分析得到的高血壓關系模型。其中行鍵采用身份證號碼、醫院編號、醫療項目和時間戳的組合鍵。

其中，NumRegionServer可以采用集群中的RegionServer數目，有利于分擔數據讀寫壓力，但也不宜過多，否則會造成集群性能下降。

1.3HBase數據查詢優化

HBase在0.92之后引入了協處理器（Coprocessors），能夠更好地建立二級索引、復雜過濾器、訪問控制等更為復雜的操作[5]。Phoenix則在此基礎上提供了更加方便的操作。Phoenix能夠用SQL的方式建立二級索引。Phoenix支持4種類型的索引技術：Covered Indexes、Functional Indexes、Global Indexing和Local Indexing，這些索引技術分別適用于不同的業務場景，主要是偏重于讀或寫。

可以通過如下方式直接為HBase創建索引：

CREATE INDEX BLOOD_PRESSURE_INDEX ON BLOOD_PRESSURE （detail.id_number） INCLUDE（detail.user_name，detail.follow_date）

創建了一個名為BLOOD_PRESSURE_INDEX的索引，查詢id_number、user_name、follow_date字段可加快查詢速度，同時也可根據這些字段查詢所需的rowkey。如果查詢字段中包含了不在索引的字段且不是rowkey，索引則不會被觸發到，查詢仍會進行全表掃描。

1.4數據統計與分頁查詢

HBase本身不提供分頁查詢功能，但在實際的應用需求中，難免會用到分頁功能，尤其對于數據量異常龐大的海量數據系統。對于UPDATE STATISTICS BLOOD_PRESSURE，執行命令能加快對BLOOD_PRESSURE表數據統計的查詢速度。關于Phoenix提供的HBase分頁查詢，可以通過以下查詢方式進行：

SELECT *

FROM BLOOD_PRESSURE

WHERE IdNumner = ？ AND Name=？

ORDER BY

PK

LIMIT STARTROW OFFSET ENDROW

根據以上查詢語句，可以根據姓名、身份證號查詢最新的從STARTROW到ENDROW之間的數據內容。

1.5HBase負載預測

雖然Phoenix提供了salted table 功能，可以將寫入的數據隨機分配到不同的RegionServer中，但是隨著集群規模的變化，也許會增加集群節點，也許會有宕機的節點。SALT_BUCKETS是固定的，無法修改。采用負載預測算法，預測HBase節點的負載情況，建立預測模型，提前將過大的region進行split，然后分配到最佳的RegionServer當中，以緩解節點負載。endprint

1.5.1負載均衡定義

令HBase集群系統由m臺服務器組成，根據能力與負載相匹配原則，設集群服務器系統的節點負載能力為Capacity-i（i=1，2，3，4，…，m ）。如果當前的總集群負載為Lsum，每個節點當前的負載量化指標為LRS-i（i=1，2，3，4，…，m ），每個節點應承擔的負載量化指標為LRSAVG-i（i=1，2，3，4，…，m ），則可以得出如下公式：

Capacity-1：Capacity-2：Capacity-3：…：

Capacity-i=a：b：c：…：i（1）

LRSAVG-i=Lsum*i/（a+b+c+…+i）

（i=1，2，3，4，…，m）（2）

如果LRSAVG-i與LRS-i相當，則表示當前節點負載良好，達到了較佳的讀寫性能；反之，說明當前節點的負載偏小或偏大，需根據具體大小進行調整。

1.5.2負載能力定義

為了能夠更好地對比計算機之間的性能，需要將計算機的性能指標進行量化分析。根據集群的性能匹配條件，將網絡流量Lnet、寫請求次數Lwrite、讀請求次數Lread、CPU利用率Lcpu、內存利用率Lmem作為集群監測的主要指標。

圖1為單臺節點的HBase，不斷發送寫數據請求，得到的響應時間折線如圖1所示。

圖1展示了在一定的數據寫入請求下，HBase提供的響應時間的對應關系。通過寫入數據來測試HBase性能，實驗發現，隨著數據量不斷增大，HBase的響應時間也在不斷延長，折線斜率也在上升，直到某個位置出現無法響應的狀況。本次實驗在數據批量寫入70 000條數據時，發現集群無法作出響應。定義一次批量最多寫入的數據條數Lwrite-i（i=1，2，3，4，…，m ）作為集群的負載能力量化指標，同時得出如下公式：

Capacity-i=Lwrite-i（i=1，2，3，4，…，m ）（3）

1.5.3負載預測方法

指數平滑法是一種常用的預測算法，對本期觀測值賦予不同權重來體現下一期的預測值。一次指數平滑法具有嚴重滯后性，不能很好地預測變化趨勢較明顯的場景。為了避免數據的滯后，對數據模型進行了改進，公式如下：

Dt+1=（Yt-Yt-1）+（1-）Dt（t>0）（4）

Ft+1=Yt+（1-）Ft+Dt+1（5）

其中，為平滑系數，取值為0.8。Dt+1為t+1時刻預測模型的差值平滑值，增加Dt+1可以預防指數平滑法引起的滯后性。Ft+1為t+1時刻的負載預測值，Yt為t時刻的實際觀測值，當t為0時，選取F0為Y1。將LRS-i作為上述公式中的Yt進行t時刻的負載預測，判斷節點的負載情況。LRS-i作為節點的總負載情況，每個節點包含多個表的多個region，LRS-i的總負載可以計為i節點中所有region的負載總和。對于region是否拆分，進行如下分析：統計當前table的所有region個數TRCount，如果region的負載大于當前表平均region負載的兩倍，則將此region進行拆分；否則，判斷region的文件大小決定是否拆分。計LTB-RG-i為某個表具體region的負載，LTB-AVGRG為某個表的平均region負載。當LTB-RG-i大于2倍的LTB-AVGRG時，將此region進行拆分。

LTB-RG-i>2*LTB-AVGRG？split：0（6）

Li=LRS-i+12LTB-RG-mLRSAVG-i（i=1，2，3，4，…，m ）（7）

Region拆分后的移動方案，需要綜合考慮節點的Capacity-i和LRSAVG-i，將拆分后的region移動到Li最小的節點中。其中Li代表編號為m的region占用的節點負載容量比值。

1.5.4算法流程

算法詳細描述如下：①建立定時任務，定期執行此算法；②構建監控系統，實時監控系統當前的負載情況、網絡流量、讀寫次數、CPU利用率、內存利用率。一方面可以實時發出報警提醒，另一方面可對將來的集群負載狀態預測提供有利的數據支撐；③預測數據模型，利用HBase的監控性能指標，對HBase的regionserver、region負載進行預測，并制定region的拆分與遷移策略，可以參照公式（5）、（6）；④獲取當前region的負載情況，建立隊列，將region的負載從大到小進行排列，計算所有region均衡負載的量化指標，比較LTB-RG-i和LTB-AVGRG之間的大小關系；如果region的預測負載大于region平均負載的兩倍，則將其進行拆分，拆分后的每個子region分別承擔一半父region的負載。然后，重新排列隊列，直到集群中所有的region都滿足為止；⑤如果當前的region負載實現了平衡，則判斷region文件大小，對于過大的文件同樣采用步驟④的拆分移動策略。算法流程如圖2所示。

Hadoop和HBase都是基于Linux的操作系統，JVM是運行環境下的系統軟件，本實驗環境是在ubuntu操作系統下進行的。上述7個主機是由一臺大型機劃分出的虛擬機得到。

數據的寫入方式通常利用HBase的Java API進行數據操作，采用批量提交數據的方式寫入。優化后的系統采用Phoenix的Jdbc接口進行數據寫入操作，同樣采用批量提交的方式。圖3為通過原始的未改進的HBase集群進行的寫入數據測試和改進方案后的HBase集群寫入數據測試對比結果。

通過圖3的對比結果，改進后的健康大數據平臺在性能上得到了提升，在管理和使用方面也更加便捷。其中，數據的寫入響應時間并不是呈直線上升，而是有波動現象，這與HBase的數據寫入原理相關。HBase采用LSM的結構進行數據讀寫，HBase數據寫入性能同時還會受到WAL、FLUSH等機制影響。但總體而言，相比于原有的HBase方案，仍得到了一定提升。endprint

上述響應時間測試采用隨機查詢的方式，在一定規模的數據中，測試系統的隨機查詢響應時間。通過圖4的對比結果可知，改進后的健康大數據平臺在查詢性能上也得到了提升。通過對比發現，HBase在一定數據范圍內，隨著數據量增長，數據查詢的響應時間并不會隨之增加，這是HBase的查詢結構LSM的一個特性。此外，也可以借助HBase的MemStore和緩存等方法加快查詢速度。

3總結與展望

健康監測大數據平臺的關鍵技術研究對于建設高性能的健康平臺具有重要意義。以健康大數據為業務背景，從健康數據格式統一的角度出發，通過研究《城鄉居民健康檔案基本數據集》，對居民健康檔案數據集提出了統一的存儲模型和方案。研究了大數據存儲和查詢的相關技術，提出利用Hash和預分區方法優化HBase的表結構，利用Phoenix建立的二級索引優化HBase的復雜查詢速度，并利用Phoenix實現的HBase協處理器優化HBase對聚合操作的執行效率。本文提出的一系列改進方案有效提高了健康大數據平臺性能，同時簡化了HBase管理操作，對利用HBase構建可進行實時查詢、處理復雜查詢的應用提供了有價值的參考。

然而，本文沒有對健康數據的相關內容進行深入分析，對于健康檔案的數據模型建立，在實際應用過程中可能存在偏差。利用Phoenix創建的表只能通過Phoenix寫入才能進行查詢顯示，直接用HBase進行操作反而無法

被查詢到，這對數據的寫入方式造成了限制。另外HBase仍然存在著諸多問題，由于底層過度依賴于Hadoop的HDFS，使其性能瓶頸也受到影響。此外，HBase的查詢和存儲性能的提升需要進一步改進自身結構，隨著硬件系統的不斷發展，HBase可以更多地借助于內存進行存儲和查詢。

參考文獻：

[1]余峰.MYHBASE：一種基于HBASE的NEWSQL數據庫的設計與實現[D].杭州：浙江大學，2012.

[2]景晗，鄭建生，陳鯉文，等.基于MapReduce 和HBase 的海量網絡數據處理[J].科學技術與工程，2015，15（34）：183191.

[3]董新華，李瑞軒，周灣灣，等.Hadoop系統性能優化與功能增強綜述[J].計算機研究與發展，2013，50（S2）：115.

[4]卓海藝.基于HBase的海量數據實時查詢系統設計與實現[D].北京：北京郵電大學，2013.

[5]丁飛，陳長松，張濤，等.基于協處理器的HBase區域級第二索引研究與實現[J].計算機應用，2014，34（A01）：181185.

[6]連加典，劉宏立，謝海波，等.基于預測機制的分級負載均衡算法[J].計算機工程與應用，2015，51（11）：6773.

[7]鄭坤，付艷麗.基于HBase 和GeoTools 的矢量空間數據存儲模型研究[J].計算機應用與軟件，2015，32（3）：2325.

[8]WHITE T. Hadoop： the definitive guide[M].O′reilly Media Inc GravensteinHighway North，2010，215（11）：14.

[9]HAYT， TANSLEYS， TOLLEK. The fourth paradigm：dataintensive science discovery[M]. Redmond，Washington， USA： Microsoft Research， 2009.

[10]RAMAMRITHAM K. Realtime databases[J]. International Journal of Distributed and Paralled Databases（S09268782），1993（2）：199226.

[11]CHANG F， DEAN J， GHEMAWAT S， et al. Bigtable： adistributed storage system for structured data[J].ACM Transactions on Computer Systems （TOCS）（S07342071）， 2006，26（2）：205218.

[12]陶永才，石磊.異構資源環境下的MapReduce性能優化[J].小型微型計算機系統，2013，34（2）：287292.

[13]傅杰，都志輝.一種周期性MapReduce作業的負載均衡策略[J].計算機科學，2013，40（3）：3840.

[14]張春明，芮建武，何婷婷.一種Hadoop小文件存儲和讀取的方法[J].計算機應用與軟件，2012，29（11）：95100.

責任編輯（責任編輯：黃?。〆ndprint