分布式數(shù)據(jù)庫Greenplum在地震前兆數(shù)據(jù)存儲(chǔ)中的應(yīng)用*

陳曉琳，李盛樂，劉 堅(jiān)，劉珠妹

(中國地震局地震研究所 地震大地測(cè)量重點(diǎn)實(shí)驗(yàn)室，湖北 武漢 430071)

0 引言

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

由于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)；移動(dòng)通信運(yùn)營(yíng)商將Greenplum數(shù)據(jù)庫作為數(shù)據(jù)倉庫，利用分布式算法挖掘出隱藏在數(shù)據(jù)中的關(guān)聯(lián)關(guān)系，從而幫助運(yùn)營(yíng)商對(duì)客戶進(jìn)行精準(zhǔn)營(yíng)銷(余彪，2015)。但值得注意的是，以上應(yīng)用均是定位于OLAP(聯(lián)機(jī)分析處理，On-Line Analytical Processing)場(chǎng)景，這是由于Greenplum數(shù)據(jù)庫的并行處理架構(gòu)，更適合作為數(shù)據(jù)倉庫使用。Greenplum數(shù)據(jù)庫不能替代前兆業(yè)務(wù)的所有場(chǎng)景。傳統(tǒng)Oracle數(shù)據(jù)庫適合前兆業(yè)務(wù)前端OLTP(聯(lián)機(jī)事務(wù)處理過程，On-Line Transaction Processing)場(chǎng)景，比如高頻次的數(shù)據(jù)采集與交換的增刪改操作；而Greenplum數(shù)據(jù)庫中基于數(shù)據(jù)倉庫的信息處理過程，更適合作為數(shù)據(jù)共享查詢、下載服務(wù)的后端數(shù)據(jù)庫。

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

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

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

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

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

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

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

Greenplum數(shù)據(jù)庫是基于PostgreSQL的數(shù)據(jù)庫集群(Waas，2009)，它們共同工作以呈現(xiàn)單個(gè)數(shù)據(jù)庫映像。大多數(shù)情況下，在SQL語句、特性、配置選項(xiàng)和最終用戶功能方面，Greenplum數(shù)據(jù)庫與PostgreSQL數(shù)據(jù)庫非常相似，數(shù)據(jù)庫用戶與Greenplum數(shù)據(jù)庫交互，就像與普通的PostgreSQL數(shù)據(jù)庫交互一樣。但是Greenplum數(shù)據(jù)庫對(duì)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ù)庫同時(shí)并發(fā)執(zhí)行。

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

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

為了避免單點(diǎn)故障，Greenplum數(shù)據(jù)庫對(duì)主節(jié)點(diǎn)和各數(shù)據(jù)節(jié)點(diǎn)均采用備份策略。當(dāng)主節(jié)點(diǎn)Master發(fā)生故障時(shí)，激活主節(jié)點(diǎn)備份Standby主機(jī)接管Master事務(wù)，它們之間通過流復(fù)制技術(shù)實(shí)現(xiàn)同步復(fù)制。如圖1所示，主數(shù)據(jù)節(jié)點(diǎn)(Primary)和它的鏡像(Mirror)是分配在不同的主機(jī)上，以防止某一數(shù)據(jù)節(jié)點(diǎn)故障導(dǎo)致數(shù)據(jù)庫的訪問異常。主節(jié)點(diǎn)和其數(shù)據(jù)鏡像之間通過文件操作級(jí)來實(shí)現(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)境，初始化搭建時(shí)由1個(gè)主節(jié)點(diǎn)(Master)和3個(gè)數(shù)據(jù)節(jié)點(diǎn)(Segment Host)組成，節(jié)點(diǎn)間使用千兆網(wǎng)絡(luò)連接，節(jié)點(diǎn)配置見表1。

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

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

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

2.2 存儲(chǔ)分布策略

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

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

2.3 字段類型設(shè)計(jì)

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

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

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

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

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

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

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

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

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

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

表4 不同節(jié)點(diǎn)集群上查詢測(cè)試結(jié)果

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

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

現(xiàn)有的前兆各學(xué)科各種數(shù)據(jù)處理軟件基于Oracle數(shù)據(jù)庫運(yùn)行多年(王建軍等，2019)，其主要數(shù)據(jù)庫操作部分均為查詢讀取，較好地匹配了Greenplum數(shù)據(jù)庫的數(shù)據(jù)讀取優(yōu)勢(shì)。如果能將其后臺(tái)數(shù)據(jù)庫遷移至Greenplum數(shù)據(jù)庫，將會(huì)極大地提升數(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)站為例，分別測(cè)試Greenplum數(shù)據(jù)庫對(duì)SQL標(biāo)準(zhǔn)及ODBC和JDBC的支持。

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

4 結(jié)論

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

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