基于HBase與Netty的煤礦微震時序大數據存儲優化

丁琳琳, 王智涵, 顧英豪, 王凱璐, 包鑫陽

(1.遼寧大學 信息學院, 遼寧 沈陽 110036; 2.遼寧煤電產業控股有限公司紅陽三礦, 遼寧 遼陽 110101)

1 前言

隨著智慧礦山相關技術的發展,煤礦中眾多微震傳感器產生的時序數據呈現出爆炸式增長的態勢。在時序數據規模逐漸增大的背景下,海量煤礦數據微震波形時序數據如何高效、合理地存儲成為了大數據領域的亟待解決的問題,即煤礦微震波形時序大數據存儲問題。時序數據具有時間序列化、時段密集化、單條數據高權重、數據產生高并發、數據總量巨大的特點[1]。煤礦微震時序波形數據作為工業時序數據中的一種,通常是由上百臺工業設備的上萬個傳感器產生,并且各傳感器之間存在著較為復雜的依賴關系,具有采樣周期密集和強關聯的特點[2]。

當前煤礦微震時序大數據的存儲方案,通常可采用傳統文件系統存儲、關系數據庫存儲以及分布式存儲三種方案。對于傳統的文件系統存儲方式,盡管操作簡便,但需重復進行對齊操作和讀取傳感器波形文件操作以滿足后續計算部分的數據需求,導致重復操作占據程序執行的大部分時間,并且無法對數據進行有效管理以及對數據的快速檢索。對于關系型數據庫存儲方式,在存儲煤礦微震波形時序數據時存在高并發事務場景下性能較差、擴展性差等缺點。對于分布式存儲在存儲時序大數據方面,盡管相對于關系型數據庫已經有了一定的優化,但也存在一些缺陷,在煤礦微震波形時序大數據的存儲場景下,需要考慮數據的特征關聯問題、存儲熱點數據問題、存儲分散以及海量數據存儲數據阻塞問題,現有存儲策略均無法較好解決。

因此,針對上述諸多問題,本文采用基于Hadoop分布式平臺[3]的NoSQL非關系型數據庫HBase[4]作為底層存儲介質,因為其在可擴展性、并發度、分布式以及面向列存儲等方面均較為突出。并結合煤礦微震波形時序數據的高并發、時間序列化以及海量數據的特點,采用適用于煤礦微震波形時序數據的表結構設計策略、預分區策略以及行鍵優化策略對存儲性能進行優化。同時,采用Netty[5]網絡通信框架編寫的中間件集群作為數據中轉層,對數據接收層流轉而來的海量數據進行分流處理,有效避免數據阻塞問題。使用Redis內存數據庫[6]的有序集合數據結構實現負載均衡算法的最小連接法[7],使Netty中間件集群中的每個節點都能夠被合理地分配。最終,采用真實的傳感器離線數據對實驗進行了驗證。

2 相關工作

基于HBase數據庫實現的開源時序數據庫OpenTSDB[8]具有優秀的擴展性和伸縮性,可以輕松地水平擴展集群規模來處理大量數據。此外,文獻[9]以時間序列數據的特點為中心,實現了分布式數據庫存儲海量時間序列數據的方法和應用。InfluxDB是一個開源時序數據庫,用于處理時序數據的高性能讀寫操作,InfluxDB具有高性能、易擴展、數據可視化等優點[10]。基于Cassandra[11]數據庫構建的開源時序數據庫KairosDB支持高效存儲和查詢時間序列數據,Kairos還具有支持多種數據類型、提供豐富的查詢接口、易于使用和部署等優點[12]。結合Logstash和Elasticsearch同樣可以實現對時序數據的高效存儲和查詢,并具有良好的擴展性和靈活性[13]。

在HBase分布式數據庫底層存儲原理方面,文獻[14]利用JavaNIO技術設計了一種HBaseRPC客戶端的非阻塞通信模型,文獻[15]則提出了一種存儲大規模空間向量數據的模型,適用于處理大規模數據的應用。另外,文獻[16]基于HBase與Redis高性能緩存,為圖片數據的查詢和存檔性能做出了客觀的貢獻。在存儲優化架構方面,文獻[17]提出了四層結構,并使用Netty網絡通信框架作為數據緩存中間件,該架構在金融時序數據的高并發存儲場景中得到了可觀的優化效果。最后,文獻[18]設計并實現了三層存儲架構,并將數據緩存中間件集群化處理,有效避免了高并發場景下海量傳感器數據阻塞的問題。

以上述研究工作為基礎,本文設計并實現了一種基于HBase與Netty的煤礦微震時序數據存儲優化方案。該方案綜合了多個方面的優化措施,成功解決了煤礦微震時序數據存儲分散以及存儲熱點等問題。同時,該方案在高并發事務處理方面也有可觀的優化效果,大幅提升了存儲效率,為煤礦微震時序數據的存儲和處理提供了有力的支撐和保障。

2 CM2TS-HBase存儲框架

本文設計并實現了一種基于HBase與Netty的煤礦微震時序波形數據存儲優化框架。該框架針對煤礦微震時序波形數據的特征,解決了熱點數據、存儲分散以及存儲過程中的高并發數據阻塞等問題,從而大幅提升了煤礦微震時序波形數據的存儲效率和性能。

2.1 存儲框架整體架構

為了應對微震監測傳感器分布廣、數據總量大的特點,以及高并發處理、熱點數據和存儲分散的挑戰,本文開發了一種名為CM2TS-HBase(Coal Mine Microquake Time Series data-HBase)的煤礦微震時序波形數據存儲框架,該存儲框架基于HBase與Netty技術實現。圖1所示為該存儲框架的詳細架構圖。

圖1 CM2TS-HBase存儲框架架構圖

存儲引擎整體分為以下四部分。

(1)數據收集層:該層分為離線和實時兩部分。離線數據就是數據中心存儲在硬盤的二進制原始波形文件;實時數據就是在實際應用環境下部署在礦區的眾多傳感器實時產生的時序微震波形數據。下面將離線狀態中的每個工作線程以及實時狀態中的每個傳感器統稱為客戶端。

(2)數據預處理層:對于離線數據需要對原始波形文件進行對齊操作,找到眾多文件中時間重疊的部分進行解析并序列化,最后在多線程并發環境下將數據通過Http/3傳輸至數據中轉層;實時傳感器數據則可以直接進行解析封裝序列化操作然后同樣通過Http/3傳輸至數據中轉層。

(3)數據中轉層:數據中轉層是基于Netty與 Redis的數據轉發中間件,可以對高并發事務進行優化處理,利用負載均衡思想將單一客戶端承受的壓力均衡地分布給所有承擔存儲任務的服務器。

(4)數據存儲層:基于分布式數據庫HBase作為存儲體系的底層存儲媒介。在實驗環境下,數據存儲層的HBase分布式存儲節點被部署在云服務器的Docker虛擬化容器中。負責存儲數據中轉層傳來的序列化數據。

2.2 主鍵優化策略

HBase是一個由眾多節點組成的集群架構。優秀的主鍵設計可以顯著提升HBase的讀寫效率,而且可以將一段時間內存儲的數據放置在連續的物理空間內,這樣也能有效地解決數據分散的問題。

主鍵的設計原則有四點,分別是長度原則、唯一原則、排序原則以及散列原則。本文設計了適用于時序微震波形數據特點并結合主鍵設計四原則的主鍵優化策略。主鍵結構示意圖如圖2所示。

圖2 主鍵結構示意圖

基于主鍵長度原則,將主鍵長度設置為24位,由于目前大多數服務器是64位操作系統,其內存均按照8字節對齊。因此主鍵設置為24位可以提高尋址效率。其中主鍵高9位表示行政區劃代碼,最小可以精確到鄉級行政區;低15位是數據的時間字段,單位可以精確到秒級,基于上述主鍵設計,HBase在存儲時首先會按照高9位進行排序,此時具有相同地區編號的數據就會被存儲在連續的物理空間中;若高9位相同,就會根據低15位的時間字段按照寫入時間順序進行存儲。

2.3 預分區策略

HBase分布式數據庫存儲數據的基本單位被稱為分區(Region),HBase默認建表時設置一個Region,并且這個Region的主鍵是無邊界的,因此在數據寫入時,所有數據都會寫入到這個默認Region,但隨著數據量的不斷增加,HBase會進行Split操作分割成2個Region。在這個過程中就會出現兩個問題:數據不停向一個Region寫入會造成熱點數據問題;Split操作會消耗寶貴的集群I/O資源。

因此本文在建表時就基于上述主鍵特點創建了多個空的Region,并確定了每個Region的起始和終止主鍵,這樣可以使每條數據均勻地命中各個Region,從而避免了熱點數據的產生并降低了Split的發生概率。

預分區的前提是有明確的主鍵結構,基于上述主鍵結構,根據高9位的行政區劃代碼進行分區操作。根據地區的不同進行分類,并按照各個地區的煤礦礦區數量動態分配Region數量,分區分類見表1。本表數據來源于中華人民共和國行政區劃代碼1 983版本,僅以東北、華北以及華東為例。

表1 分區分類表

根據上述預分區策略對HBase數據庫進行預分區操作,可將數據均勻地進行分布式存儲,基本解決了煤礦微震波形時序數據在HBase分布式數據庫存儲時的數據熱點問題。

2.4 數據表設計與數據對象序列化操作

基于煤礦微震波形時序數據特點以及多傳感器網絡的場景,本文設計了一種適用于此類特殊場景的數據表結構,數據表結構示意圖如圖3所示。

HBase分布式數據庫在進行查詢操作時的規則是以主鍵為索引進行的,主鍵可以確定唯一一行數據,但無法確定一個具體的Cell。本文將列族設置為具體的煤礦礦區名稱,以下不同的列分別表示部署在該煤礦中的傳感器代號,這樣在后續的計算任務中便可以進行多維度多條件的查詢。

由圖3可見數據行中存儲的是序列化數據,序列化的定義是為了將數據對象轉換為更易進行網絡傳輸和保持格式的過程。在存儲引擎當中客戶端與Netty Server之間的通信在宏觀的角度看就是兩個進程之間的遠程交互,客戶端會根據時序波形的特征將解析后的原始數據封裝成固定格式的數據對象,使序列化后的數據在空間上被大幅度壓縮,提高雙方在遠程傳輸數據過程的通信效率。

2.5 基于Netty與Redis的異步數據緩存中間件

本節使用了兩個非常流行的組件,分別是Netty框架與Redis內存數據庫。該模塊的架構圖如圖4所示。

圖4 基于Netty與Redis的異步數據緩存中間件架構圖

客戶端(Clients),在實時狀態下,每個微震波形傳感器都可以被認為是一個客戶端;在離線狀態下,線程池中的每個發起存儲請求的線程任務也可以被設定為客戶端。圖中步驟2、3表示客戶端在發起存儲請求前會從Redis緩存中查找最小連接服務器節點。圖中步驟4表示客戶端根據查詢到的結果向當前最小連接服務器發送存儲請求。

Redis緩存,該部分用于實現對中間件服務器集群的負載均衡調度。本文采用負載均衡算法中最為流行的最小連接法,使用Redis數據庫中的有序集合數據結構,基于所有當前正在運行服務器的連接數進行排序,使每個發起存儲請求的客戶端都能獲取到當前壓力最小的Netty Server。

Netty Server,基于Netty框架開發的中間件服務器,并以集群的形式分布式地向HBase發送待存儲數據。

3 數據存儲過程

CM2TS-HBase數據存儲過程如圖5所示。

圖5 數據存儲過程

原始文件解析主機開啟多線程并發解析原始波形文件,并在此過程中調用數據整理器對主鍵進行調整并對波形數據對象進行序列化整理,使其便于網絡傳輸。

攜帶整理完畢的數據發起存儲請求,在請求前需要根據Redis緩存存儲的中間件服務器集群中各個服務器的實時連接狀態,選取最優狀態的服務器進行存儲。同理,每當中間件服務器開啟都會將本節點的信息存入Redis中向存儲請求線程提供服務;同時服務器的關閉與宕機也會進行更新操作。

存儲請求線程得到最優節點信息后嘗試與服務器建立測試通信,如果成功便更新節點信息并攜帶序列化波形數據對象發送存儲請求,中間件服務器接收到請求后根據預分區策略將數據存儲到對應Region中,反之將報錯信息返回給客戶端并記錄日志,最終所有存儲請求傳輸完成后關閉連接,并更新對應節點信息。

CM2TS-HBase存儲過程算法如算法1所示。該算法時間復雜度為O(n),空間復雜度為O(n)。

算法1:CM2TS-HBase存儲過程算法

Input:待存儲數據 data

OutPut:存儲完成狀態 R

Begin

1:nserver←zrangenserset0 0

2:booleanconnected←doConnected(nserver);

3:ifconnected=false

4:zremnsersetnserver;

5:else

6:zincrbynserset1nserver;

7:whiledata←hasNext()

8:R←doWrite(data);

9:if(R=False)

10:emitR;

11:endwhile

12:else

13:continue;

End.

算法第一行通過Redis命令zrange 0 0獲取到當前Netty Server服務器集合中連接數最小的服務器nserver,算法第2行到第6行表示對選中的Netty Server進行連接測試,如果連接失敗,通過Redis命令zrem nserset nserver刪除該服務器,如果連接成功,則通過Redis命令zincrby nserset 1 nserver將nserver的連接數加一,算法中第7行到第13行表示進入存儲循環過程,通過doWrite方法向HBase數據庫寫入數據,并實時返回存儲狀態R,如果存儲出現問題,R將攜帶報錯信息返回控制臺,如果存儲過程未出現報錯問題,則存儲過程將繼續循環,存儲下一條數據,直到此輪存儲請求結束。

4 實驗分析

4.1 實驗環境

實驗在HBase偽分布式環境下進行。硬件環境為一臺2核4G云服務器,通過Docker虛擬容器化后的4臺虛擬主機組成的偽分布式集群。原始數據解析主機為一臺Intel酷睿i5 8250U 8核 1.6 GHz 16 GB RAM主機對歷史微震數據文件進行多線程解析存儲。

軟件平臺為CentOS 7.6-64位、JDK-1.8、HBase-2.3.6、Zookeeper-3.4.10、Hadoop-3.1.3。服務器節點信息見表2。

表2 服務器節點信息表

本文實驗設計了3種存儲方案,通過對比3種方案在存儲煤礦微震波形時序數據的性能表現得出最終結論。3種方案分別為:通過HBase原生客戶端Put方法存儲HBase(HBaseAPI);基于HBase的金融時序數據存儲系統思想存儲煤礦微震波形時序數據(FTBase);基于HBase與Netty的煤礦微震時序大數據優化策略存儲煤礦微震時序數據(CM2TS-HBase)。

4.2 數據集

實驗所用數據為2019年遼寧某煤礦真實部署傳感器監測到的歷史微震波形文件,每條數據包含采集時間、波形空間坐標等內容。傳感器數據采集頻率為5 000條/s,實驗設置3個組別,分別是6文件組、12文件組以及24文件組進行并發存儲,每個文件大小約250 MB。

4.3 評估指標

針對煤礦微震波形時序數據的存儲性能優化實驗,采用2項指標作為最終評估標準。分別是:根據固定存儲文件數量統計存儲耗時情況以及單位時間節點存儲數據量的對比。

(1) 固定文件數量統計存儲耗時情況,在離線狀態下,可通過離線波形文件以多線程的方式模擬出煤礦微震傳感器的實時存儲數據場景。同時可以統計出高并發狀態下各個實驗方案的存儲性能。因此在單位文件數量的前提下,存儲耗時越小即表示存儲性能更佳,即對高并發場景的存儲性能進行了有效地提升。

(2) 單位時間節點存儲數據量對比,實驗根據單位文件數量下存儲持續時間設置實驗組,分別在各實驗組的時間節點統計存儲的數據量。存儲數據量越大就說明性能更佳。

4.4 實驗結果

通過對比存儲總耗時區分二者的性能差距,存儲總耗時實驗對比結果見表3。當實驗設置文件數量為6個和12個時,3種方案的實驗結果相差不大。當實驗將文件數量提升至24個時,HBaseAPI的處理時間明顯變長,延長至167 s;同時,CM2TS-HBase存儲耗時為97 s,FTBase存儲耗時為78 s。CT2MS-HBase存儲耗時明顯低于HBaseAPI與FTBase,存儲耗時對比如圖6所示。

表3 實驗耗時結果表

圖6 存儲耗時對比圖

單位時間節點存儲數據量實驗結果如圖7所示。在實驗過程中,HBaseAPI的每秒鐘存儲數據量由持續時間20 s時的31.6×104條/s提升至持續時間120 s時的86.2×104條/s,性能有大幅度的提升。同時,通過與FTBase的對比中也可以看出負載均衡算法的引入對中間件集群的資源分配進行了合理地調整,進而提升了整體存儲系統的性能。因此,在高并發場景下,CM2TS-HBase的表現更好。

圖7 單位時間存儲數據量對比圖

5 結論

本文探討了如何基于HBase分布式數據庫、Netty網絡通信框架以及Redis內存數據庫等技術來存儲煤礦微震時序大數據。在實踐中發現,由于HBase分布式數據庫的自身缺陷和煤礦微震時序大數據的特點,需要采取特殊的策略來進行預分區、主鍵優化和數據表結構的設計。通過本文提出的策略,可以有效地提高煤礦微震時序大數據的存儲效率和查詢性能。

本文所述的設計思想從實際問題出發,針對煤礦微震時序大數據的存儲問題提供了有效的解決方案。這對于工業界使用傳感器產生的時序數據進行生產或安全維護具有重要的參考價值和實用意義。此外,本文所介紹的技術和策略也可以為其他領域的時序數據存儲問題提供一些借鑒和參考。