基于HBase的工業(yè)時序大數(shù)據(jù)分布式存儲性能優(yōu)化策略

楊力，陳建廷，向陽

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

0 引言

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

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

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

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

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

1 相關(guān)工作

針對時序數(shù)據(jù)特點所引發(fā)的負載傾斜問題，目前的主流方法是向HBase 引入必要的系統(tǒng)模塊以達到優(yōu)化目的，主要分為預分區(qū)和被動分區(qū)兩類方法。

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

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

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

2 本文方法

2.1 問題描述

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

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

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

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

2.2 優(yōu)化系統(tǒng)整體架構(gòu)

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

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

圖2 引入優(yōu)化策略后的系統(tǒng)架構(gòu)Fig.2 System architecture after introducing optimization strategy

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

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

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

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

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

在該系統(tǒng)架構(gòu)中，時序數(shù)據(jù)的存儲與查詢流程如下：

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

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

3）在負載均衡優(yōu)化策略指導下，預測分類模塊從歷史訪問行為數(shù)據(jù)庫讀取用戶的訪問行為數(shù)據(jù)，利用訪問行為數(shù)據(jù)進行訓練，并根據(jù)用戶訪問信息預測欲查詢或?qū)懭氲臄?shù)據(jù)，輸出數(shù)據(jù)分類結(jié)果信息至索引構(gòu)建/RowKey 拼接模塊。

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

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

2.3 負載均衡優(yōu)化策略

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

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

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

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

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

引入基于冷熱數(shù)據(jù)分區(qū)及訪問行為分類的負載均衡優(yōu)化策略后，Hbase 的寫數(shù)據(jù)流程與負載分布如圖3 所示。

圖3 優(yōu)化策略的寫數(shù)據(jù)流程Fig.3 Writing process of optimization strategy

可以看到，相較于原Hbase 的寫數(shù)據(jù)流程，該系統(tǒng)的寫數(shù)據(jù)流程中，寫數(shù)據(jù)請求負載根據(jù)預測分類結(jié)果均勻存放在相應數(shù)據(jù)分區(qū)中，很好地改善了數(shù)據(jù)寫負載的傾斜問題。優(yōu)化策略的寫數(shù)據(jù)步驟如下：

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

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

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

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

5）索引構(gòu)建/RowKey 拼接模塊根據(jù)接收的數(shù)據(jù)冷熱分類結(jié)果，將數(shù)據(jù)冷熱性按上文所述字段規(guī)則耦合至對應數(shù)據(jù)的RowKey，并將耦合冷熱性后的數(shù)據(jù)以數(shù)據(jù)流的形式寫入不同節(jié)點中對應的冷熱數(shù)據(jù)區(qū)。

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

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

圖4 優(yōu)化策略的讀數(shù)據(jù)流程Fig.4 Reading process of optimization strategy

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

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

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

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

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

2.4 索引主數(shù)據(jù)同Region化策略

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

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

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

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

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

引入索引主數(shù)據(jù)同Region 化策略后，系統(tǒng)查詢數(shù)據(jù)流程如圖6 所示，索引構(gòu)建/RowKey 拼接模塊對具有多級索引查詢需求的部分熱數(shù)據(jù)構(gòu)建對應的索引。優(yōu)化策略的索引查詢數(shù)據(jù)步驟如下：

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

1）用戶群將時序數(shù)據(jù)索引發(fā)送至索引構(gòu)建/RowKey 拼接模塊，模塊按策略返回索引RowKey。

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

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

4）用戶群獲得HRegionServer 許可后，系統(tǒng)按索引RowKey 進行主數(shù)據(jù)搜索。

5）系統(tǒng)將與索引對應的主數(shù)據(jù)返回給用戶群。

3 實驗與結(jié)果分析

3.1 實驗環(huán)境

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

2）軟件環(huán)境。實驗所用操作系統(tǒng)為CentOS 7.6 64 bit；Hadoop 版本為2.7.6；HBase 版本為1.4.13；JDK 版本為1.8。

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

表1 TS數(shù)據(jù)集Tab.1 Time series datasets

3.2 評價指標

采用節(jié) 點負載分布［20］和數(shù)據(jù) 查詢時間［21］評價優(yōu) 化策略。

1）節(jié)點負載分布。在不同數(shù)據(jù)規(guī)模與訪問密集程度下，對優(yōu)化前后的系統(tǒng)各節(jié)點負載進行統(tǒng)計，各節(jié)點上請求數(shù)越均衡，集群資源有效利用率越高，對高頻時序數(shù)據(jù)訪問產(chǎn)生的負載傾斜問題改善越成功。

2）數(shù)據(jù)查詢時間。系統(tǒng)在不同數(shù)據(jù)集下對相同查詢請求處理完成所需時間，數(shù)據(jù)查詢時間越短，數(shù)據(jù)查詢效率越高，優(yōu)化越有效。

3.3 比較方法

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

3.4 節(jié)點負載分布

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

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

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

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

3.5 數(shù)據(jù)查詢時間

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

圖7 數(shù)據(jù)查詢時間對比Fig.7 Comparision of data query time

本文方法與原系統(tǒng)、PUB-HBase 在不同數(shù)據(jù)規(guī)模下對查詢?nèi)蝿账璧木C合查詢時間如表4 所示。在引入數(shù)據(jù)冷熱分區(qū)機制與索引主數(shù)據(jù)優(yōu)化策略后，由于熱數(shù)據(jù)區(qū)數(shù)據(jù)常駐內(nèi)存，且索引與主數(shù)據(jù)處于相同Region 中，減少了系統(tǒng)跨節(jié)點通信帶來的額外開銷，提高了查詢速度，查詢時間變短。相同數(shù)據(jù)規(guī)模下，本文方法的數(shù)據(jù)查詢時間小于原系統(tǒng)和PUB-HBase。相較于原系統(tǒng)與PUB-HBase，本文策略平均查詢效率分別提升27.7%與13.8%。

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

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

圖8 熱數(shù)據(jù)區(qū)命中率與數(shù)據(jù)查詢所需時間關(guān)系Fig.8 Relationship between hot data area hit rate and time required for data query

4 結(jié)語

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

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