基于HBase的工業時序大數據分布式存儲性能優化策略

楊力，陳建廷，向陽

（同濟大學 電子與信息工程學院，上海 201804）

0 引言

隨著信息技術飛速發展，大數據正在成為各大產業領域的重要資產，并且物聯網、5G 等技術的高速發展也導致大數據的范圍擴大化和來源多樣化［1］。隨著全球工業水平提升，工業大數據已成為大數據家族的重要成員，其中時序數據就是重要且典型的工業大數據類型。在各大智能工業場景中，大量不同來源的異構時序性日志數據量呈爆炸式增長，在時序數據規模越來越大的情況下，海量工業時序數據的存儲與管理成為了大數據領域的研究焦點［2］。

廣義的時序數據，即帶有時間信息的數據記錄，通?？梢酝ㄟ^結構化方式表示。時序數據具有時間序列化、時段密集化、單條數據高權重、數據產生高并發、數據總量巨大的特點［3］。在工業場景下，工業時序數據通常由上百臺工業設備的上萬個傳感器產生，各傳感器采樣周期堆疊，并且各數據之間可能存在復雜的依賴關系，因此工業時序數據具有采樣周期密集和強關聯的特點［4］。工業時序數據主要包含設備參數、設備運行狀況、設備負載程度等，反映了各設備在不同單位時間內的工作情況，對分析設備故障、提升設備工作效率進而優化整個工業場景整體管控都具有重要的意義［5］。

因此，工業系統對時序數據具有較高的數據訪問需求?，F有數據存儲系統在面對該需求時極易發生負載不均衡現象，導致系統訪問效率低下。在一些典型業務場景，如超大型自動化碼頭系統中，數以萬計的碼頭設備傳感器在極短的時間內產生大量設備工作狀態時序數據，對于相同傳感器或相近時間段數據的寫入與讀取，通常發生在同一存儲節點上，極易造成存儲節點因訪問數據流量不均衡而引發的負載傾斜問題；且數據高維索引查詢的效率較低，很容易出現數據訪問速度慢，甚至服務器宕機的情況，這會嚴重影響業務流程的運行。因此，工業時序數據存儲系統需要具備平衡數據訪問負載的能力，實現多維度查詢，從而支持對工業時序數據的高密度并發訪問。

HBase 作為一種具有良好可擴展性的分布式列族數據庫，常作為一種通用存儲技術用于海量數據存儲場景［6］。對于數據負載傾斜問題，目前主要基于HBase 的多存儲服務器節點分散分布的特點，通過添加必要的系統模塊以達到優化目的，主要分為預分區與被動分區兩類。預分區方法在數據到來之前將Region 按照行鍵RowKey 進行分區，將后續寫入的數據按不同策略寫入特定分區［7-12］；被動分區方法對數據進行監控，根據數據量、數據訪問頻率等數據變化特性進行動態分區［13-18］。但由于工業時序數據采樣周期密集、強關聯以及訪問需求高的特點，現存的負載均衡方法沒有考慮到特定業務場景中數據與訪問行為特征的關聯，無法滿足特定場景下的數據訪問需求，因此，在工業場景下，面向海量工業時序數據的分布式存儲負載均衡策略值得進一步研究和探索。

本文基于分布式存儲系統HBase 提出面向海量工業時序數據的分布式存儲性能優化策略。針對工業時序數據的負載傾斜問題，本文發現工業系統具有相對固定的時序數據訪問模式，通過對用戶歷史訪問行為模式與數據特征的分析，提出基于冷熱數據分區及訪問行為分類的負載均衡優化策略。將待存儲數據進行冷熱分類并寫入對應分區，進而緩解負載傾斜，提升后續數據讀取效率；同時，為降低存儲集群中跨節點通信開銷以提升工業時序數據高維索引的查詢效率，提出了索引主數據同Region 化策略。在真實工業時序數據上進行了對比實驗，驗證了本文策略能提升工業時序數據的存儲性能，可滿足工業場景下對時序數據的訪問需求。

1 相關工作

針對時序數據特點所引發的負載傾斜問題，目前的主流方法是向HBase 引入必要的系統模塊以達到優化目的，主要分為預分區和被動分區兩類方法。

預分區方法在存儲數據前就設定HBase 中不同數據分區的StartRowKey 和EndRowKey，進行預分區。Van Le等［7］基于Hbase 提出一種針對時序數據的智能存儲策略，在HBase建表之前，根據要存儲的時序數據的特征設計每個分區Region 的StartRowKey 和EndRowKey，然后設計表的預分區，以保證后來的時序數據均勻地分散在不同的Region 中，進而緩解用戶密集訪問高頻時序數據所產生的負載不均衡問題。但隨著時序數據量的指數級增長，單個Region 在很短的時間內就會達到Split 閾值，HBase 為保證數據安全會自動將超過閾值的Region 進行Split 操作，增大了HBase 的系統開銷。王遠等［8］提出在欲插入數據的RowKey 中添加隨機字符串前綴，打亂時序數據插入的順序，以避免將多條連續時序數據寫入同一個Region，巧妙地避免了寫熱點問題；但該方式會同時降低數據查詢的效率，并且忽略了讀熱點問題。Azqueta-Alzúqeta等［9］提出基于MapReduce 并行處理技術預先對寫入的時序數據并行計算RowKey 值，然后根據HBase中各存儲節點HRegionServer 的屬性和數目特征，對數據表進行預分區；通過分布式計算框架MapReduce 并行處理確實加快了對高頻時序數據的準備與存儲過程，但并沒有解決HBase Region 自動Split 而導致HBase 系統開銷增大的問題。雷鳴等［10］提出面向海量氣象半結構化與非結構化數據的HBase 負載均衡策略，通過修改HBase 內置數據分區模塊，改變HBase 的分區規則，以達到負載均衡的目的；但這只是改變了Region 的大小，并沒有考慮不同Region 內存儲的數據被訪問的頻次差別。王璐［11］提出將分表存儲與預分區相結合的策略，在數據寫入前對數據表與預分區進行設計，緩解了HBase 的負載傾斜問題；但該方法并沒有考慮在特定業務場景下不同表處理的數據訪問請求數量的差異。張周［12］提出基于用戶訪問行為預測的HBase 分布式數據存儲系統（HBase data storage system based on User access Behavior Prediction，PUB-HBase），該系統面向網絡安全實驗數據集，對HBase 的數據區進行冷熱分類，對網絡安全日志數據訪問模式進行模型描述，并設計RowKey 字段實現索引與主數據的一致性，緩解負載傾斜問題；但該系統將熱數據區（Hot Data Area）存放在集群磁盤中，降低了熱數據讀取效率，并且對數據讀請求與索引查詢請求字段的額外解析增大了系統處理數據訪問請求的系統開銷。

被動分區方法在系統運行中，通過監控數據存儲量與數據被訪問頻率構建分區并設定分區的分布。Sun等［13］引入數據流塊的概念并對負載進行預測和數據遷移，實現了系統的動態負載均衡，但還需優化數據遷移帶來的系統與網絡開銷。Chen等［14］提出針對HBase 動態負載與數據熱點問題的負載均衡策略，該策略動態考慮數據負載分布的變化，對數據進行動態存儲，在一定程度上緩解了HBase 的負載傾斜問題，但沒有考慮由于收集并處理節點實時負載分布信息而帶來的系統額外開銷。Xiong等［15］提出針對HBase 的負載均衡問題的策略，可分為全局計劃、隨機分配計劃與批量啟動分配計劃，這些計劃對Region 的個數進行管理和分配，改善了負載均衡問題，但并沒有考慮到數據寫熱點問題，因為Region 數目均衡并不能保證實際負載均衡［16］。Ghandour等［17］向HBase 引入負載均衡器，均衡器通過監控熱點訪問數據動態地分割和移動訪問頻率更高的“熱數據”，以提升對特定熱點數據的訪問負載均衡效果；但該策略只是被動地根據用戶訪問行為改變冷熱數據的分布，必然會導致系統在執行負載均衡過程中對一些突發訪問行為改變應對不及時，從而增大HBase 的額外開銷。祝燁［18］提出一種通過搜集集群整體狀態信息對熱點數據進行動態管理的策略，但該策略并未考慮集群狀態信息獲取與匯聚時所產生的額外系統開銷。

現有負載均衡方法沒有考慮特定業務場景中數據與訪問行為特征的關聯性。本文結合預分區與被動分區的思想，考慮了工業系統中時序數據與訪問行為特征的關聯性，在用戶訪問行為到來前，在集群中預先分區為若干冷數據區（Cold Data Area）；在接收到一定數量的用戶訪問請求后，根據用戶訪問行為將寫入的數據進行冷熱分類預測，將預測的熱數據分散存放在不同節點的熱數據分區中，緩解用戶對熱數據高頻密集訪問而導致的負載傾斜問題，并將主數據與多維索引規劃存放在相同Region 中，以提高工業時序數據的多維索引查詢效率。

2 本文方法

2.1 問題描述

在通用分布式集群中，負載均衡讓多個存儲或計算節點在中央處理器（Central Processing Unit，CPU）、網絡流量、內存、磁盤輸入輸出（Input and Output，IO）等資源中分配負載，以達到優化存儲與計算資源的使用、最大化數據吞吐率、最小化請求響應時間的同時避免單一節點過載的目的［19］。負載傾斜，即負載均衡的相反效果，由于單一節點的存儲與計算資源過載，造成CPU 負荷過大、網絡擁塞、磁盤IO 任務隊列過長，導致集群資源無法最大化利用、集群工作效率顯著下降，并影響業務層的運行。

負載傾斜產生的根本原因是在特定業務場景下數據訪問模式的不平衡問題。海量工業時序數據業務場景具有數據采樣周期密集、強關聯以及訪問需求高的特點，現存的負載均衡方法并沒有考慮工業場景中數據與訪問行為特征的關聯，因此對海量工業時序數據的高并發密集訪問會導致請求在集群中單一節點或少數節點上堆積，進而引發CPU、網絡流量、內存、磁盤IO 等資源的不均衡使用，導致系統響應時間增長，訪問失敗率與機器宕機幾率增高，并由于更多數據訪問請求的堆積而進一步加重負載傾斜程度，引發惡性循環，最終影響業務流程的運行。

圖1 描述了在工業時序數據存儲場景下，HBase 集群中由數據的高并發訪問引發的負載傾斜現象。多個用戶并發訪問海量時序數據，造成數據訪問請求在集群中單一節點HRegionServer2 上堆積，此節點承受了超出資源支持限度的請求，而其他2 個節點的資源并沒有充分利用，處于閑置狀態，造成了負載傾斜問題。

圖1 HBase集群負載傾斜Fig.1 HBase cluster load tilt

2.2 優化系統整體架構

對多種具體工業場景下系統時序數據訪問日志進行分析，本文發現在不同的業務場景下，工業系統具有相對固定的時序數據訪問模式，體現為對一些特定特征的數據訪問較頻繁。因此根據用戶訪問請求特征對要寫入系統的數據進行冷熱分類，將常被訪問的熱數據存放在熱數據區，將不常被訪問的冷數據存放在冷數據區。熱數據分散存儲在多個節點中，用戶群后續對熱數據進行高頻訪問時，數據訪問請求能夠較均勻地分散在不同存儲節點上，達到負載均衡。

基于上述思想，本文的系統架構如圖2 所示，由4 個優化模塊和1 個歷史訪問行為數據庫組成，優化模塊包括：數據請求處理模塊、預測分類模塊、索引構建/RowKey 拼接模塊、數據整理模塊。

圖2 引入優化策略后的系統架構Fig.2 System architecture after introducing optimization strategy

1）數據請求處理模塊接收用戶群的時序數據訪問請求，提取用戶所訪問數據的特征，即用戶訪問行為。

2）預測分類模塊根據數據特征對用戶要訪問的數據進行分類，如果判定為熱數據，則將要寫入的數據標記為熱數據，如果判定為冷數據，則將要寫入的數據標記為冷數據。

3）索引構建/RowKey 拼接模塊為冷熱數據構建對應分區的RowKey，并進一步根據主數據的特征，采用索引主數據同Region 化策略，以構建主數據的二級索引。

4）數據整理模塊在集群負載較小時，掃描已經寫入集群的數據，將因用戶訪問行為變動而改變冷熱性質的數據重新篩選分類，讓冷熱數據分類與用戶總體訪問行為更加契合，并將熱數據更新至內存中。

5）歷史訪問行為數據庫存放用戶訪問數據的特征，對數據進行分類判定。

在該系統架構中，時序數據的存儲與查詢流程如下：

1）用戶群向數據請求處理模塊發送時序數據訪問請求，若是存儲數據，則向索引構建/RowKey 拼接模塊傳輸欲存儲的時序數據流。

2）數據請求處理模塊接收讀取、查詢的請求，并提取要讀取數據的特征，傳入歷史訪問行為數據庫中。

3）在負載均衡優化策略指導下，預測分類模塊從歷史訪問行為數據庫讀取用戶的訪問行為數據，利用訪問行為數據進行訓練，并根據用戶訪問信息預測欲查詢或寫入的數據，輸出數據分類結果信息至索引構建/RowKey 拼接模塊。

4）索引構建/RowKey 拼接模塊根據數據冷熱分類結果信息，利用索引主數據同Region 化策略生成主數據的RowKey，發送給HRegionServer 集群，若是存儲數據，集群將數據寫入對應數據分區中；若是查詢數據，則集群將接收到的RowKey 對應數據進行查詢并返回結果至用戶群。

5）在集群負載較小時，數據整理模塊調用預測分類模塊，將冷熱數據區中的數據按照最新分類模型進行分類，篩選出新的冷熱數據，并將這些數據標為對應的冷熱數據類型，傳給索引構建/RowKey 拼接模塊，構建對應的RowKey，分散放置到集群各節點的冷熱數據區中。

2.3 負載均衡優化策略

為了滿足工業時序數據業務場景下的用戶訪問模式，在如圖2 所示架構下，根據用戶訪問請求的數據特征對要寫入系統的數據進行冷熱分類，將后續用戶對熱數據的高頻訪問請求較均勻地分散在不同節點上，達到負載均衡。冷數據即用戶訪問頻率較低且不足以引發負載傾斜的數據，存放在冷數據區；熱數據即用戶訪問頻率較高且容易引發負載傾斜的數據，存放在熱數據區。熱數據區與冷數據區均勻設置于多個HRegionServer 節點中，以保證用戶對冷熱數據的訪問請求負載的均衡。

該策略首先根據具體業務場景制定行鍵RowKey 連接與命名規則，并根據RowKey 規則進行預分區，例如本文策略的默認數據分區RowKey 字段的連接規則為：0 號字節表示節點編號；1 號字節為索引標記位；（0000 0010）2、（0000 0011）2、（0000 0001）2 分別表示熱索引、熱主數據、冷主數據；其余字節為對應分區下具體數據的標識字段。在預測分類模型訓練成功之前，所有數據存放在冷數據區中。

考慮到分類預測模型的模型規模、分類準確率、計算速度等因素，本文使用邏輯回歸（Logistic Regression，LR）模型，輸入用戶讀取數據的特征，并計算出該數據在每分鐘內被訪問的次數，對LR 模型進行訓練，以根據用戶訪問行為對數據進行冷熱分類。

以自動化碼頭上自動引導車（Automated Guided Vehicle，AGV）的可編程邏輯控制器（Programmable Logic Controller，PLC）數據存儲為例，每輛AGV 上都有多個傳感器在特定時刻產生設備狀態數據。將數據特征輸入訓練好的LR 模型，對數據進行冷熱分類，然后輸出數據的冷熱分類結果。在自動化碼頭業務場景，不同生產項目類別的業務自主性、裝卸工藝業務流程、集裝箱運輸路線等特征，都具有特定的運行模式，導致設備狀態時序數據的產生與讀取模式具有相對固定的特點，因此工業時序數據與訪問行為特征存在關聯性。

冷熱數據分類標準為：若數據每分鐘被訪問的次數超過20，歸類為熱數據；否則，歸為冷數據。

引入基于冷熱數據分區及訪問行為分類的負載均衡優化策略后，Hbase 的寫數據流程與負載分布如圖3 所示。

圖3 優化策略的寫數據流程Fig.3 Writing process of optimization strategy

可以看到，相較于原Hbase 的寫數據流程，該系統的寫數據流程中，寫數據請求負載根據預測分類結果均勻存放在相應數據分區中，很好地改善了數據寫負載的傾斜問題。優化策略的寫數據步驟如下：

1）用戶群與本地元數據緩存Meta Cache 交互，讀取meta表所在HRegionServer 節點信息，若Meta Cache 未命中，則連接Zookeeper，獲取meta 表所在HRegionServer 信息。

2）用戶群得到meta 表具體位置，定位它所在HRegionServer 節點，與此節點通信，獲取meta 表，將新的meta 元數據對應信息通過最近最少使用（Least Recently Used，LRU）寫入元數據緩存Meta Cache，根據meta 表訪問要寫入的數據表table 所在的HRegionServer，并建立連接。

3）用戶群獲得HRegionServer 節點許可后，以數據流的形式將要寫入的時序數據特征傳入預測分類模塊。

4）預測分類模塊根據傳入的數據特征，根據所訓練的分類模型對寫入的時序數據進行冷熱分類，并將分類結果輸出至索引構建/RowKey 拼接模塊。

5）索引構建/RowKey 拼接模塊根據接收的數據冷熱分類結果，將數據冷熱性按上文所述字段規則耦合至對應數據的RowKey，并將耦合冷熱性后的數據以數據流的形式寫入不同節點中對應的冷熱數據區。

6）在集群負載較小時，數據整理模塊調用預測分類模塊，將冷熱數據區中的數據按照最新分類模型分類，篩選出新的冷熱數據，并將這些數據標為對應的冷熱數據類型，傳給索引構建/RowKey 拼接模塊，構建對應的RowKey，并分散放置到集群各節點的冷熱數據區中，此步驟未在圖中給出。

引入基于冷熱數據分區及訪問行為分類的負載均衡優化策略后，Hbase 的讀數據流程與負載分布如圖4 所示。在引入了數據請求處理模塊后，用戶讀取數據的特征被提取并保存至歷史訪問行為數據庫，用于訓練預測分類模塊，并對寫入數據進行冷熱分類。優化策略的讀數據步驟如下。

圖4 優化策略的讀數據流程Fig.4 Reading process of optimization strategy

1）用戶群與本地元數據緩存Meta Cache 交互，讀取meta表所在HRegionServer 節點信息，若Meta Cache 未命中，則連接Zookeeper，獲取meta 表所在HRegionServer 信息。

2）用戶群得到meta 表具體位置，定位它所在HRegionServer 節點，與此節點通信，獲取meta 表，將此新的meta 元數據對應信息通過LRU 寫入元數據緩存Meta Cache，并根據meta 表訪問要讀取的數據表table 所在的HRegionServer，建立連接。

3）數據請求處理模塊接收用戶群的訪問數據請求，并將訪問請求通過用戶群與節點之間的連接發送至對應數據所在的HregionServer。

4）數據請求處理模塊提取用戶群要讀取數據的特征，以數據流的形式傳入歷史訪問行為數據庫中。

5）系統根據RowKey 同時訪問讀數據緩存Block Cache、數據內存副本MemStore 和已寫入磁盤的文件StoreFile，將提取的數據進行合并比較，系統將同一索引下時間戳最大的數據返回給用戶群。

2.4 索引主數據同Region化策略

在工業時序大數據場景下，若想要查詢某個時間段中某設備在某地的狀態數據，需要多次訪問該數據所在表，因此需要二級甚至多級索引以優化查詢性能。雖然HBase 提供二級索引構建功能，但HBase 默認二級索引RowKey 沒有適應主數據分區的構建策略，導致在存儲的數據規模逐漸增大的情況下，二級索引與主數據不在同一個Region 甚至不處于同一個HRegionServer 中，在高頻查詢過程中，導致HRegionServer 之間的跨節點通信、數據查詢所需的系統開銷增加，數據查詢效率降低。

面向時序數據的索引主數據同Region 化策略通過用戶歷史訪問行為統計匯總用戶最常訪問的數據列特征，并構建二級索引，將索引與對應主數據存放在同一Region 中。在發生Region 遷移時，索引與主數據同時遷移，無需對索引進行額外維護，避免了索引跨節點查詢導致對應主數據及索引遷移維護帶來的系統開銷。在索引構建的主要流程中，同Region 化策略與原系統索引并無差別，不會產生額外的性能和內存開銷。

二級索引與普通數據類似，通過RowKey 唯一確定。二級索引的數據值value 對應主數據的RowKey。二級索引與主數據的行鍵RowKey 由4 個字段組成，二級索引的RowKey字段設計如圖5 所示。

圖5 二級索引的RowKey字段設計Fig.5 Secondary index RowKey field design

RowKey 首字節（0 號字節）為集群中服務器的節點編號，假設集群中服務器節點數為n，則RowKey 首字節范圍?。?，n），表示該條數據所在服務器節點。1 號字節最低位用于區分索引與主數據，0 代表索引，1 代表主數據；次低位用于區分數據冷熱類別，0 為冷數據，1 為熱數據。2～9 號字節為RegionID，唯一標識一個節點中的Region。10～（9+m）號字節為根據主數據各列族特征進行哈希變換的字段，m為保證特定場景下數據存儲規模與RowKey 唯一性所需最小字節數。

引入索引主數據同Region 化策略后，系統查詢數據流程如圖6 所示，索引構建/RowKey 拼接模塊對具有多級索引查詢需求的部分熱數據構建對應的索引。優化策略的索引查詢數據步驟如下：

圖6 優化策略的索引查詢流程Fig.6 Index query process of optimization strategy

1）用戶群將時序數據索引發送至索引構建/RowKey 拼接模塊，模塊按策略返回索引RowKey。

2）用戶群與本地元數據緩存Meta Cache 交互，讀取meta表所在HRegionServer 節點信息，若Meta Cache 未命中，則連接Zookeeper，獲取meta 表所在HRegionServer 信息。

3）用戶群得到meta 表具體位置，定位它所在HRegionServer 節點，與此節點通信，獲取meta 表，將此新的meta 元數據對應信息通過LRU 的方式寫入元數據緩存Meta Cache，并根據meta 表訪問要讀取的數據表table 所在的HRegionServer，建立連接。

4）用戶群獲得HRegionServer 許可后，系統按索引RowKey 進行主數據搜索。

5）系統將與索引對應的主數據返回給用戶群。

3 實驗與結果分析

3.1 實驗環境

1）硬件環境。實驗所用HBase 集群由1 個master 節點與3 個HRegionServer 節點組成。服務器節點型號均為Dell PowerEdge R720，采用Intel Cascade Lake 3.0 GHz 處理器，24 GB 內存，14 TB 硬盤。

2）軟件環境。實驗所用操作系統為CentOS 7.6 64 bit；Hadoop 版本為2.7.6；HBase 版本為1.4.13；JDK 版本為1.8。

3）測試數據。本文采用自動化碼頭中AGV 產生的設備狀態數據，包含了設備在某一時刻的運行狀態、電量、運行速度、運轉功率等信息，屬于典型的工業時序數據，具有時間序列化、時段密集化、數據產生高并發、數據總量巨大的特點。實驗數據由130 輛AGV 在2020 年7 月至2021 年1 月不間斷運轉所產生，共2.4× 108條。為了論證存儲性能優化策略在數據規模越大的條件下，優勢越明顯，實驗將該數據集進行數據規模遞增的劃分，共分出9 個子數據集。表1 列出了實驗所用時序（Time Series，TS）數據集的相關信息。

表1 TS數據集Tab.1 Time series datasets

3.2 評價指標

采用節 點負載分布［20］和數據 查詢時間［21］評價優 化策略。

1）節點負載分布。在不同數據規模與訪問密集程度下，對優化前后的系統各節點負載進行統計，各節點上請求數越均衡，集群資源有效利用率越高，對高頻時序數據訪問產生的負載傾斜問題改善越成功。

2）數據查詢時間。系統在不同數據集下對相同查詢請求處理完成所需時間，數據查詢時間越短，數據查詢效率越高，優化越有效。

3.3 比較方法

將本文方法與預分區方法和被動分區方法中具有代表性的方法進行實驗對比，包括：PUB-HBase［12］和分級負載均衡器（Hierarchical load Balancer，HBalancer）［14］。PUB-HBase面向網絡安全實驗數據集，對HBase 的數據區進行冷熱分類，對網絡安全日志數據訪問模式進行模型描述，并預測用戶讀數據請求，通過RowKey 字段設計實現索引與數據的一致性，進而緩解負載傾斜，并提升數據查詢效率。HBalancer動態收集并考慮數據負載分布的變化，對數據進行動態存儲，從而在一定程度上緩解負載傾斜問題。

3.4 節點負載分布

在不同規模的數據集下，本文采用不同節點處理的請求數的標準差代表節點負載分布的傾斜程度，標準差越大，不同節點處理請求數量差別越大，負載傾斜程度越高。在不同數據量下，使用PUB-HBase、HBalancer、本文方法后，系統在工業場景訪問模式下各HRegionServer 集群的負載傾斜程度如表2 所示。在不同數據規模下，相較于原系統、PUBHBase、Hbalancer，引入本文策略后系統的集群負載傾斜度明顯降低，極大地改善了原系統存在的負載傾斜問題，且負載均衡效果優于另外兩種方法。引入本文方法后系統的負載傾斜度相較于原系統、PUB-HBase、HBalancer 分別平均降低了28.5%、16.1%、12.5%。

表2 不同方法在不同數據量下的負載傾斜度Tab.2 Load tilts of different methods under different data volumes

表3 列出了預測分類模塊的預測精度與訓練數據量、訓練時間之間的關系。在訓練數據量為0.54 GB 時，模型精度較低，僅有76.36%。隨著訓練數據量的增大，模型訓練時間和模型預測精度都隨之上升。當訓練數據量達到4.50 GB時，模型精度較高，為85.42%，模型預測精度的增長變緩，預測精度滿足數據冷熱分區策略的模型精度需求，且訓練時間為3 048.49 s，滿足系統的即時性訪問需求。

表3 在不同訓練量下的訓練時間和預測精度Tab.3 Train times and prediction accuracyies under different training volumes

3.5 數據查詢時間

只引入本文同Region 化策略的系統與原系統、PUBHBase 通過索引搜索數據所用的時間如圖7 所示?？梢钥闯?，單獨引入本文同Region 化策略的系統通過索引查詢數據所用時間短于原系統和PUB-Hbase。并且隨著數據量增大，數據查詢時間縮短效果更明顯，說明同Region 化策略能夠在索引查詢數據過程中減少HRegionServer 之間額外的跨節點通信以及帶來的系統開銷，提升數據查詢效率。

圖7 數據查詢時間對比Fig.7 Comparision of data query time

本文方法與原系統、PUB-HBase 在不同數據規模下對查詢任務所需的綜合查詢時間如表4 所示。在引入數據冷熱分區機制與索引主數據優化策略后，由于熱數據區數據常駐內存，且索引與主數據處于相同Region 中，減少了系統跨節點通信帶來的額外開銷，提高了查詢速度，查詢時間變短。相同數據規模下，本文方法的數據查詢時間小于原系統和PUB-HBase。相較于原系統與PUB-HBase，本文策略平均查詢效率分別提升27.7%與13.8%。

表4 綜合數據查詢時間對比 單位：ms Tab.4 Comparision of comprehensive data query time unit：ms

為進一步驗證冷熱數據分區對數據查詢時間的優化作用，實驗研究了熱數據區命中率與數據查詢時間的關系。在不同數據規模下，優化后的系統熱數據區命中率與數據查詢所需時間的關系如圖8 所示。從圖8 可以看出，熱數據區命中率越高，查詢所需時間越短，這是因為熱數據常駐于內存中，而冷數據存儲在磁盤中，當用戶群的訪問請求命中熱數據區時，數據直接在內存中被訪問，數據訪問速度更快，訪問時間更短。當數據規模達到TS7 至TS9 時，圖像線條傾斜程度增大，這表明數據規模越大，熱數據區命中率對數據查詢時間縮短效果越明顯。

圖8 熱數據區命中率與數據查詢所需時間關系Fig.8 Relationship between hot data area hit rate and time required for data query

4 結語

本文基于HBase 提出了面向海量工業時序數據的分布式存儲性能優化策略：基于冷熱數據分區及訪問行為分類的負載均衡優化策略；索引主數據同Region 化策略?；诶錈釘祿謪^及訪問行為分類的負載均衡優化策略，引入數據冷熱分區的概念以及用戶訪問行為預測分類模型，根據用戶訪問請求特征對要寫入系統的數據進行冷熱分類并存放在相應數據區，將后續用戶對熱數據的高頻訪問請求均勻地分散在不同節點上，緩解了由工業時序數據特點引發的負載傾斜問題；索引主數據同Region 化策略，匯總用戶最常訪問的數據列特征，并設計索引RowKey 字段，提升了工業時序數據高維索引的查詢效率。

通過與原Hbase 的實驗對比表明，在工業時序數據存儲場景下，本文的優化策略在兩種指標上都取得了明顯的提升。雖然本文策略被實驗驗證具有一定的有效性，但對數據訪問模式的穩定性具有較高的要求，如果訪問模式頻繁改變，則難以有效劃分冷熱數據。在后續工作中，可以通過設置更靈活且更緊湊的分類模型訓練時間來提升系統對訪問模式改變的適應性，進而達到更好的性能。