面向混合負載的分布式氣象數(shù)據(jù)管理系統(tǒng)設(shè)計

陳 超，顧青峰

（中國氣象局氣象發(fā)展與規(guī)劃院，北京 100081）

0 引 言

氣象數(shù)據(jù)具有數(shù)據(jù)規(guī)模大、數(shù)據(jù)類型多樣化等特點［1］。例如歐洲中期天氣預(yù)報中心（European Centre for Medium-Range Weather Forecasts，ECMWF）目前每日數(shù)據(jù)增量為300 TB，當前數(shù)據(jù)存量已經(jīng)超過500 PB。隨著氣象傳感器的增加與氣象高性能計算能力的提升，經(jīng)緯度的精度越來越高，氣象數(shù)據(jù)的規(guī)模也呈現(xiàn)爆發(fā)性增長。而且，氣象數(shù)據(jù)不僅規(guī)模大、增速快，同時也面臨天氣預(yù)報、氣候變化分析等很多種氣象業(yè)務(wù)的大量查詢需求，其中很多查詢的延遲要求非常高［2-3］。

因此，氣象數(shù)據(jù)管理系統(tǒng)需要同時具備大容量、高速寫入、高速查詢的需求。目前氣象數(shù)據(jù)管理系統(tǒng)優(yōu)先滿足大容量的需求，大部分放在大規(guī)模存儲系統(tǒng)中維護，應(yīng)對查詢，特別是復雜查詢的能力不足，迫切需要構(gòu)建一套面對讀、寫混合負載時能夠達到高性能的新一代大容量分布式氣象數(shù)據(jù)管理系統(tǒng)。本文基于國際上最先進的類Spanner 分布式數(shù)據(jù)庫架構(gòu)，重點對分布式數(shù)據(jù)庫同時應(yīng)對數(shù)據(jù)寫入與查詢的能力進行優(yōu)化，設(shè)計和實現(xiàn)一套面向混合負載的分布式氣象數(shù)據(jù)管理系統(tǒng)，能夠在保持高寫入性能的前提下，將復雜查詢的性能提升3.13倍。

1 相關(guān)工作

氣象數(shù)據(jù)［4-5］符合大數(shù)據(jù)的4 個V 特征，包括海量的數(shù)據(jù)規(guī)模（Volume）、快速的數(shù)據(jù)流轉(zhuǎn)和動態(tài)的數(shù)據(jù)體系（Velocity）、多樣的數(shù)據(jù)類型（Variety）和巨大的數(shù)據(jù)價值（Value）［6-7］，這也給氣象數(shù)據(jù)管理系統(tǒng)帶來很多挑戰(zhàn)。以氣象數(shù)據(jù)中占比很高的氣象模式數(shù)據(jù)為例，可以看出氣象數(shù)據(jù)不僅規(guī)模大、類型復雜，而且數(shù)據(jù)快速流動、查詢類型多樣。在氣象數(shù)據(jù)中，由衛(wèi)星、高空和地面的大量氣象傳感器記錄的狀態(tài)信息傳送到高性能計算機后，高性能計算機根據(jù)最新的天氣實況數(shù)據(jù)，通過物理方程計算運算產(chǎn)生了模式數(shù)據(jù)。模式數(shù)據(jù)包含了各個經(jīng)緯度、海拔上的多種預(yù)測的物理量（例如溫度、濕度、風速等），而且包括未來不同時間點的預(yù)測值（如未來3 h、6 h、72 h 等）。每天高性能計算機都需要計算和產(chǎn)生多次模式數(shù)據(jù)，用于提升天氣預(yù)報的準確度。近年來，涌現(xiàn)了大量數(shù)值模式相關(guān)的研究。同時隨著高性能計算機計算能力的不斷增長，模式數(shù)據(jù)的精度越來越高，規(guī)模也越來越大。天氣預(yù)報等大量氣象應(yīng)用同時對模式數(shù)據(jù)進行各種復雜查詢。

氣象數(shù)據(jù)管理系統(tǒng)面臨著同時進行高頻度的數(shù)據(jù)寫入與數(shù)據(jù)查詢的需求，非常符合Gartner 在2014年提出的新型混合事務(wù)和分析處理（Hybrid Transaction and Analytical Processing，HTAP）［8-9］應(yīng)用程序框架，兼顧傳統(tǒng)聯(lián)機事務(wù)處理（Online Transactional Processing，OLTP）［10-11］和聯(lián)機分析處理（Online Analytical Processing，OLAP）［12-13］的特點，因此對數(shù)據(jù)管理系統(tǒng)的要求也更高。典型的HTAP 數(shù)據(jù)庫產(chǎn)品包括Oracle Dual-Format［14］、MySQL HeatWave［15］等。目前我國氣象信息系統(tǒng)一般采用分布式存儲系統(tǒng)為主、數(shù)據(jù)庫系統(tǒng)為輔（例如存儲模式數(shù)據(jù)在文件系統(tǒng)中的位置，相當于索引的作用）來構(gòu)建氣象數(shù)據(jù)管理系統(tǒng)。這類系統(tǒng)應(yīng)對大規(guī)模存儲的能力強，但是應(yīng)對負載查詢的能力嚴重不足。

而國際上的大規(guī)模數(shù)據(jù)管理系統(tǒng)，在過去幾十年，經(jīng)歷了單機數(shù)據(jù)庫（例如PostgreSQL、MySQL 等）、大規(guī)模并行處理（Massive Parallel Processing，MPP）數(shù)據(jù)庫［16］、NoSQL［17-18］架構(gòu)，逐漸提升系統(tǒng)擴展性，可以管理更多數(shù)據(jù)。但是NoSQL 系統(tǒng)使用鍵值對等數(shù)據(jù)模型，放棄了嚴格的事務(wù)保障和復雜查詢能力，需要應(yīng)用做很多額外開發(fā)工作。因此，最近幾年，以Google 公司的Spanner［19］為代表，涌現(xiàn)了一批新的NewSQL 分布式數(shù)據(jù)管理系統(tǒng)，包括CockroachDB［20］、TiDB［21］等，可以兼顧事務(wù)保障和優(yōu)秀的擴展性的能力。

類Spanner 分布式數(shù)據(jù)庫系統(tǒng)的架構(gòu)如圖1 所示。系統(tǒng)一般由本地存儲引擎、分布式共識層、分布式事務(wù)層和SQL 引擎層構(gòu)成。本地存儲引擎目前多為鍵值對存儲引擎，如RocksDB［22］。同時為了提升系統(tǒng)的可靠性和可用性，一般同一份數(shù)據(jù)在不同節(jié)點上部署多個副本，防止部分節(jié)點出現(xiàn)軟硬件崩潰或網(wǎng)絡(luò)故障，從而導致系統(tǒng)中的數(shù)據(jù)無法訪問。分布式共識層一般采用Paxos 協(xié)議族［23-24］，例如Raft 協(xié)議［25］、ZAB［26］，保障系統(tǒng)的多個存儲副本達成一致，即使在部分節(jié)點崩潰時，系統(tǒng)仍能正常工作，不出現(xiàn)錯誤和一致性問題。分布式事務(wù)層一般采用兩階段提交（Two-Phase Commit，2PC）［27］方法在多個節(jié)點之間提供事務(wù)ACID 屬性的保障。SQL 引擎層負責SQL 語言解析、查詢計劃、優(yōu)化和執(zhí)行等功能。此外，系統(tǒng)中一般會有元數(shù)據(jù)管理節(jié)點來管理全局的元數(shù)據(jù)、提供時鐘服務(wù)和協(xié)調(diào)服務(wù)等。

圖1 類Spanner分布式數(shù)據(jù)管理系統(tǒng)架構(gòu)

但是這些NewSQL 系統(tǒng)主要是處理寫入為主的業(yè)務(wù)，應(yīng)對復雜查詢的能力不強，無法很好支撐HTAP 應(yīng)用，也不適合直接用于支持氣象數(shù)據(jù)管理。目前已有的HTAP 工作中，一般仍然是將多個子系統(tǒng)進行組合，部分子系統(tǒng)負責OLTP，部分子系統(tǒng)負責OLAP，在2 個子系統(tǒng)之間進行數(shù)據(jù)同步［21，28］，并沒有在系統(tǒng)設(shè)計上面向HTAP 進行原生的系統(tǒng)設(shè)計。氣象數(shù)據(jù)迫切需要一套擴展性好，同時應(yīng)對HTAP 能力強的新型分布式數(shù)據(jù)管理系統(tǒng)

2 氣象數(shù)據(jù)特征分析

氣象數(shù)據(jù)中最重要的是模式數(shù)據(jù)，大約70%的氣象數(shù)據(jù)為模式數(shù)據(jù)［29-30］，而且模式數(shù)據(jù)不斷更新。天氣預(yù)報等氣象業(yè)務(wù)中，預(yù)報員也需要對模式數(shù)據(jù)頻繁地進行查詢。模式數(shù)據(jù)是根據(jù)大量氣象傳感器采集的天氣狀態(tài)信息，由高性能計算機計算出的地球表面不同海拔上每個經(jīng)緯度空間點上的多個物理量（如溫度、濕度、風速等）在未來一段時間內(nèi)的預(yù)測值（例如3 h、6 h、9 h、24 h、72 h 等）。由于計算和存儲能力有限，也因為空間上相鄰區(qū)域的天氣狀況非常接近，因此一般每個海拔高度上經(jīng)緯度空間的精度一般為幾千米范圍，這個空間范圍在計算時會被抽象為一個“格點”。如果模式數(shù)據(jù)的每條記錄對應(yīng)一個格點，那么模式數(shù)據(jù)中這個格點的屬性值非常多，經(jīng)常達到幾萬個甚至更多，一般包括1000個左右的物理量以及每個物理量未來幾個時間段的預(yù)測值，而且一般會同時根據(jù)不同的算法計算多套模式數(shù)據(jù)，如表1所示。

表1 氣象模式數(shù)據(jù)示意圖

2.1 模式數(shù)據(jù)的更新

模式數(shù)據(jù)在不斷進行更新，高性能計算機根據(jù)最新采集的天氣狀況，不斷重新計算，并更新氣象數(shù)據(jù)管理系統(tǒng)中的模式數(shù)據(jù)，以提升天氣預(yù)報的準確度。隨著高性能計算機計算能力的不斷提升，模式數(shù)據(jù)更新的頻率不斷提升，天氣預(yù)報的準確度也在不斷提高。

2.2 模式數(shù)據(jù)的查詢

預(yù)報員對模式數(shù)據(jù)的查詢類型非常多樣，例如查詢一個經(jīng)緯度平面的格點數(shù)據(jù)（比如查詢某個省未來3 h 的地表氣溫）、查詢某個格點的時間序列數(shù)據(jù)（例如查詢某地未來一段時間的濕度變化）、查詢某個格點的不同物理量、查詢某個格點不同模式計算產(chǎn)生的數(shù)據(jù)用于比較等。因此，模式數(shù)據(jù)的查詢呈現(xiàn)以下2個特點：

1）每次查詢經(jīng)常是查詢格點數(shù)據(jù)的一小部分列，例如只查詢未來某個時段的溫度，可能涉及一個列，或者幾個列。而且不同類型的查詢，關(guān)注不同的列。

2）點查詢和范圍查詢并存，可能只關(guān)注一個格點的數(shù)據(jù)，也可能關(guān)注一定空間范圍的數(shù)據(jù)，例如一個省，甚至全國的數(shù)據(jù)。

2.3 模式數(shù)據(jù)管理的挑戰(zhàn)

模式數(shù)據(jù)的管理屬于典型的HTAP 應(yīng)用，模式數(shù)據(jù)一邊在更新，一邊在進行查詢。目前已有的數(shù)據(jù)管理系統(tǒng)，很難在讀寫2個方面都做好。

3 面向混合負載的分布式氣象數(shù)據(jù)管理系統(tǒng)設(shè)計

本文在目前主流的類Spanner分布式數(shù)據(jù)庫系統(tǒng)的基礎(chǔ)上，充分利用存儲層多個副本的特點，部署不同的副本形態(tài)，從而可以應(yīng)對混合負載中不同應(yīng)用的需求。例如有的副本更適合氣象數(shù)據(jù)的插入、更新操作，有些副本更適合氣象業(yè)務(wù)的數(shù)據(jù)查詢，從而提升混合負載下氣象數(shù)據(jù)系統(tǒng)的整體性能。

3.1 系統(tǒng)架構(gòu)

本文設(shè)計的面向混合負載的分布式氣象數(shù)據(jù)管理系統(tǒng)應(yīng)對HTAP 需求的關(guān)鍵是在多個存儲副本采用不同的存儲模式。一部分副本更適合數(shù)據(jù)的寫入、更新，以及對一個數(shù)據(jù)項的大量屬性的訪問；而另一部分副本更適合對某個屬性或某幾個屬性的查詢，可以避免很多無關(guān)氣象數(shù)據(jù)的讀取，尤其是對于氣象模式數(shù)據(jù)這樣屬性非常多的情況來說。

如圖2 所示，為了支持異構(gòu)數(shù)據(jù)副本機制，分布式氣象數(shù)據(jù)管理系統(tǒng)的大部分層次都需要做專門的調(diào)整：

1）單機存儲引擎層：副本的具體存儲模式包括2種不同的氣象數(shù)據(jù)存儲模式，具體實現(xiàn)將在3.2 節(jié)中詳細介紹。

2）分布式共識層：主要的區(qū)別是在異構(gòu)副本下，所有的副本都需要支持讀取。傳統(tǒng)Raft 協(xié)議的實現(xiàn)多數(shù)支持領(lǐng)導者副本的讀取，追隨者副本只是提供冗余，提高系統(tǒng)可靠性；但Raft 協(xié)議的設(shè)計實際是支持追隨者副本讀取的［11］，本文系統(tǒng)采用標準Raft 的追隨者副本讀取設(shè)計。

3）SQL 引擎層：需要增加訪問路由策略模塊，每次對氣象數(shù)據(jù)的訪問都可能有多個副本的多個選擇，因此需要選擇最適合的副本進行訪問。具體的策略將在3.3節(jié)詳細闡述。

4）元數(shù)據(jù)管理：需要額外記錄每個副本采用的氣象數(shù)據(jù)存儲模式，以便SQL引擎進行訪問路由決策。

3.2 氣象異構(gòu)存儲方案

氣象模式數(shù)據(jù)的每條記錄對應(yīng)一個格點的屬性信息，傳統(tǒng)模式一般用一個氣象格點的所有屬性作為數(shù)據(jù)庫的一條記錄，即以格點為中心的存儲模式（簡寫為格點存儲模式）。但是如前文所述，每個格點的屬性可以達到上萬個甚至更多，包括多種氣象模式計算出的約1000 個物理量，每個物理量還有多個未來時段的預(yù)測值。因此如果氣象查詢只涉及氣象格點其中一個屬性或少數(shù)一些屬性，那么傳統(tǒng)的格點存儲模式（如圖3（a）所示，每個格點的所有屬性聚集在一起存儲，在單機存儲引擎上表現(xiàn)為一個鍵值對），訪問時絕大部分數(shù)據(jù)都是無效數(shù)據(jù)，因此實際的數(shù)據(jù)訪問吞吐會非常差。

圖3 格點存儲模式和屬性存儲模式對比

如果縮小記錄的粒度，以單個格點的單個屬性或少數(shù)屬性構(gòu)成的屬性組作為一條記錄，即以屬性為中心的存儲模式（簡寫為屬性存儲模式），那么可以顯著減少氣象業(yè)務(wù)查詢時對無效屬性數(shù)據(jù)的訪問，從而可以顯著提升氣象查詢的性能。具體如圖3（b）所示，每個格點的屬性可以分為多個組，每組包括一個或多個屬性，每組用一個鍵值對來存儲。屬性存儲模式的優(yōu)點是在應(yīng)對單個屬性或少量屬性的大范圍查詢時，可以有效提升讀取數(shù)據(jù)的有效率，避免I/O 浪費。但是如圖3（b）所示，其缺點是鍵中除了格點坐標外，還需要包括屬性組的ID 信息，因此長度有所增加，會消耗更多存儲空間。此外，屬性存儲模式下鍵值對的數(shù)量會顯著增加，CPU計算和處理的開銷會增加。不過對于屬性特別多的氣象模式數(shù)據(jù)來說，屬性存儲模式對很多氣象業(yè)務(wù)的查詢性能提升效果會比較顯著。具體屬性組的大小、屬性的聚集，需要根據(jù)氣象應(yīng)用的查詢特征來設(shè)置，以達到最優(yōu)化的效果。

3.3 查詢路由策略

當存儲層有格點、屬性2 種類型的多個副本可供選擇時，SQL引擎層需要通過一定的查詢路由策略來決定訪問哪個副本。本文系統(tǒng)中，查詢路由策略主要采用啟發(fā)式規(guī)則方式，按照優(yōu)先級從高到低，采用以下3類規(guī)則來決定路由選擇：

1）由于氣象業(yè)務(wù)中預(yù)報員對模式數(shù)據(jù)的查詢比較多樣化，但整體來說，一般分為2 大類：一類是對某個格點的多個屬性的查詢，例如對某個地點的時間序列查詢，或多個物理量的查詢，或者多個氣象模式的比對，這種情況比較適合訪問格點存儲模式副本，可以保障一次鍵值對訪問能獲得所有需要的數(shù)據(jù)。第二類是對少量屬性的大范圍空間查詢，例如對一個地區(qū)（如一個省、一個市）某個海拔的溫度、濕度查詢，這時比較適合訪問屬性存儲模式副本，以減少無關(guān)屬性的訪問。

2）事務(wù)分為讀寫事務(wù)、純寫事務(wù)、純讀事務(wù)3 類。由于在Raft 協(xié)議中，只有領(lǐng)導者副本能夠處理寫請求，而所有副本都可以處理讀請求，因此讀寫事務(wù)和純寫事務(wù)一定會路由到領(lǐng)導者副本，純讀事務(wù)可能路由到所有副本，具體將通過以下2 條規(guī)則確定。值得注意的是，為了更好地處理寫請求，領(lǐng)導者副本一般都默認設(shè)置為格點存儲模式副本；但是當原有的領(lǐng)導者副本所在節(jié)點崩潰，其余副本均為屬性存儲模式副本時，只能由屬性存儲模式副本當選領(lǐng)導者，這時屬性存儲模式副本仍然可以處理寫情況，只是寫入性能相較于格點存儲模式副本會低一些。

3）此外也需要考慮到各個副本所在節(jié)點的負載情況。如果系統(tǒng)中出現(xiàn)熱點，某個目標副本所在節(jié)點的整體負載超過閾值，則會訪問其他負載較低的副本，從而減少請求排隊時間，提升系統(tǒng)整體的負載均衡程度和整體性。

4 實驗結(jié)果與分析

本文的分布式氣象數(shù)據(jù)管理系統(tǒng)主要由元數(shù)據(jù)管理、SQL引擎、分布式事務(wù)、分布式共識和單機鍵值存儲引擎等部分組成。其中單機鍵值存儲引擎采用目前主流的LSM-Tree 架構(gòu)［31］，在訪問性能和存儲空間效率方面都具有明顯優(yōu)勢。分布式共識協(xié)議采用Raft協(xié)議［25］，分布式事務(wù)采用主流的2PC協(xié)議。

在實驗測評中，系統(tǒng)部署于8 個物理節(jié)點上，每個節(jié)點包括2 個Intel 4208 CPU、64 GB 內(nèi)存和2 塊1 TB 的固態(tài)硬盤。實驗數(shù)據(jù)采用典型的氣象模式數(shù)據(jù)，一方面在不斷更新模式數(shù)據(jù)，通過系統(tǒng)每秒進行的數(shù)據(jù)更新事務(wù)數(shù)目來量化性能；另一方面在多線程進行模式數(shù)據(jù)的典型查詢，通過查詢的平均延遲來反映性能。實驗過程中，讀寫線程數(shù)量一樣。本文提出的異構(gòu)氣象存儲模式將與傳統(tǒng)的格點存儲模式進行性能比較。

當氣象業(yè)務(wù)訪問線程數(shù)量從4 增長到128 時，系統(tǒng)寫入性能如圖4 所示，系統(tǒng)查詢性能如圖5 所示。由圖中的實驗結(jié)果可以看出，本文提出的異構(gòu)氣象存儲模式相對于TiDB 等分布式數(shù)據(jù)庫系統(tǒng)中普遍采用的傳統(tǒng)存儲模式，在寫入性能上略有下降，但是在查詢性能方面有顯著的提升，特別是在高并發(fā)的情況下。

圖4 系統(tǒng)并行寫入性能

圖5 系統(tǒng)并行查詢性能

寫性能下降的主要原因是異構(gòu)氣象存儲模式的多副本混合采用格點存儲模式和屬性存儲模式，其中屬性存儲模式中鍵的長度增加，占用更多存儲空間，寫入負載下實際寫入系統(tǒng)的數(shù)據(jù)規(guī)模更大，而且鍵值對數(shù)量增加，需要更多CPU 處理。因此寫入的平均速度略有下降；不過下降幅度并不大，平均下降2.19%。

如圖5 所示，異構(gòu)氣象存儲模式的讀性能提升的幅度非常大，查詢性能平均提升3.13倍。主要原因是本文系統(tǒng)的列存儲模式在處理少量屬性的范圍查詢時效率非常高，讀取的無效數(shù)據(jù)很少，而且負載均衡程度更高，在高并發(fā)、高負載的情況下效果更為顯著。

5 結(jié)束語

作為典型的科學大數(shù)據(jù)，氣象數(shù)據(jù)規(guī)模大、增長快、數(shù)據(jù)類型和查詢多樣化，而且價值大，尤其是符合HTAP 應(yīng)用特征，對數(shù)據(jù)更新和數(shù)據(jù)查詢要求都非常高，因此迫切需要能夠高效支持HTAP 的新型分布式數(shù)據(jù)管理系統(tǒng)來支撐。本文設(shè)計和實現(xiàn)了一套面向混合負載的氣象數(shù)據(jù)管理系統(tǒng)，通過存儲層格點存儲模式、屬性存儲模式的異構(gòu)設(shè)計，以及SQL 引擎層的智能查詢路由，可以同時高效地滿足氣象模式數(shù)據(jù)的并行更新和查詢。相對于傳統(tǒng)模式，可以在高寫入性能的前提下，將氣象的復雜查詢的性能提升3.13倍。

讀寫混合負載的特征在氣象應(yīng)用中越來越普遍，HTAP氣象數(shù)據(jù)管理系統(tǒng)具有很好的發(fā)展前景。本文方法為了顯著提升查詢性能，對寫入性能有少量的犧牲。未來將進一步研究可調(diào)節(jié)的HTAP方法，在讀、寫性能之間進行調(diào)節(jié)，精確滿足具體氣象應(yīng)用的需求。