單維鋒 滕云田 劉海軍 楊冠澤

1)中國地震局地球物理研究所,北京 100081

2)防災(zāi)科技學(xué)院,河北三河 065201

0 引言

近年來,隨著監(jiān)測儀器數(shù)量的增多和采樣率的提高,地震觀測數(shù)據(jù)量激增?，F(xiàn)有基于關(guān)系數(shù)據(jù)庫的存儲方案存在讀寫速度慢、用戶并發(fā)度低、可擴展性差等問題,難以滿足科研人員日益增長的快速數(shù)據(jù)處理的需求(劉堅等,2015)。大數(shù)據(jù)技術(shù)為處理海量地震觀測數(shù)據(jù)提供了一種全新的數(shù)據(jù)存儲與計算模式。高效、合理的地震觀測數(shù)據(jù)存儲是后續(xù)開展機器學(xué)習、數(shù)據(jù)挖掘和地震分析預(yù)測等應(yīng)用的前提和基礎(chǔ)。本文以地震前兆觀測時間序列數(shù)據(jù)為例,探討了地震大數(shù)據(jù)存儲方案(郭凱等,2017；李永紅等,2015,)。

劉堅等(2015)分別針對地震結(jié)構(gòu)化數(shù)據(jù)與非結(jié)構(gòu)化數(shù)據(jù)提出了一種基于HBase的地震大數(shù)據(jù)存儲方案,并與基于MySQL的存儲方案在數(shù)據(jù)讀寫性能方面進行了比較研究。王丹寧等(2016)針對測震波形數(shù)據(jù),分析了實時數(shù)據(jù)、歷史數(shù)據(jù)的不同業(yè)務(wù)需求,初步提出了一種基于HBase的分布式存儲方案。雖然前人在地震大數(shù)據(jù)存儲方面開展了一些研究,但大多是基于HBase給出的較為籠統(tǒng)的設(shè)計方案,對地震前兆觀測數(shù)據(jù)為時間序列數(shù)據(jù)的特點和常用的業(yè)務(wù)場景考慮不夠全面,且僅僅測試了單用戶模式下系統(tǒng)的讀寫性能。由于大數(shù)據(jù)環(huán)境下,數(shù)據(jù)趨于集中,并發(fā)需求大,因此對不同存儲方案的并發(fā)讀寫性能測試尤為重要。

本文以地震前兆觀測數(shù)據(jù)為例,在深入分析地震數(shù)據(jù)處理業(yè)務(wù)需求的基礎(chǔ)上,結(jié)合地震時間序列數(shù)據(jù)的特點和業(yè)務(wù)需求,首次將OpenTSDB通用時間序列數(shù)據(jù)庫應(yīng)用于地震前兆觀測數(shù)據(jù),然后提出了基于HBase的優(yōu)化設(shè)計方案,并重點測試和分析了基于MySQL、OpenTSDB和HBase的地震前兆觀測數(shù)據(jù)存儲方案的讀寫性能和并發(fā)性能。

1 地震前兆觀測數(shù)據(jù)的數(shù)據(jù)特點

地震前兆觀測數(shù)據(jù)主要包括流體、形變、地磁、地電等學(xué)科數(shù)據(jù),是典型的時間序列數(shù)據(jù),現(xiàn)存儲在關(guān)系數(shù)據(jù)庫中。目前,正常運行的地震前兆觀測儀器近3000套,測項分量近8000個,年產(chǎn)出數(shù)據(jù)量約500G左右(周克昌等,2013)。不同的儀器具有不同的采樣率,包括秒采、分采、時采、日采等儀器。在實際應(yīng)用中,由于經(jīng)常需要對某個具體儀器的觀測數(shù)據(jù)進行讀取、分析和處理操作,因此將相近測項的數(shù)據(jù)合并存儲在一張表中,同時將某臺儀器產(chǎn)生的觀測數(shù)據(jù)以天為單位壓縮為1個字符串,存儲在1條記錄中,大大減少了表中記錄的總條數(shù),提高了數(shù)據(jù)查詢效率,但在一定程度上增加了程序邏輯的復(fù)雜度。

2 地震業(yè)務(wù)處理特點分析

地震前兆觀測數(shù)據(jù)是典型的時間序列數(shù)據(jù),這些觀測數(shù)據(jù)是專家進行地震趨勢判斷、數(shù)據(jù)分析與挖掘、地震預(yù)報的基礎(chǔ)。在實際業(yè)務(wù)處理中,絕大部分數(shù)據(jù)讀取業(yè)務(wù)是按時間段連續(xù)讀取某臺觀測儀器的觀測數(shù)據(jù),幾乎沒有隨機讀取操作即通過組合臺站、測點、測項、采樣率和起止時間等條件查詢數(shù)據(jù)。以下是幾個典型的地震前兆原始數(shù)據(jù)處理場景：

(1)讀取某臺儀器某個測項在某一段時間內(nèi)的連續(xù)數(shù)據(jù)。

(2)讀取多臺儀器多個測項在某一段時間內(nèi)的連續(xù)數(shù)據(jù)。為了對比分析不同觀測數(shù)據(jù)的變化趨勢(如判斷前兆異常),需要對一段時間內(nèi)多臺儀器的多個測項連續(xù)觀測數(shù)據(jù)進行讀取、處理,以對比發(fā)現(xiàn)其中可能存在的規(guī)律。

(3)聚合函數(shù)應(yīng)用。由于數(shù)據(jù)可視化、分析等業(yè)務(wù)處理的需要,通常需要對某臺儀器的某個測項的某段數(shù)據(jù)內(nèi)的數(shù)據(jù)進行聚合操作,如取平均值、最大值、最小值等。

3 大數(shù)據(jù)環(huán)境下地震前兆觀測數(shù)據(jù)存儲方案

地震前兆觀測數(shù)據(jù)為時間序列數(shù)據(jù),屬于結(jié)構(gòu)化數(shù)據(jù)范疇。由于現(xiàn)有的關(guān)系數(shù)據(jù)庫在大數(shù)據(jù)規(guī)模下的讀取性能和并發(fā)性能等方面難以滿足科研人員需要,在設(shè)計大數(shù)據(jù)存儲方案時,必須考慮地震前兆觀測數(shù)據(jù)時間序列數(shù)據(jù)的固有特點以及按時間段讀取、聚合的業(yè)務(wù)特點。目前,地震前兆觀測儀器以分采和時采設(shè)備為主,秒采設(shè)備和日采設(shè)備較少。由于地震前兆觀測數(shù)據(jù)存儲平臺需要為用戶提供數(shù)據(jù)查詢、分析、可視化服務(wù)以及為各類異常事件檢測、地震分析預(yù)報等算法提供原始數(shù)據(jù),需要高效讀取數(shù)據(jù),因此需要高效的并發(fā)讀取性能。

在大數(shù)據(jù)環(huán)境下存儲地震前兆觀測數(shù)據(jù)主要有3種方案,一是直接基于HDFS文件系統(tǒng)進行存儲,可按照臺站、測項、儀器等建立多級目錄,然后將觀測數(shù)據(jù)按時間片段(如1天)進行存儲。該方案簡單、可靠、有效,但在讀取長時間段或多個儀器數(shù)據(jù)時,需要讀取多個數(shù)據(jù)文件,此時需要編寫業(yè)務(wù)邏輯進行數(shù)據(jù)合并,比較繁瑣。二是以O(shè)penTSDB為代表的時間序列數(shù)據(jù)庫。OpenTSDB作為分布式、可伸縮的通用時間序列數(shù)據(jù)庫,能夠提供毫秒級精度的時間序列數(shù)據(jù)存儲,并提供了多種簡便的訪問接口,無需過多設(shè)計,可以拿來即用。三是以HBase為代表的NoSQL數(shù)據(jù)庫。HBase是高可靠性、高性能、可伸縮的列式數(shù)據(jù)庫,可以支持超大規(guī)模數(shù)據(jù)存儲,但需要用戶根據(jù)數(shù)據(jù)特點和業(yè)務(wù)需求設(shè)計數(shù)據(jù)存儲結(jié)構(gòu),難度較OpenTSDB數(shù)據(jù)庫大很多。本文以地震前兆觀測大數(shù)據(jù)為例,基于OpenTSDB和HBase數(shù)據(jù)庫分別設(shè)計了地震大數(shù)據(jù)存儲方案,并對其讀寫性能進行了對比分析研究。

3.1 基于OpenTSDB的數(shù)據(jù)存儲方案

OpenTSDB面向時間序列數(shù)據(jù),提供了一套通用的時間序列數(shù)據(jù)存儲和查詢方案。在OpenTSDB中定義時間序列數(shù)據(jù)僅需要包含以下屬性：指標名稱(metric name)、時間戳(timestamp,單位為ms或者s)、值(value,64位整數(shù)或者單精度浮點數(shù))、1組標簽(tags,用于描述數(shù)據(jù)屬性,每個標簽由tagKey和tagValue組成)。

OpenTSDB底層依賴HBase數(shù)據(jù)庫,但在存儲上做了大量的優(yōu)化,如OpenTSDB為每個metric、tagKey和tagValue都分配了1個UID(固定為3個字節(jié)),大大縮短了row key長度,節(jié)省了存儲空間。將同屬于1個時間周期內(nèi)(默認1h)的具有相同TSUID(相同的metric以及相同的tags)的數(shù)據(jù)合并為1行存儲,大大減少了時間序列的行數(shù),提高了查詢效率和存儲效率。本次測試的存儲方案如表1 所示。

表1 基于OpenTSDB的存儲設(shè)計方案

3.2 基于HBase的數(shù)據(jù)存儲方案

HBase是一個高性能的列式數(shù)據(jù)庫,它可以處理超過10億行數(shù)據(jù)和數(shù)百萬列數(shù)據(jù)組成的數(shù)據(jù)表,其關(guān)鍵在于設(shè)計合理的row key,以方便數(shù)據(jù)查詢。與劉堅等(2015)提出的row key設(shè)計方案不同,我們借鑒了OpenTSDB設(shè)計思路,將觀測儀器1天內(nèi)的觀測數(shù)據(jù)合并為1條記錄,以采樣率為列簇,以該采樣率1天內(nèi)包含的數(shù)據(jù)數(shù)目為列數(shù),如Seconds列簇有86400列,Minutes列簇有1440列,Hours列簇有24列,Days列簇只有1列。row key為“臺站+測點+測項+采樣率+時間(日)”,其中“時間”精確到日,如表2 所示。

表2 基于HBase的存儲設(shè)計方案

此方案的優(yōu)點在于通過合并1天內(nèi)的觀測數(shù)據(jù)為1條記錄,一方面可以大大減少表中記錄的總數(shù)目,提高查詢效率；另一方面,通過將1天內(nèi)的數(shù)據(jù)存儲在不同的列中,可直接讀取某列來獲取其值,不需要字符串拆分操作；最后,通過離線計算秒采、分采和時采數(shù)據(jù)的分均值、時均值和日均值數(shù)據(jù)等,并寫入到對應(yīng)的列中,大大提高部分聚合查詢請求的性能。

4 實驗對比

4.1 實驗環(huán)境

為對比大數(shù)據(jù)環(huán)境下地震前兆觀測數(shù)據(jù)不同存儲方案的存儲、查詢性能指標,基于OpenStack云平臺搭建了由10臺服務(wù)器組成的Hadoop高可靠(HA)集群。每個節(jié)點包含1顆2核CPU、8G內(nèi)存和500G硬盤。Hadoop集群的每個節(jié)點均安裝了CentOS 7和JDK 1.8,并在相應(yīng)的節(jié)點上安裝了Hadoop 2.7.6、zookeeper 3.4.10、HBase 1.3.2、和Opentsdb 2.3.0軟件。每個節(jié)點的角色分配情況如表3 所示，表中“√”表示本節(jié)點安裝了該項配置，M表示HMaster節(jié)點,S2為HMaster備份節(jié)點,R為RegionServer節(jié)點。8臺RegionServer節(jié)點上均部署了OpenTSDB服務(wù)。

表3 HBase 與OpenTSDB的實驗配置

此外,為了測試關(guān)系數(shù)據(jù)庫的系統(tǒng)性能,選用1臺硬件配置較高的服務(wù)器進行單機測試,該主機包含2個Intel(R)Xeon(R)E5-2620 V4 CPU(2.1 GHz,8核),64G內(nèi)存和5塊2T硬盤(RAID 5)。安裝了CentOS 7、JDK 1.8和MySQL 5.0數(shù)據(jù)庫,并創(chuàng)建了現(xiàn)有數(shù)據(jù)存儲方案。

所有測試指令由1臺單獨的PC計算機執(zhí)行,并發(fā)測試采用多線程技術(shù)進行模擬實現(xiàn)。

測試程序應(yīng)用Java開放語言,程序通過JDBC連接MySQL數(shù)據(jù)庫實現(xiàn)讀寫操作,通過Native Java API訪問HBase集群,通過HTTP API接口連接到OpenTSDB服務(wù)器。在多線程并發(fā)測試時,HBase HMaster節(jié)點(S1)可以根據(jù)用戶的請求自動將其分配到某個RegionServer節(jié)點。由于OpenTSDB不支持自動負載均衡,因此通過程序以平均分配的方式將查詢和存儲請求分發(fā)給不同的OpenTSDB節(jié)點。

4.2 實驗結(jié)果分析

首先,模擬多臺儀器同時入庫操作。測試程序分別開啟1、10、50、100、200、250個并發(fā)線程,模擬多臺儀器執(zhí)行插入操作,分別連續(xù)運行3min,計算插入操作的平均事務(wù)響應(yīng)時間和事務(wù)吞吐量。圖1 為寫操作平均響應(yīng)時間,由圖1 可以看出,在并發(fā)客戶數(shù)較少時,MySQL具有明顯的并發(fā)優(yōu)勢,響應(yīng)時間明顯小于HBase和OpenTSDB,隨著并發(fā)客戶數(shù)增多,MySQL的平均響應(yīng)時間急速上升,這也是目前基于關(guān)系數(shù)據(jù)庫的地震前兆處理軟件程序面臨的主要問題之一。HBase和OpenTSDB并未因并發(fā)客戶端的增多而大幅增加,表現(xiàn)出較好的可擴展性。圖2 為寫操作事務(wù)吞吐情況,由圖2 也可以看出,隨著并發(fā)用戶數(shù)的增加,HBase基本上呈線性上升趨勢,表明本次測試并未達到系統(tǒng)并發(fā)處理能力的極限,還有很大的并發(fā)提升空間。OpenTSDB也呈現(xiàn)出了上升趨勢,但其并發(fā)性能明顯不如HBase。MySQL數(shù)據(jù)庫在并發(fā)數(shù)達到100后,事務(wù)吞吐量反而有所下降,表明了單機MySQL的并發(fā)規(guī)模應(yīng)該在150個左右,用戶數(shù)過多會導(dǎo)致系統(tǒng)性能下降。實驗發(fā)現(xiàn)單機MySQL的并發(fā)規(guī)模與系統(tǒng)硬件配置有一定的關(guān)系,硬件配置越高,并發(fā)數(shù)越大。

圖1 寫操作平均響應(yīng)時間

圖2 寫操作事務(wù)吞吐量

根據(jù)上述業(yè)務(wù)需求分析,客戶通常需要讀取某臺儀器某個測項在某一段時間內(nèi)或多臺儀器多個測項一段時間內(nèi)的連續(xù)數(shù)據(jù)。在本次實驗中,首先模擬產(chǎn)生了1億條記錄,然后分別測試了單用戶模式和200個并發(fā)用戶模式下獲取1天、1周、1年和10年觀測數(shù)據(jù)記錄的查詢操作平均響應(yīng)時間。圖3 為單用戶查詢操作平均響應(yīng)時間,圖3 表明,MySQL和HBase在單用戶模式下,在相同查詢規(guī)模下,表現(xiàn)出比較穩(wěn)定的查詢效率,HBase性能比MySQL略好,OpenTSDB數(shù)據(jù)庫性能最差。其主要原因在于,在單用戶模式下,測試程序必須先連接到HMaster節(jié)點,然后定位到目標數(shù)據(jù),再連接到HRegion節(jié)點獲取數(shù)據(jù),而MySQL服務(wù)器直接在本地查詢數(shù)據(jù),故無法發(fā)揮HBase的并發(fā)優(yōu)點。而在OpenTSDB方案中,由于數(shù)據(jù)存儲在HBase中,很有可能導(dǎo)致待讀取數(shù)據(jù)和OpenTSDB服務(wù)器不在一臺服務(wù)器上,查詢的數(shù)據(jù)都需要OpenTSDB服務(wù)器進行中轉(zhuǎn),導(dǎo)致耗時增多,系統(tǒng)性能下降明顯。圖4 為200用戶并發(fā)查詢操作平均響應(yīng)時間,在圖4 中,HBase的平均響應(yīng)時間并未隨著并發(fā)客戶數(shù)的增多而有明顯變化,相反，MySQL具有明顯的增長現(xiàn)象,OpenTSDB更是幾乎直線上升，這也表明MySQL的單機并發(fā)性具有一定局限性。雖然OpenTSDB服務(wù)器可以并發(fā)處理來自多個客戶端的查詢請求,但是由于業(yè)務(wù)處理和數(shù)據(jù)通常不在一起,所以這種模式的代價較高。

圖3 單用戶查詢操作平均響應(yīng)時間

圖4 200用戶并發(fā)查詢操作平均響應(yīng)時間

5 結(jié)語

本文面向海量地震前兆觀測數(shù)據(jù),提出了基于OpenTSDB和HBase的地震前兆大數(shù)據(jù)存儲方案,并與傳統(tǒng)的基于關(guān)系數(shù)據(jù)庫的存儲方案在讀取和插入操作方面進行了對比研究。實驗結(jié)果表明,基于HBase的存儲方案無論在查詢操作方面,還是在插入操作方面,均表現(xiàn)出了較好的性能,且具有很強的可擴展性和并發(fā)性。OpenTSDB是一種基于HBase數(shù)據(jù)庫,面向時間序列數(shù)據(jù)的通用數(shù)據(jù)庫,雖然與HBase數(shù)據(jù)庫一樣提供了良好的可擴展性和并發(fā)性,但OpenTSDB并不自動提供負載均衡策略,需要用戶自己在程序?qū)幼远x負載均衡策略,致使OpenTSDB服務(wù)處理程序和待訪問數(shù)據(jù)不在同一臺計算機上,固其讀寫性能與HBase方案相比略差。但由于其操作簡單、接口豐富,加上良好的可擴展性和可伸縮性,因此也是大數(shù)據(jù)環(huán)境下常被采用的方案。此外,HBase可以通過預(yù)分區(qū),參數(shù)調(diào)優(yōu)等方法進一步提高系統(tǒng)的性能。總之,基于云平臺和大數(shù)據(jù)技術(shù)的地震大數(shù)據(jù)存儲和分析業(yè)務(wù)方案將是未來地震綜合數(shù)據(jù)處理的發(fā)展方向。