陳曉琳，李盛樂，劉 堅，劉珠妹

(中國地震局地震研究所 地震大地測量重點實驗室，湖北 武漢 430071)

0 引言

地震前兆觀測數(shù)據(jù)作為基礎(chǔ)數(shù)據(jù)，在地震研究中具有廣泛應(yīng)用。為使地震研究人員更方便、廣泛地獲得全國范圍內(nèi)的地震前兆觀測數(shù)據(jù)，中國地震臺網(wǎng)中心聯(lián)合中國地震局地震研究所開發(fā)了地震數(shù)據(jù)對內(nèi)共享服務(wù)平臺(謝有順等，2017)。該平臺匯集了800多個前兆觀測臺站、2 900多套前兆儀器的實時產(chǎn)出數(shù)據(jù)，學(xué)科預(yù)處理、專業(yè)處理的產(chǎn)品數(shù)據(jù)共計973 GB；主要采用B/S架構(gòu)，用戶直接通過瀏覽器訪問位于服務(wù)器端的Oracle前兆共享數(shù)據(jù)庫。在平臺測試運行階段，由于用戶查詢、下載數(shù)據(jù)量較大，Oracle數(shù)據(jù)庫的查詢、讀取速度極大地制約了共享平臺的訪問性能。因此，為了解決該問題，需要研究地震前兆數(shù)據(jù)在大數(shù)據(jù)平臺下的存儲方案(劉堅等，2015)。在大數(shù)據(jù)環(huán)境下發(fā)展起來的新型分布式數(shù)據(jù)庫Greenplum具有專為大規(guī)模查詢、下載設(shè)計的并行處理架構(gòu)(Bani，Girsang，2018)；并且擁有良好的線性擴(kuò)展能力，能方便地增加系統(tǒng)的存儲容量和處理能力，這些優(yōu)勢都較好地契合了前兆數(shù)據(jù)共享服務(wù)的存儲需求。

由于Greenplum數(shù)據(jù)庫的良好性能，在國內(nèi)外大型企業(yè)中得到了廣泛的關(guān)注。紐約證券交易所(NYSE)采用Greenplum數(shù)據(jù)庫支持其海量數(shù)據(jù)的高速查詢(Kauretal，2012)；國內(nèi)最早開始使用Greenplum數(shù)據(jù)庫的是阿里巴巴(中國)網(wǎng)絡(luò)技術(shù)有限公司，其在2008年引入該技術(shù)，將原有的Oracle數(shù)據(jù)庫遷移到Greenplum數(shù)據(jù)庫上作為數(shù)據(jù)中心，進(jìn)行產(chǎn)品關(guān)聯(lián)分析(何勇，陳曉峰，2014)；銀行等金融機(jī)構(gòu)采用了Greenplum數(shù)據(jù)庫分布式架構(gòu)技術(shù)來支持其大批量數(shù)據(jù)的查詢需求(張文升，2017)；移動通信運營商將Greenplum數(shù)據(jù)庫作為數(shù)據(jù)倉庫，利用分布式算法挖掘出隱藏在數(shù)據(jù)中的關(guān)聯(lián)關(guān)系，從而幫助運營商對客戶進(jìn)行精準(zhǔn)營銷(余彪，2015)。但值得注意的是，以上應(yīng)用均是定位于OLAP(聯(lián)機(jī)分析處理，On-Line Analytical Processing)場景，這是由于Greenplum數(shù)據(jù)庫的并行處理架構(gòu)，更適合作為數(shù)據(jù)倉庫使用。Greenplum數(shù)據(jù)庫不能替代前兆業(yè)務(wù)的所有場景。傳統(tǒng)Oracle數(shù)據(jù)庫適合前兆業(yè)務(wù)前端OLTP(聯(lián)機(jī)事務(wù)處理過程，On-Line Transaction Processing)場景，比如高頻次的數(shù)據(jù)采集與交換的增刪改操作；而Greenplum數(shù)據(jù)庫中基于數(shù)據(jù)倉庫的信息處理過程，更適合作為數(shù)據(jù)共享查詢、下載服務(wù)的后端數(shù)據(jù)庫。

本文根據(jù)前兆數(shù)據(jù)共享需求，制定了前兆數(shù)據(jù)在Greenplum數(shù)據(jù)庫下的存儲策略?；诘卣鹦袠I(yè)網(wǎng)搭建了Greenplum分布式數(shù)據(jù)庫環(huán)境，并從前兆數(shù)據(jù)讀取性能、數(shù)據(jù)庫可擴(kuò)展性能、前兆應(yīng)用軟件兼容性等方面對Greenplum數(shù)據(jù)庫與Oracle數(shù)據(jù)庫進(jìn)行了對比測試。

1 Greenplum數(shù)據(jù)庫原理

目前，大數(shù)據(jù)存儲或計算是熱點問題，涌現(xiàn)了許多的大數(shù)據(jù)存儲技術(shù)。而Greenplum數(shù)據(jù)庫作為關(guān)系型數(shù)據(jù)庫，更容易和目前使用的Oracle數(shù)據(jù)庫進(jìn)行對接、轉(zhuǎn)換。另外Greenplum數(shù)據(jù)庫完全支持SQL標(biāo)準(zhǔn)，支持ODBC和JDBC，從應(yīng)用編程接口上講，更利于原有的地震數(shù)據(jù)分析應(yīng)用軟件遷移到大數(shù)據(jù)平臺。

1.1 分布式并行架構(gòu)

Greenplum數(shù)據(jù)庫采用了大規(guī)模并行處理架構(gòu)(Massively Parallel Processing，以下簡稱MPP)，MPP是由2個或多個處理器構(gòu)成的系統(tǒng)。每個處理器都有自己的內(nèi)存、操作系統(tǒng)和磁盤，它們并行執(zhí)行用戶操作(陳達(dá)倫等，2016)。主節(jié)點Master是Greenplum數(shù)據(jù)庫系統(tǒng)的入口點(圖1)，是與客戶端連接并提交SQL語句的數(shù)據(jù)庫實例。

圖1 Greenplum數(shù)據(jù)庫集群架構(gòu)

主節(jié)點Master將工作負(fù)載分發(fā)給其它數(shù)據(jù)庫實例(Segment Instance)進(jìn)行存儲和處理數(shù)據(jù)。Interconnect(網(wǎng)絡(luò)層)支持在不同的Segment實例(獨立的PostgreSQL數(shù)據(jù)庫)之間進(jìn)行通信，并允許系統(tǒng)作為一個邏輯數(shù)據(jù)庫運行。由于Greenplum數(shù)據(jù)庫使用這種高性能的系統(tǒng)架構(gòu)來分擔(dān)數(shù)據(jù)倉庫的負(fù)載，并可以并行使用系統(tǒng)的所有資源來處理用戶任務(wù)。因此，Greenplum數(shù)據(jù)庫在大數(shù)據(jù)量的查詢、下載時表現(xiàn)出了優(yōu)越的性能。

Greenplum數(shù)據(jù)庫是基于PostgreSQL的數(shù)據(jù)庫集群(Waas，2009)，它們共同工作以呈現(xiàn)單個數(shù)據(jù)庫映像。大多數(shù)情況下，在SQL語句、特性、配置選項和最終用戶功能方面，Greenplum數(shù)據(jù)庫與PostgreSQL數(shù)據(jù)庫非常相似，數(shù)據(jù)庫用戶與Greenplum數(shù)據(jù)庫交互，就像與普通的PostgreSQL數(shù)據(jù)庫交互一樣。但是Greenplum數(shù)據(jù)庫對PostgreSQL數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)進(jìn)行了修改或補(bǔ)充，以支持它的并行結(jié)構(gòu)。例如，系統(tǒng)目錄、優(yōu)化器、查詢器和事務(wù)管理器組件已經(jīng)被修改和增強(qiáng)，以便能夠讓所有分布式PostgreSQL數(shù)據(jù)庫同時并發(fā)執(zhí)行。

1.2 數(shù)據(jù)分布與同步

由于Greenplum數(shù)據(jù)庫的分布式架構(gòu)，因此所有的表都會被切片成若干數(shù)據(jù)片存儲在Segment上。分區(qū)策略可以為隨機(jī)分布和Hash分布。隨機(jī)分布中數(shù)據(jù)被隨機(jī)分散到每個Segment，雖然這種分布方式可以保證數(shù)據(jù)被均勻分布到每個Segment，但是在進(jìn)行表的關(guān)聯(lián)操作時，需要根據(jù)關(guān)聯(lián)鍵重分布數(shù)據(jù)，所以隨機(jī)分布性能較差。Hash分布可以指定表的一列或者多列組合作為Hash Key來進(jìn)行數(shù)據(jù)分布。Greenplum數(shù)據(jù)庫會根據(jù)指定的Hash Key列來計算每一行數(shù)據(jù)對應(yīng)的Hash值，并映射至相應(yīng)的Segment實例。對于Greenplum數(shù)據(jù)庫，如果用戶創(chuàng)建表時未指定數(shù)據(jù)分布方式，則默認(rèn)為Hash分布，并且將主鍵作為Hash Key，如果沒有設(shè)置主鍵則選擇第一列作為Hash Key。

為了避免單點故障，Greenplum數(shù)據(jù)庫對主節(jié)點和各數(shù)據(jù)節(jié)點均采用備份策略。當(dāng)主節(jié)點Master發(fā)生故障時，激活主節(jié)點備份Standby主機(jī)接管Master事務(wù)，它們之間通過流復(fù)制技術(shù)實現(xiàn)同步復(fù)制。如圖1所示，主數(shù)據(jù)節(jié)點(Primary)和它的鏡像(Mirror)是分配在不同的主機(jī)上，以防止某一數(shù)據(jù)節(jié)點故障導(dǎo)致數(shù)據(jù)庫的訪問異常。主節(jié)點和其數(shù)據(jù)鏡像之間通過文件操作級來實現(xiàn)數(shù)據(jù)的同步(GISEarth，2016)。

2 前兆數(shù)據(jù)建庫關(guān)鍵技術(shù)

2.1 集群環(huán)境搭建

在行業(yè)網(wǎng)內(nèi)搭建Greenplum分布式數(shù)據(jù)庫環(huán)境，初始化搭建時由1個主節(jié)點(Master)和3個數(shù)據(jù)節(jié)點(Segment Host)組成，節(jié)點間使用千兆網(wǎng)絡(luò)連接，節(jié)點配置見表1。

表1 Greenplum數(shù)據(jù)庫集群服務(wù)器參數(shù)

高可用性設(shè)計：主節(jié)點(Master)負(fù)責(zé)解析、分發(fā)SQL語句，收集、匯總查詢數(shù)據(jù)等工作。因此必須保證主節(jié)點的高可用性，這里同時將Segment Host3機(jī)器設(shè)置為主節(jié)點的備份節(jié)點(Master Standby)。每個數(shù)據(jù)節(jié)點都配備鏡像數(shù)據(jù)，當(dāng)主數(shù)據(jù)節(jié)點發(fā)生故障時，Mirror節(jié)點會自動切換為Primary，不會對前臺應(yīng)用產(chǎn)生影響。

在線擴(kuò)展：各類前兆觀測臺站800多個，前兆儀器2 900多套，各測項采樣率逐漸提高，秒采樣逐漸成為趨勢。秒采樣的數(shù)據(jù)量比分采樣的數(shù)據(jù)量提高了60倍，并且后期設(shè)計要接入氣象觀測數(shù)據(jù)。當(dāng)數(shù)據(jù)量日益增大，現(xiàn)有集群不能滿足需求時，可以通過增加集群數(shù)量對Greenplum數(shù)據(jù)庫進(jìn)行線性擴(kuò)展。擴(kuò)展過程中，業(yè)務(wù)可以繼續(xù)運行，不需要宕機(jī)。

2.2 存儲分布策略

對于Greenplum數(shù)據(jù)庫，影響SQL查詢性能的最重要因素是數(shù)據(jù)分布是否均勻。如果數(shù)據(jù)在Segment分布不均勻，會導(dǎo)致短板效應(yīng)，因此設(shè)計合適的存儲分布策略至關(guān)重要。一般情況下，如果數(shù)據(jù)經(jīng)常被高并發(fā)的鍵值或離散查詢，將查詢條件的列作為分布列，這樣不需要連接到所有的Segment去查，可以大大提高并發(fā)能力。因此根據(jù)前兆數(shù)據(jù)共享需求，制定了如下存儲規(guī)則：指定表的主鍵(臺站編碼、測點編碼、測項編碼、開始時間)作為分布鍵。

在Greenplum數(shù)據(jù)庫中除了將數(shù)據(jù)分布到各Segment外，還要對各Segment上的數(shù)據(jù)進(jìn)行分區(qū)，分布和分區(qū)共同決定數(shù)據(jù)的查詢效率。分區(qū)是從邏輯上對同一個Segment上的表數(shù)據(jù)進(jìn)行劃分，這樣可以優(yōu)化查詢性能，不會影響數(shù)據(jù)在各個Segment上的分布情況。目前Greenplum數(shù)據(jù)庫支持LIST和RANGE兩種分區(qū)類型。分區(qū)的目的是盡可能地縮小QUERY需要掃描的數(shù)據(jù)量，因此必須和查詢條件相關(guān)聯(lián)。鑒于此，本文以時間作為分區(qū)鍵，選擇RANGE分區(qū)類型。

2.3 字段類型設(shè)計

Greenplum數(shù)據(jù)庫的數(shù)據(jù)類型十分豐富，基本與Oracle數(shù)據(jù)庫的一樣，僅在少數(shù)數(shù)據(jù)類型上有區(qū)別(Rajputetal，2013)。在建設(shè)前兆Greenplum數(shù)據(jù)庫時，參照“十五”前兆數(shù)據(jù)庫(周克昌等，2010)中的常用數(shù)據(jù)類型選擇了對應(yīng)的數(shù)據(jù)類型，見表2。

表2 Greenplum數(shù)據(jù)庫字段類型

3 性能測試與結(jié)果分析

為了更好地進(jìn)行前兆共享數(shù)據(jù)庫的選型，本文從數(shù)據(jù)查詢、集群擴(kuò)展等方面對Greenplum數(shù)據(jù)庫進(jìn)行了測試實驗，并給出了測試結(jié)果。

3.1 數(shù)據(jù)讀取性能測試

以QZ_312_DYS_02(地磁變化記錄秒數(shù)據(jù))表為例，對部署于相同網(wǎng)段的Oracle和Greenplum數(shù)據(jù)庫進(jìn)行數(shù)據(jù)讀取速度測試。測試程序采用Java編寫，利用JDBC驅(qū)動遠(yuǎn)程連接數(shù)據(jù)庫。分別進(jìn)行了小數(shù)據(jù)量和大數(shù)據(jù)量的查詢測試，查詢結(jié)果見表3。

表3 查詢測試結(jié)果

從表3測試結(jié)果來看，對于小數(shù)據(jù)量的查詢處理，Oracle和Greenplum數(shù)據(jù)庫均可以在較短的時間內(nèi)完成處理，用戶等待時間差距不明顯；而對于大批量數(shù)據(jù)的查詢處理，Oracle數(shù)據(jù)庫等待時間較長，Greenplum數(shù)據(jù)庫則在很短的時間即可完成查詢?nèi)蝿?wù)。顯然，對于大批量數(shù)據(jù)的查詢處理，Greenplum數(shù)據(jù)庫明顯優(yōu)于Oracle數(shù)據(jù)庫。這是由于Greenplum數(shù)據(jù)庫將查詢?nèi)蝿?wù)分布至各個數(shù)據(jù)節(jié)點進(jìn)行并行處理，充分利用了各數(shù)據(jù)節(jié)點的CPU和IO能力，使數(shù)據(jù)分析處理能力得到提升。

3.2 可擴(kuò)展性能測試

Greenplum數(shù)據(jù)庫的重要特性是能在數(shù)據(jù)規(guī)模增大時便捷地進(jìn)行線性擴(kuò)展，通過增加節(jié)點數(shù)量高效提升數(shù)據(jù)庫的性能。為此，本文在基礎(chǔ)集群為4節(jié)點的基礎(chǔ)上，逐步將集群增加至6，8節(jié)點，對數(shù)據(jù)庫的擴(kuò)展性進(jìn)行了測試，結(jié)果見表4。

表4 不同節(jié)點集群上查詢測試結(jié)果

測試結(jié)果顯示，隨著節(jié)點數(shù)的增加，Greenplum數(shù)據(jù)庫的查詢效率也隨之提升。這種良好的橫向擴(kuò)展性可以支持?jǐn)?shù)據(jù)庫良好的成長，以應(yīng)對不斷增長的前兆觀測數(shù)據(jù)。

3.3 應(yīng)用兼容性測試

現(xiàn)有的前兆各學(xué)科各種數(shù)據(jù)處理軟件基于Oracle數(shù)據(jù)庫運行多年(王建軍等，2019)，其主要數(shù)據(jù)庫操作部分均為查詢讀取，較好地匹配了Greenplum數(shù)據(jù)庫的數(shù)據(jù)讀取優(yōu)勢。如果能將其后臺數(shù)據(jù)庫遷移至Greenplum數(shù)據(jù)庫，將會極大地提升數(shù)據(jù)處理效率。而且本文所采用的Greenplum數(shù)據(jù)庫完全支持SQL標(biāo)準(zhǔn)，支持ODBC和JDBC。因此只需修改這些軟件的數(shù)據(jù)庫接口部分的代碼，便可以將底層數(shù)據(jù)庫經(jīng)由Oracle轉(zhuǎn)換為Greenplum。以前兆數(shù)據(jù)處理中的周期分析和前兆數(shù)據(jù)共享網(wǎng)站為例，分別測試Greenplum數(shù)據(jù)庫對SQL標(biāo)準(zhǔn)及ODBC和JDBC的支持。

表5 Greenplum數(shù)據(jù)庫的ODBC及JDBC訪問測試

4 結(jié)論

本文提出將分布式數(shù)據(jù)庫Greenplum用于前兆數(shù)據(jù)共享服務(wù)，以滿足大批量前兆數(shù)據(jù)的快速讀取需求。通過在地震行業(yè)網(wǎng)內(nèi)搭建分布式集群服務(wù)器，部署了基于Greenplum的前兆共享數(shù)據(jù)庫。性能測試實驗表明，與傳統(tǒng)Oracle數(shù)據(jù)庫相比，基于Greenplum的前兆共享數(shù)據(jù)庫在大批量的數(shù)據(jù)查詢處理上，具有顯著的優(yōu)勢，并且Greenplum數(shù)據(jù)庫架構(gòu)具有良好的可擴(kuò)展性，隨著節(jié)點數(shù)的增加，查詢效率能得到進(jìn)一步提升。Greenplum數(shù)據(jù)庫作為大數(shù)據(jù)環(huán)境下發(fā)展起來的數(shù)據(jù)庫，增加了可編程并行分析挖掘功能，并提供廣泛的語言支持，使得現(xiàn)有的前兆分析應(yīng)用程序移植起來極為方便。因此，利用Greenplum數(shù)據(jù)庫開展前兆數(shù)據(jù)庫分析挖掘是下一步的研究方向。

測試環(huán)境搭建過程中，得到南京云創(chuàng)存儲科技有限公司地震研發(fā)組成員馬鳴、陳旭等的大力支持和熱心幫助，在此表示感謝！