分布式數據庫Greenplum在地震前兆數據存儲中的應用*

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

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

0 引言

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

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

本文根據前兆數據共享需求，制定了前兆數據在Greenplum數據庫下的存儲策略。基于地震行業網搭建了Greenplum分布式數據庫環境，并從前兆數據讀取性能、數據庫可擴展性能、前兆應用軟件兼容性等方面對Greenplum數據庫與Oracle數據庫進行了對比測試。

1 Greenplum數據庫原理

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

1.1 分布式并行架構

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

圖1 Greenplum數據庫集群架構

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

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

1.2 數據分布與同步

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

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

2 前兆數據建庫關鍵技術

2.1 集群環境搭建

在行業網內搭建Greenplum分布式數據庫環境，初始化搭建時由1個主節點(Master)和3個數據節點(Segment Host)組成，節點間使用千兆網絡連接，節點配置見表1。

表1 Greenplum數據庫集群服務器參數

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

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

2.2 存儲分布策略

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

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

2.3 字段類型設計

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

表2 Greenplum數據庫字段類型

3 性能測試與結果分析

為了更好地進行前兆共享數據庫的選型，本文從數據查詢、集群擴展等方面對Greenplum數據庫進行了測試實驗，并給出了測試結果。

3.1 數據讀取性能測試

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

表3 查詢測試結果

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

3.2 可擴展性能測試

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

表4 不同節點集群上查詢測試結果

測試結果顯示，隨著節點數的增加，Greenplum數據庫的查詢效率也隨之提升。這種良好的橫向擴展性可以支持數據庫良好的成長，以應對不斷增長的前兆觀測數據。

3.3 應用兼容性測試

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

表5 Greenplum數據庫的ODBC及JDBC訪問測試

4 結論

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

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