基于HBase與Netty的煤礦微震時(shí)序大數(shù)據(jù)存儲(chǔ)優(yōu)化

丁琳琳, 王智涵, 顧英豪, 王凱璐, 包鑫陽(yáng)

(1.遼寧大學(xué) 信息學(xué)院, 遼寧 沈陽(yáng) 110036; 2.遼寧煤電產(chǎn)業(yè)控股有限公司紅陽(yáng)三礦, 遼寧 遼陽(yáng) 110101)

1 前言

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

當(dāng)前煤礦微震時(shí)序大數(shù)據(jù)的存儲(chǔ)方案,通常可采用傳統(tǒng)文件系統(tǒng)存儲(chǔ)、關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)以及分布式存儲(chǔ)三種方案。對(duì)于傳統(tǒng)的文件系統(tǒng)存儲(chǔ)方式,盡管操作簡(jiǎn)便,但需重復(fù)進(jìn)行對(duì)齊操作和讀取傳感器波形文件操作以滿足后續(xù)計(jì)算部分的數(shù)據(jù)需求,導(dǎo)致重復(fù)操作占據(jù)程序執(zhí)行的大部分時(shí)間,并且無(wú)法對(duì)數(shù)據(jù)進(jìn)行有效管理以及對(duì)數(shù)據(jù)的快速檢索。對(duì)于關(guān)系型數(shù)據(jù)庫(kù)存儲(chǔ)方式,在存儲(chǔ)煤礦微震波形時(shí)序數(shù)據(jù)時(shí)存在高并發(fā)事務(wù)場(chǎng)景下性能較差、擴(kuò)展性差等缺點(diǎn)。對(duì)于分布式存儲(chǔ)在存儲(chǔ)時(shí)序大數(shù)據(jù)方面,盡管相對(duì)于關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)有了一定的優(yōu)化,但也存在一些缺陷,在煤礦微震波形時(shí)序大數(shù)據(jù)的存儲(chǔ)場(chǎng)景下,需要考慮數(shù)據(jù)的特征關(guān)聯(lián)問(wèn)題、存儲(chǔ)熱點(diǎn)數(shù)據(jù)問(wèn)題、存儲(chǔ)分散以及海量數(shù)據(jù)存儲(chǔ)數(shù)據(jù)阻塞問(wèn)題,現(xiàn)有存儲(chǔ)策略均無(wú)法較好解決。

因此,針對(duì)上述諸多問(wèn)題,本文采用基于Hadoop分布式平臺(tái)[3]的NoSQL非關(guān)系型數(shù)據(jù)庫(kù)HBase[4]作為底層存儲(chǔ)介質(zhì),因?yàn)槠湓诳蓴U(kuò)展性、并發(fā)度、分布式以及面向列存儲(chǔ)等方面均較為突出。并結(jié)合煤礦微震波形時(shí)序數(shù)據(jù)的高并發(fā)、時(shí)間序列化以及海量數(shù)據(jù)的特點(diǎn),采用適用于煤礦微震波形時(shí)序數(shù)據(jù)的表結(jié)構(gòu)設(shè)計(jì)策略、預(yù)分區(qū)策略以及行鍵優(yōu)化策略對(duì)存儲(chǔ)性能進(jìn)行優(yōu)化。同時(shí),采用Netty[5]網(wǎng)絡(luò)通信框架編寫(xiě)的中間件集群作為數(shù)據(jù)中轉(zhuǎn)層,對(duì)數(shù)據(jù)接收層流轉(zhuǎn)而來(lái)的海量數(shù)據(jù)進(jìn)行分流處理,有效避免數(shù)據(jù)阻塞問(wèn)題。使用Redis內(nèi)存數(shù)據(jù)庫(kù)[6]的有序集合數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)負(fù)載均衡算法的最小連接法[7],使Netty中間件集群中的每個(gè)節(jié)點(diǎn)都能夠被合理地分配。最終,采用真實(shí)的傳感器離線數(shù)據(jù)對(duì)實(shí)驗(yàn)進(jìn)行了驗(yàn)證。

2 相關(guān)工作

基于HBase數(shù)據(jù)庫(kù)實(shí)現(xiàn)的開(kāi)源時(shí)序數(shù)據(jù)庫(kù)OpenTSDB[8]具有優(yōu)秀的擴(kuò)展性和伸縮性,可以輕松地水平擴(kuò)展集群規(guī)模來(lái)處理大量數(shù)據(jù)。此外,文獻(xiàn)[9]以時(shí)間序列數(shù)據(jù)的特點(diǎn)為中心,實(shí)現(xiàn)了分布式數(shù)據(jù)庫(kù)存儲(chǔ)海量時(shí)間序列數(shù)據(jù)的方法和應(yīng)用。InfluxDB是一個(gè)開(kāi)源時(shí)序數(shù)據(jù)庫(kù),用于處理時(shí)序數(shù)據(jù)的高性能讀寫(xiě)操作,InfluxDB具有高性能、易擴(kuò)展、數(shù)據(jù)可視化等優(yōu)點(diǎn)[10]?；贑assandra[11]數(shù)據(jù)庫(kù)構(gòu)建的開(kāi)源時(shí)序數(shù)據(jù)庫(kù)KairosDB支持高效存儲(chǔ)和查詢時(shí)間序列數(shù)據(jù),Kairos還具有支持多種數(shù)據(jù)類型、提供豐富的查詢接口、易于使用和部署等優(yōu)點(diǎn)[12]。結(jié)合Logstash和Elasticsearch同樣可以實(shí)現(xiàn)對(duì)時(shí)序數(shù)據(jù)的高效存儲(chǔ)和查詢,并具有良好的擴(kuò)展性和靈活性[13]。

在HBase分布式數(shù)據(jù)庫(kù)底層存儲(chǔ)原理方面,文獻(xiàn)[14]利用JavaNIO技術(shù)設(shè)計(jì)了一種HBaseRPC客戶端的非阻塞通信模型,文獻(xiàn)[15]則提出了一種存儲(chǔ)大規(guī)?？臻g向量數(shù)據(jù)的模型,適用于處理大規(guī)模數(shù)據(jù)的應(yīng)用。另外,文獻(xiàn)[16]基于HBase與Redis高性能緩存,為圖片數(shù)據(jù)的查詢和存檔性能做出了客觀的貢獻(xiàn)。在存儲(chǔ)優(yōu)化架構(gòu)方面,文獻(xiàn)[17]提出了四層結(jié)構(gòu),并使用Netty網(wǎng)絡(luò)通信框架作為數(shù)據(jù)緩存中間件,該架構(gòu)在金融時(shí)序數(shù)據(jù)的高并發(fā)存儲(chǔ)場(chǎng)景中得到了可觀的優(yōu)化效果。最后,文獻(xiàn)[18]設(shè)計(jì)并實(shí)現(xiàn)了三層存儲(chǔ)架構(gòu),并將數(shù)據(jù)緩存中間件集群化處理,有效避免了高并發(fā)場(chǎng)景下海量傳感器數(shù)據(jù)阻塞的問(wèn)題。

以上述研究工作為基礎(chǔ),本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于HBase與Netty的煤礦微震時(shí)序數(shù)據(jù)存儲(chǔ)優(yōu)化方案。該方案綜合了多個(gè)方面的優(yōu)化措施,成功解決了煤礦微震時(shí)序數(shù)據(jù)存儲(chǔ)分散以及存儲(chǔ)熱點(diǎn)等問(wèn)題。同時(shí),該方案在高并發(fā)事務(wù)處理方面也有可觀的優(yōu)化效果,大幅提升了存儲(chǔ)效率,為煤礦微震時(shí)序數(shù)據(jù)的存儲(chǔ)和處理提供了有力的支撐和保障。

2 CM2TS-HBase存儲(chǔ)框架

本文設(shè)計(jì)并實(shí)現(xiàn)了一種基于HBase與Netty的煤礦微震時(shí)序波形數(shù)據(jù)存儲(chǔ)優(yōu)化框架。該框架針對(duì)煤礦微震時(shí)序波形數(shù)據(jù)的特征,解決了熱點(diǎn)數(shù)據(jù)、存儲(chǔ)分散以及存儲(chǔ)過(guò)程中的高并發(fā)數(shù)據(jù)阻塞等問(wèn)題,從而大幅提升了煤礦微震時(shí)序波形數(shù)據(jù)的存儲(chǔ)效率和性能。

2.1 存儲(chǔ)框架整體架構(gòu)

為了應(yīng)對(duì)微震監(jiān)測(cè)傳感器分布廣、數(shù)據(jù)總量大的特點(diǎn),以及高并發(fā)處理、熱點(diǎn)數(shù)據(jù)和存儲(chǔ)分散的挑戰(zhàn),本文開(kāi)發(fā)了一種名為CM2TS-HBase(Coal Mine Microquake Time Series data-HBase)的煤礦微震時(shí)序波形數(shù)據(jù)存儲(chǔ)框架,該存儲(chǔ)框架基于HBase與Netty技術(shù)實(shí)現(xiàn)。圖1所示為該存儲(chǔ)框架的詳細(xì)架構(gòu)圖。

圖1 CM2TS-HBase存儲(chǔ)框架架構(gòu)圖

存儲(chǔ)引擎整體分為以下四部分。

(1)數(shù)據(jù)收集層:該層分為離線和實(shí)時(shí)兩部分。離線數(shù)據(jù)就是數(shù)據(jù)中心存儲(chǔ)在硬盤的二進(jìn)制原始波形文件;實(shí)時(shí)數(shù)據(jù)就是在實(shí)際應(yīng)用環(huán)境下部署在礦區(qū)的眾多傳感器實(shí)時(shí)產(chǎn)生的時(shí)序微震波形數(shù)據(jù)。下面將離線狀態(tài)中的每個(gè)工作線程以及實(shí)時(shí)狀態(tài)中的每個(gè)傳感器統(tǒng)稱為客戶端。

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

(3)數(shù)據(jù)中轉(zhuǎn)層:數(shù)據(jù)中轉(zhuǎn)層是基于Netty與 Redis的數(shù)據(jù)轉(zhuǎn)發(fā)中間件,可以對(duì)高并發(fā)事務(wù)進(jìn)行優(yōu)化處理,利用負(fù)載均衡思想將單一客戶端承受的壓力均衡地分布給所有承擔(dān)存儲(chǔ)任務(wù)的服務(wù)器。

(4)數(shù)據(jù)存儲(chǔ)層:基于分布式數(shù)據(jù)庫(kù)HBase作為存儲(chǔ)體系的底層存儲(chǔ)媒介。在實(shí)驗(yàn)環(huán)境下,數(shù)據(jù)存儲(chǔ)層的HBase分布式存儲(chǔ)節(jié)點(diǎn)被部署在云服務(wù)器的Docker虛擬化容器中。負(fù)責(zé)存儲(chǔ)數(shù)據(jù)中轉(zhuǎn)層傳來(lái)的序列化數(shù)據(jù)。

2.2 主鍵優(yōu)化策略

HBase是一個(gè)由眾多節(jié)點(diǎn)組成的集群架構(gòu)。優(yōu)秀的主鍵設(shè)計(jì)可以顯著提升HBase的讀寫(xiě)效率,而且可以將一段時(shí)間內(nèi)存儲(chǔ)的數(shù)據(jù)放置在連續(xù)的物理空間內(nèi),這樣也能有效地解決數(shù)據(jù)分散的問(wèn)題。

主鍵的設(shè)計(jì)原則有四點(diǎn),分別是長(zhǎng)度原則、唯一原則、排序原則以及散列原則。本文設(shè)計(jì)了適用于時(shí)序微震波形數(shù)據(jù)特點(diǎn)并結(jié)合主鍵設(shè)計(jì)四原則的主鍵優(yōu)化策略。主鍵結(jié)構(gòu)示意圖如圖2所示。

圖2 主鍵結(jié)構(gòu)示意圖

基于主鍵長(zhǎng)度原則,將主鍵長(zhǎng)度設(shè)置為24位,由于目前大多數(shù)服務(wù)器是64位操作系統(tǒng),其內(nèi)存均按照8字節(jié)對(duì)齊。因此主鍵設(shè)置為24位可以提高尋址效率。其中主鍵高9位表示行政區(qū)劃代碼,最小可以精確到鄉(xiāng)級(jí)行政區(qū);低15位是數(shù)據(jù)的時(shí)間字段,單位可以精確到秒級(jí),基于上述主鍵設(shè)計(jì),HBase在存儲(chǔ)時(shí)首先會(huì)按照高9位進(jìn)行排序,此時(shí)具有相同地區(qū)編號(hào)的數(shù)據(jù)就會(huì)被存儲(chǔ)在連續(xù)的物理空間中;若高9位相同,就會(huì)根據(jù)低15位的時(shí)間字段按照寫(xiě)入時(shí)間順序進(jìn)行存儲(chǔ)。

2.3 預(yù)分區(qū)策略

HBase分布式數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)的基本單位被稱為分區(qū)(Region),HBase默認(rèn)建表時(shí)設(shè)置一個(gè)Region,并且這個(gè)Region的主鍵是無(wú)邊界的,因此在數(shù)據(jù)寫(xiě)入時(shí),所有數(shù)據(jù)都會(huì)寫(xiě)入到這個(gè)默認(rèn)Region,但隨著數(shù)據(jù)量的不斷增加,HBase會(huì)進(jìn)行Split操作分割成2個(gè)Region。在這個(gè)過(guò)程中就會(huì)出現(xiàn)兩個(gè)問(wèn)題:數(shù)據(jù)不停向一個(gè)Region寫(xiě)入會(huì)造成熱點(diǎn)數(shù)據(jù)問(wèn)題;Split操作會(huì)消耗寶貴的集群I/O資源。

因此本文在建表時(shí)就基于上述主鍵特點(diǎn)創(chuàng)建了多個(gè)空的Region,并確定了每個(gè)Region的起始和終止主鍵,這樣可以使每條數(shù)據(jù)均勻地命中各個(gè)Region,從而避免了熱點(diǎn)數(shù)據(jù)的產(chǎn)生并降低了Split的發(fā)生概率。

預(yù)分區(qū)的前提是有明確的主鍵結(jié)構(gòu),基于上述主鍵結(jié)構(gòu),根據(jù)高9位的行政區(qū)劃代碼進(jìn)行分區(qū)操作。根據(jù)地區(qū)的不同進(jìn)行分類,并按照各個(gè)地區(qū)的煤礦礦區(qū)數(shù)量動(dòng)態(tài)分配Region數(shù)量,分區(qū)分類見(jiàn)表1。本表數(shù)據(jù)來(lái)源于中華人民共和國(guó)行政區(qū)劃代碼1 983版本,僅以東北、華北以及華東為例。

表1 分區(qū)分類表

根據(jù)上述預(yù)分區(qū)策略對(duì)HBase數(shù)據(jù)庫(kù)進(jìn)行預(yù)分區(qū)操作,可將數(shù)據(jù)均勻地進(jìn)行分布式存儲(chǔ),基本解決了煤礦微震波形時(shí)序數(shù)據(jù)在HBase分布式數(shù)據(jù)庫(kù)存儲(chǔ)時(shí)的數(shù)據(jù)熱點(diǎn)問(wèn)題。

2.4 數(shù)據(jù)表設(shè)計(jì)與數(shù)據(jù)對(duì)象序列化操作

基于煤礦微震波形時(shí)序數(shù)據(jù)特點(diǎn)以及多傳感器網(wǎng)絡(luò)的場(chǎng)景,本文設(shè)計(jì)了一種適用于此類特殊場(chǎng)景的數(shù)據(jù)表結(jié)構(gòu),數(shù)據(jù)表結(jié)構(gòu)示意圖如圖3所示。

HBase分布式數(shù)據(jù)庫(kù)在進(jìn)行查詢操作時(shí)的規(guī)則是以主鍵為索引進(jìn)行的,主鍵可以確定唯一一行數(shù)據(jù),但無(wú)法確定一個(gè)具體的Cell。本文將列族設(shè)置為具體的煤礦礦區(qū)名稱,以下不同的列分別表示部署在該煤礦中的傳感器代號(hào),這樣在后續(xù)的計(jì)算任務(wù)中便可以進(jìn)行多維度多條件的查詢。

由圖3可見(jiàn)數(shù)據(jù)行中存儲(chǔ)的是序列化數(shù)據(jù),序列化的定義是為了將數(shù)據(jù)對(duì)象轉(zhuǎn)換為更易進(jìn)行網(wǎng)絡(luò)傳輸和保持格式的過(guò)程。在存儲(chǔ)引擎當(dāng)中客戶端與Netty Server之間的通信在宏觀的角度看就是兩個(gè)進(jìn)程之間的遠(yuǎn)程交互,客戶端會(huì)根據(jù)時(shí)序波形的特征將解析后的原始數(shù)據(jù)封裝成固定格式的數(shù)據(jù)對(duì)象,使序列化后的數(shù)據(jù)在空間上被大幅度壓縮,提高雙方在遠(yuǎn)程傳輸數(shù)據(jù)過(guò)程的通信效率。

2.5 基于Netty與Redis的異步數(shù)據(jù)緩存中間件

本節(jié)使用了兩個(gè)非常流行的組件,分別是Netty框架與Redis內(nèi)存數(shù)據(jù)庫(kù)。該模塊的架構(gòu)圖如圖4所示。

圖4 基于Netty與Redis的異步數(shù)據(jù)緩存中間件架構(gòu)圖

客戶端(Clients),在實(shí)時(shí)狀態(tài)下,每個(gè)微震波形傳感器都可以被認(rèn)為是一個(gè)客戶端;在離線狀態(tài)下,線程池中的每個(gè)發(fā)起存儲(chǔ)請(qǐng)求的線程任務(wù)也可以被設(shè)定為客戶端。圖中步驟2、3表示客戶端在發(fā)起存儲(chǔ)請(qǐng)求前會(huì)從Redis緩存中查找最小連接服務(wù)器節(jié)點(diǎn)。圖中步驟4表示客戶端根據(jù)查詢到的結(jié)果向當(dāng)前最小連接服務(wù)器發(fā)送存儲(chǔ)請(qǐng)求。

Redis緩存,該部分用于實(shí)現(xiàn)對(duì)中間件服務(wù)器集群的負(fù)載均衡調(diào)度。本文采用負(fù)載均衡算法中最為流行的最小連接法,使用Redis數(shù)據(jù)庫(kù)中的有序集合數(shù)據(jù)結(jié)構(gòu),基于所有當(dāng)前正在運(yùn)行服務(wù)器的連接數(shù)進(jìn)行排序,使每個(gè)發(fā)起存儲(chǔ)請(qǐng)求的客戶端都能獲取到當(dāng)前壓力最小的Netty Server。

Netty Server,基于Netty框架開(kāi)發(fā)的中間件服務(wù)器,并以集群的形式分布式地向HBase發(fā)送待存儲(chǔ)數(shù)據(jù)。

3 數(shù)據(jù)存儲(chǔ)過(guò)程

CM2TS-HBase數(shù)據(jù)存儲(chǔ)過(guò)程如圖5所示。

圖5 數(shù)據(jù)存儲(chǔ)過(guò)程

原始文件解析主機(jī)開(kāi)啟多線程并發(fā)解析原始波形文件,并在此過(guò)程中調(diào)用數(shù)據(jù)整理器對(duì)主鍵進(jìn)行調(diào)整并對(duì)波形數(shù)據(jù)對(duì)象進(jìn)行序列化整理,使其便于網(wǎng)絡(luò)傳輸。

攜帶整理完畢的數(shù)據(jù)發(fā)起存儲(chǔ)請(qǐng)求,在請(qǐng)求前需要根據(jù)Redis緩存存儲(chǔ)的中間件服務(wù)器集群中各個(gè)服務(wù)器的實(shí)時(shí)連接狀態(tài),選取最優(yōu)狀態(tài)的服務(wù)器進(jìn)行存儲(chǔ)。同理,每當(dāng)中間件服務(wù)器開(kāi)啟都會(huì)將本節(jié)點(diǎn)的信息存入Redis中向存儲(chǔ)請(qǐng)求線程提供服務(wù);同時(shí)服務(wù)器的關(guān)閉與宕機(jī)也會(huì)進(jìn)行更新操作。

存儲(chǔ)請(qǐng)求線程得到最優(yōu)節(jié)點(diǎn)信息后嘗試與服務(wù)器建立測(cè)試通信,如果成功便更新節(jié)點(diǎn)信息并攜帶序列化波形數(shù)據(jù)對(duì)象發(fā)送存儲(chǔ)請(qǐng)求,中間件服務(wù)器接收到請(qǐng)求后根據(jù)預(yù)分區(qū)策略將數(shù)據(jù)存儲(chǔ)到對(duì)應(yīng)Region中,反之將報(bào)錯(cuò)信息返回給客戶端并記錄日志,最終所有存儲(chǔ)請(qǐng)求傳輸完成后關(guān)閉連接,并更新對(duì)應(yīng)節(jié)點(diǎn)信息。

CM2TS-HBase存儲(chǔ)過(guò)程算法如算法1所示。該算法時(shí)間復(fù)雜度為O(n),空間復(fù)雜度為O(n)。

算法1:CM2TS-HBase存儲(chǔ)過(guò)程算法

Input:待存儲(chǔ)數(shù)據(jù) data

OutPut:存儲(chǔ)完成狀態(tài) 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.

算法第一行通過(guò)Redis命令zrange 0 0獲取到當(dāng)前Netty Server服務(wù)器集合中連接數(shù)最小的服務(wù)器nserver,算法第2行到第6行表示對(duì)選中的Netty Server進(jìn)行連接測(cè)試,如果連接失敗,通過(guò)Redis命令zrem nserset nserver刪除該服務(wù)器,如果連接成功,則通過(guò)Redis命令zincrby nserset 1 nserver將nserver的連接數(shù)加一,算法中第7行到第13行表示進(jìn)入存儲(chǔ)循環(huán)過(guò)程,通過(guò)doWrite方法向HBase數(shù)據(jù)庫(kù)寫(xiě)入數(shù)據(jù),并實(shí)時(shí)返回存儲(chǔ)狀態(tài)R,如果存儲(chǔ)出現(xiàn)問(wèn)題,R將攜帶報(bào)錯(cuò)信息返回控制臺(tái),如果存儲(chǔ)過(guò)程未出現(xiàn)報(bào)錯(cuò)問(wèn)題,則存儲(chǔ)過(guò)程將繼續(xù)循環(huán),存儲(chǔ)下一條數(shù)據(jù),直到此輪存儲(chǔ)請(qǐng)求結(jié)束。

4 實(shí)驗(yàn)分析

4.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)在HBase偽分布式環(huán)境下進(jìn)行。硬件環(huán)境為一臺(tái)2核4G云服務(wù)器,通過(guò)Docker虛擬容器化后的4臺(tái)虛擬主機(jī)組成的偽分布式集群。原始數(shù)據(jù)解析主機(jī)為一臺(tái)Intel酷睿i5 8250U 8核 1.6 GHz 16 GB RAM主機(jī)對(duì)歷史微震數(shù)據(jù)文件進(jìn)行多線程解析存儲(chǔ)。

軟件平臺(tái)為CentOS 7.6-64位、JDK-1.8、HBase-2.3.6、Zookeeper-3.4.10、Hadoop-3.1.3。服務(wù)器節(jié)點(diǎn)信息見(jiàn)表2。

表2 服務(wù)器節(jié)點(diǎn)信息表

本文實(shí)驗(yàn)設(shè)計(jì)了3種存儲(chǔ)方案,通過(guò)對(duì)比3種方案在存儲(chǔ)煤礦微震波形時(shí)序數(shù)據(jù)的性能表現(xiàn)得出最終結(jié)論。3種方案分別為:通過(guò)HBase原生客戶端Put方法存儲(chǔ)HBase(HBaseAPI);基于HBase的金融時(shí)序數(shù)據(jù)存儲(chǔ)系統(tǒng)思想存儲(chǔ)煤礦微震波形時(shí)序數(shù)據(jù)(FTBase);基于HBase與Netty的煤礦微震時(shí)序大數(shù)據(jù)優(yōu)化策略存儲(chǔ)煤礦微震時(shí)序數(shù)據(jù)(CM2TS-HBase)。

4.2 數(shù)據(jù)集

實(shí)驗(yàn)所用數(shù)據(jù)為2019年遼寧某煤礦真實(shí)部署傳感器監(jiān)測(cè)到的歷史微震波形文件,每條數(shù)據(jù)包含采集時(shí)間、波形空間坐標(biāo)等內(nèi)容。傳感器數(shù)據(jù)采集頻率為5 000條/s,實(shí)驗(yàn)設(shè)置3個(gè)組別,分別是6文件組、12文件組以及24文件組進(jìn)行并發(fā)存儲(chǔ),每個(gè)文件大小約250 MB。

4.3 評(píng)估指標(biāo)

針對(duì)煤礦微震波形時(shí)序數(shù)據(jù)的存儲(chǔ)性能優(yōu)化實(shí)驗(yàn),采用2項(xiàng)指標(biāo)作為最終評(píng)估標(biāo)準(zhǔn)。分別是:根據(jù)固定存儲(chǔ)文件數(shù)量統(tǒng)計(jì)存儲(chǔ)耗時(shí)情況以及單位時(shí)間節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)量的對(duì)比。

(1) 固定文件數(shù)量統(tǒng)計(jì)存儲(chǔ)耗時(shí)情況,在離線狀態(tài)下,可通過(guò)離線波形文件以多線程的方式模擬出煤礦微震傳感器的實(shí)時(shí)存儲(chǔ)數(shù)據(jù)場(chǎng)景。同時(shí)可以統(tǒng)計(jì)出高并發(fā)狀態(tài)下各個(gè)實(shí)驗(yàn)方案的存儲(chǔ)性能。因此在單位文件數(shù)量的前提下,存儲(chǔ)耗時(shí)越小即表示存儲(chǔ)性能更佳,即對(duì)高并發(fā)場(chǎng)景的存儲(chǔ)性能進(jìn)行了有效地提升。

(2) 單位時(shí)間節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)量對(duì)比,實(shí)驗(yàn)根據(jù)單位文件數(shù)量下存儲(chǔ)持續(xù)時(shí)間設(shè)置實(shí)驗(yàn)組,分別在各實(shí)驗(yàn)組的時(shí)間節(jié)點(diǎn)統(tǒng)計(jì)存儲(chǔ)的數(shù)據(jù)量。存儲(chǔ)數(shù)據(jù)量越大就說(shuō)明性能更佳。

4.4 實(shí)驗(yàn)結(jié)果

通過(guò)對(duì)比存儲(chǔ)總耗時(shí)區(qū)分二者的性能差距,存儲(chǔ)總耗時(shí)實(shí)驗(yàn)對(duì)比結(jié)果見(jiàn)表3。當(dāng)實(shí)驗(yàn)設(shè)置文件數(shù)量為6個(gè)和12個(gè)時(shí),3種方案的實(shí)驗(yàn)結(jié)果相差不大。當(dāng)實(shí)驗(yàn)將文件數(shù)量提升至24個(gè)時(shí),HBaseAPI的處理時(shí)間明顯變長(zhǎng),延長(zhǎng)至167 s;同時(shí),CM2TS-HBase存儲(chǔ)耗時(shí)為97 s,FTBase存儲(chǔ)耗時(shí)為78 s。CT2MS-HBase存儲(chǔ)耗時(shí)明顯低于HBaseAPI與FTBase,存儲(chǔ)耗時(shí)對(duì)比如圖6所示。

表3 實(shí)驗(yàn)耗時(shí)結(jié)果表

圖6 存儲(chǔ)耗時(shí)對(duì)比圖

單位時(shí)間節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)量實(shí)驗(yàn)結(jié)果如圖7所示。在實(shí)驗(yàn)過(guò)程中,HBaseAPI的每秒鐘存儲(chǔ)數(shù)據(jù)量由持續(xù)時(shí)間20 s時(shí)的31.6×104條/s提升至持續(xù)時(shí)間120 s時(shí)的86.2×104條/s,性能有大幅度的提升。同時(shí),通過(guò)與FTBase的對(duì)比中也可以看出負(fù)載均衡算法的引入對(duì)中間件集群的資源分配進(jìn)行了合理地調(diào)整,進(jìn)而提升了整體存儲(chǔ)系統(tǒng)的性能。因此,在高并發(fā)場(chǎng)景下,CM2TS-HBase的表現(xiàn)更好。

圖7 單位時(shí)間存儲(chǔ)數(shù)據(jù)量對(duì)比圖

5 結(jié)論

本文探討了如何基于HBase分布式數(shù)據(jù)庫(kù)、Netty網(wǎng)絡(luò)通信框架以及Redis內(nèi)存數(shù)據(jù)庫(kù)等技術(shù)來(lái)存儲(chǔ)煤礦微震時(shí)序大數(shù)據(jù)。在實(shí)踐中發(fā)現(xiàn),由于HBase分布式數(shù)據(jù)庫(kù)的自身缺陷和煤礦微震時(shí)序大數(shù)據(jù)的特點(diǎn),需要采取特殊的策略來(lái)進(jìn)行預(yù)分區(qū)、主鍵優(yōu)化和數(shù)據(jù)表結(jié)構(gòu)的設(shè)計(jì)。通過(guò)本文提出的策略,可以有效地提高煤礦微震時(shí)序大數(shù)據(jù)的存儲(chǔ)效率和查詢性能。

本文所述的設(shè)計(jì)思想從實(shí)際問(wèn)題出發(fā),針對(duì)煤礦微震時(shí)序大數(shù)據(jù)的存儲(chǔ)問(wèn)題提供了有效的解決方案。這對(duì)于工業(yè)界使用傳感器產(chǎn)生的時(shí)序數(shù)據(jù)進(jìn)行生產(chǎn)或安全維護(hù)具有重要的參考價(jià)值和實(shí)用意義。此外,本文所介紹的技術(shù)和策略也可以為其他領(lǐng)域的時(shí)序數(shù)據(jù)存儲(chǔ)問(wèn)題提供一些借鑒和參考。