HBase數據庫行鍵設計及驗證

李興菊 趙建軍 聶紅梅 王迎

摘要：HBase列式非關系型數據庫行鍵設計決定了海量數據存儲與查詢效率。針對目前存在的數據存儲問題及檢索效率問題，對現有5種主流方法進行數據測試后，選擇了相對較優的哈希前綴法，井在原有基礎上根據智慧水務系統中的數據結構特性，使用重要字段提升法結合逆序行鍵方法進行設計.驗證結果顯示，該行鍵組合法針對智慧水務中的時序性數據，在存儲方面解決了寫入熱點與存儲分散相矛盾的問題，檢索效率在原有哈希前綴法基礎上也有了一定提升。

關鍵詞：HBase;數據庫;行鍵;數據模型;智慧水務

DOI：10.11907/ejdk.191271開放科學（資源服務）標識碼（OSID）：

中圖分類號：TP391文獻標識碼：A 文章編號：1672-7800（2019）010-0178-04

0引言

非關系型數據庫系統（Not only SQL，NoSQL）的誕生解決了互聯網Web2.0時代帶來的數據存儲處理瓶頸問題，非關系型數據庫由于具有高并發性以及強大的擴展性等優點，彌補了關系型數據庫的不足。非關系型數據庫中的列式存儲系統HBase的出現更是在很大程度上解決了數據存儲問題，并一度使HBase成為當前的熱門存儲技術之一。雖然目前已有很多針對HBase存儲與查詢的相關研究，但由于應用場景及存儲數據結構的不同，使設計的HBase存儲模式無法解決數據在存儲與查詢過程中面臨的效率問題。根據大量針對HBase的相關研究，選擇對HBase數據存儲與查詢影響相對較大的部分——行鍵設計進行討論。例如在文獻中對HBase數據庫模式設計進行討論，并采用組合方法設計了行鍵，但其僅注重模式選擇，而對行鍵具體設計并未作過多討論及驗證;圣文順、徐愛萍在數據檢索方面分別使用基于行鍵前綴匹配及關鍵字匹配的方式提高數據檢索效率，但該實現方式需要犧牲數據寫入能力。通過總結以上行鍵設計方法，針對居民用水數據設計了一種相對合理的行鍵，最后對設計結果進行實驗驗證。結果證明該行鍵方法在處理此類數據時，相比其它行鍵方法在解決存儲與檢索熱點問題方面具有一定優勢。

1HBase數據庫

HBase（Hadoop Database）數據庫是非關系型數據庫（NoSQL）的一種，其參考了Google的Bigtable開源分布式系統，使用Hadoop中的分布式文件系統HDFS作為數據底層存儲系統，具有高可靠性、面向列與可伸縮等特性，因其自身的獨特特性，常被用來存儲海量非結構化和半結構化的松散數據。HBase主要具有以下特點：①海量性：可存儲百萬億數量級的數據;②列式存儲特性：不存在數據稀疏性問題，大大節省了存儲開銷;③可擴展性：以HDFS作為底層文件存儲方式，繼承了其可擴展性;④高可靠性：HDFS的冗余備份機制減少了數據丟失情況;⑤高性能：檢索效率可達到毫秒級別。

以上特點一方面體現出其與傳統關系型數據庫的不同，另一方面也體現了HBase在數據管理性能方面的優越性。圖1為HBase系統框架，其不僅展示了HBase的核心組件，還展示了與Hadoop在數據存儲工作中的關系。圖1中HBase的4個核心組件分別是客戶端（Client）、主服務器（Master）、Region服務器以及協調服務器（Zookeeper）。客戶端是人們與HBase通話的人口，Zookeeper用來從眾多Master中選出一個集群總管，以保證在任何時刻都有唯一一個Master節點在工作，避免出現“單點失效”問題;Mas-ter服務器負責對每個Region服務器進行協調，將集中在某個Region服務器的操作均衡分配到負載較輕的服務器中，準確地說是對整個集群進行管理;Region服務器負責對其下面的Region提供讀寫操作，當Region超過分配值大小時對其進行拆分，并對單個小文件進行合并。

2HBase數據模型

HBase是一個稀疏、多維度、排序的映射表，該表的索引是行鍵、列族、列限定符與時間戳。圖2為HBase數據模型。

HBase與普通數據庫都采用表組織數據，整張表由行和列組成，可以有若干行，其使用行鍵進行標識，是HBase中的唯一索引。由多個列構成的列族也是表的組成部分之一，每個單元格通過行、列族與列限定符確定，單元格中的數據還未定義數據類型，通常情況下默認為字節數組。單元格中使用時間戳區分不同時刻的數據版本，時間戳通常也參與單元格定位，故行鍵、列族、列限定符與時間戳用來確定一個唯一單元格。

3行鍵設計

HBase中不管是表列族存儲還是Region劃分都是基于行鍵進行的，因此HBase的存儲結構很大一部分都與行鍵設計有關，對HBase數據庫以及數據模型的基本認識有利于針對不同數據管理進行行鍵設計。由于HBase在存儲時使用列族而非列進行數據分割，底層存儲使用列族將數據線性存人單元格中，每個列族則按照行鍵使用其字典順序進行數據存儲。行鍵設計決定了每個Region中數據將如何存儲，由于行鍵一旦被創建則無法更改，所以行鍵設計中不僅要考慮在同一時間段讀寫操作都集中在某一個Region上而出現的負載不均衡問題，還要考慮針對特定應用場景如何提高數據檢索效率，達到對海量異構數據的高效讀寫。針對負載均衡及查詢效率問題，對行鍵設計進行討論是至關重要的，而其設計必須以預期的訪問模式進行。

3.1以檢索為主的行鍵方法設計

行鍵作為HBase中的唯一索引，只能在行鍵上建立索引，在對數據庫進行訪問時最主要的方法是通過行鍵進行訪問，也即是說HBase在數據讀取時是按照RowKey進行快速檢索的，如果設置的行鍵無法滿足檢索條件，或用戶使用的檢索條件不匹配時，則只能采用全表掃描方法，在數據量相對較少的情況下，該方式對HBase的性能不會產生太大影響，但一旦存儲的數據規模增大后，這種全表掃描方法則會使得查詢效率大大降低。

在HBase數據模型中，整張表包括了行、列族、列限定符與時間戳等幾個重要部分，考慮是否可以將其中每一部分作為行鍵進行設計，然后對每一部分作為行鍵結果進行討論。

方法一：將時間戳單獨作為行鍵。時間戳代表同一份數據的多個版本，其作為用戶數據檢索時的一個重要部分，當前很多傳感器、監控儀器等智能設備產生的數據都以時間作為存儲標志，或用戶在不同時刻對表中數據進行修改更新時，相應單元格會對該時間戳進行保存。目前也有很多行鍵設計方法使用時間戳對查詢方法進行優化。在文獻中將時間戳作為行鍵的一部分，使用Long.MAX_value對產生的數據時間戳進行逆序存儲，以保證用戶始終能最先查詢到更新后的數據。該方法針對時序性強的數據范圍查詢具有一定優勢，具體實現方法為：Long.MAX value-timestamp。

方法二：使用列限定符作為行鍵。用戶在查詢數據時可以將列限定符作為行鍵，以檢索或排除用戶需要查詢的數據，也能在特定條件下實現查詢優化。但當一個表中包含很多列時，如果將列直接作為行鍵進行數據檢索依然會出現查詢條件不匹配的問題，因而必須進行全表掃描操作。對行、列族、列限定符與時間戳作為行鍵時的查詢性能進行測試，測試結果如圖3所示。

使用單獨時間戳或列限定符等很難達到提高檢索效率的目的，當用戶無法使用行鍵中的字段或使用其它數據進行查詢時，即對不匹配的數據查詢起不到作用或作用很小，考慮將其進行組合進行行鍵設計以提高檢索效率。

方法三：組合方法。采用組合方法是可行的，但為了提高數據查詢性能，將行鍵索引放在內存中進行緩存，如果使用組合方法將表中全部數據放人行鍵中會使其長度過長，將不得不占用更大內存，從而導致內存利用率降低。所以在進行組合時一方面要考慮行鍵長度，盡可能使行鍵長度較短，另一方面，針對處理的數據特點及用戶檢索習慣，將常用字段作為行鍵的一部分進行組合。結合以上兩個原則設計行鍵則能在一定程度上提高數據查詢效率。

通過以上分析發現：行鍵設計無法達到盡善盡美，只能根據具體情況，在設計時根據權重進行取舍，從表中找出針對該場景最關鍵的查詢條件進行設計，使檢索效率相對較高。

3.2以寫為主的行鍵設計方法

行鍵是一串二進制碼流，使用字典順序由低到高地存儲在表中。在進行Region劃分吋必須基于行鍵進行，通常情況下行鍵生成是采用ID自增的方式，或默認采用時間戳作為行鍵起始值。目前針對時間序列數據的行鍵設計方法有很多，隨著各種傳感器、監控系統等智能設備的逐漸普及，由它們產生數據最為突出的特點是時間序列性很明確，針對這類數據最棘手的問題則是如何避免系統在寫入過程中因操作過分集中于某個Region而產生讀寫熱點，從而使系統整體性能下降。思考如何將這類數據分散存儲到每個Region服務器上是解決問題的出發點。有很多方法都能達到目的，當前最主要的幾種行鍵設計方法有：

（1）隨機生成行鍵法。通過散列函數（如：MD5）在原來生成的相鄰鍵前加上隨機生成的一個前綴，通過該方法生成的行鍵可以解決原本行鍵造成的負載不均衡問題，將寫負載相對均勻地分布到Region上，但缺點是：每次只能檢索一行數據，無法再按時間范圍掃描數據。如：

Byte[]row key=MD5（timestamp）

（2）哈希前綴法。使用哈希函數將原本行鍵中選定的一部分進行哈希運算后作為行鍵前綴，從而避免將時間序列作為行鍵造成的寫入熱點問題，同樣也能達到負載均衡。如：

但該方法的缺點是：行鍵離散化使得之前連續的數據被離散到不同Region中，雖然解決了寫入熱點問題，卻導致檢索一個連續范圍內的數據時系統性能下降，這是以犧牲查詢性能為代價實現的。

（3）提升字段法。行鍵以時間戳為前綴，提升字段法是指改變生成時間戳的位置，使用其它字段作為前綴，或添加其它字段作為前綴，讓連續遞增的時間戳在行鍵中的權重降低，這種組合行鍵方法也可以解決寫入熱點問題。

（4）反轉行鍵法。將原本相鄰的行鍵按字節順序進行反轉，使新生產的行鍵順序離散化，從而實現熱點均衡。

4案列設計

4.1數據源分析

智慧水務系統通過數據采集儀、無線網絡、水質水壓表等多種在線監測設備實時感知城鎮供排水系統運行狀態，并在該循環過程中建立水務互聯網。通過在此基礎上對一些數據進行分析處理，不僅可以減少人力支出，而且可以從各種智能設備上獲取有價值的數據，并結合一定分析手段對數據加以利用。智能水務系統的不斷完善使供水過程監控更加智能化和協調化，隨著經濟的發展與城市規模的逐漸擴張，各城市水司供水半徑擴大，管網復雜程度提高，人力成本與運營難度也不斷提高。由于人們對安全、優質、高效供水服務的需求越來越迫切，以及階梯水價振幅政策的實施，對水務運營也提出了更高要求。通過物聯網、信息化手段改變傳統自來水公司的運營模式與經營模式，構建基于物聯網、云計算的智慧水務管控一體化平臺，已成為水務公司提高運營效率的必然選擇。另外，考慮到掌上辦公的便捷性，各種結合移動端的APP也相繼出現，為打造安全、優質、高效、低碳、環保的供水新模式、建設現代水務企業提供了有效途徑，也使現有數據存儲方法面臨巨大挑戰。為使智慧水務系統中從各種傳感器與監控儀器等智能設備收集而來的以時間序列為主的數據能為整個決策過程提供更大的價值支持，在分析HBase數據模型、行鍵設計原則基礎上，針對這類數據進行行鍵設計相關討論。

4.2綜合方案設計

使用以上幾種方法并結合城鎮居民用水數據信息，對HBase數據庫的讀寫性能進行測試。測試數據約有150萬行，得到如表1所示結果。

根據表中的測試結果發現，在4種方法中，字段提升法與哈希前綴法相比其它兩種方法的綜合性能更好。理想情況下行鍵設計是在存儲時讓關聯性強的數據存儲在同一個Region或相鄰Region上，同時在進行大量數據寫入操作時能使數據均衡分布在每個Region上，不會造成寫入熱點問題。智慧水務系統中存儲的數據主要包括：社區ID、用水時間、用水量情況等數據。結合以上測試結果與智慧水務系統中要存儲的時間序列數據，雖然針對以寫為主的智慧水務系統而言，哈希前綴法與提升字段法綜合性能相近，但在數據檢索時哈希前綴法的查詢效率并不高，所以本文采用提升字段法對行鍵進行設計。

5設計

其中，CuID為居民社區號，使用社區號作為行鍵起始值，一方面可以讓同一社區的居民情況存儲在同一個Re-gion上，還可以避免將時間戳作為行鍵起始值造成的熱點問題。Timestamp為用戶用水產生的時間，將時間戳放在中間位置是根據用戶日常查詢習慣，該設計方法解決了用戶在查詢用水情況時因行鍵不匹配而導致的檢索效率降低問題。將HomeID（住戶號）作為行鍵最后一部分，將3部分按該方式進行組合，從而設計出初步的行鍵模型。在初步行鍵設計中利用提升字段法，對最初的時間戳降低權重，從最左邊移到了中間。

建表后對該行鍵方法進行測試后發現，用戶在查詢數據時通常會查詢最近用水情況，所以希望數據存儲時能將最新的數據存放在最前面，實現時間降序排列。根據該需求分析，在原行鍵上進行修改，行鍵設計方法如下：

row

key=>

最后，本文對兩種行鍵設計方法進行實驗測試，測試發現改進后的行鍵設計方法提高了數據讀寫性能，也由此說明行鍵設計既要結合具體應用場景，還要根據數據處理需求，才能最終實現行鍵設計的相對合理化。

6結語

行鍵設計一直是HBase數據存儲中的研究重點，本文研究發現行鍵設計依賴于具體應用場景，針對不同的存儲管理需求，行鍵設計方法也有所區別。本文從以檢索為主和以寫人為主兩方面對行鍵設計進行研究，并對隨機生成行鍵法、哈希前綴法、提升字段法和反轉行鍵法4種方法進行測試，之后根據智慧水務系統數據存儲需求選擇其中的提升字段法進行行鍵設計，通過再次測試對初始方法進行改進，最終得到相對合理的行鍵設計方法，證明了該行鍵設計方法在時間序列數據處理上的有效性。接下來將對該方法作進一步研究，根據行鍵設計原則精簡行鍵長度，實現優化目的。