雷 鳴

(天津市氣象信息中心 天津 300074)

0 引 言

隨著氣象業(yè)務(wù)高速擴(kuò)展，數(shù)據(jù)的種類與數(shù)據(jù)量不斷增長。而與此同時(shí)，針對氣象數(shù)據(jù)的服務(wù)性能和響應(yīng)速度的要求卻越來越高。但目前省級(jí)全國綜合氣象信息共享系統(tǒng)(CIMISS)，卻是2009年由國家氣象信息中心負(fù)責(zé)組織建設(shè)，集數(shù)據(jù)收集、分發(fā)、處理、存儲(chǔ)和共享于一體。2013年，該系統(tǒng)推廣部署在全國各省級(jí)氣象數(shù)據(jù)中心，并獲得良好應(yīng)用。但隨著設(shè)備老化和技術(shù)的落后，目前其數(shù)據(jù)處理能力已經(jīng)明顯無法滿足要求[1-3]。但省級(jí)部門卻無權(quán)針對該系統(tǒng)進(jìn)行改造。

為了進(jìn)一步提升氣象數(shù)據(jù)服務(wù)的敏捷性和存儲(chǔ)動(dòng)態(tài)擴(kuò)展的需求。同時(shí)又能夠與CIMISS進(jìn)行無縫銜接，在充分參考相關(guān)行業(yè)在解決海量數(shù)據(jù)查詢的成功方案基礎(chǔ)上[4-8]，利用分布式技術(shù)[9-11]，構(gòu)建滿足省級(jí)特色需求的數(shù)據(jù)服務(wù)中心。同時(shí)，利用CIMISS的氣象數(shù)據(jù)統(tǒng)一服務(wù)MUSIC接口(Meteorological Unified Service Interface Community)[12-14]，打通多系統(tǒng)之間的壁壘，屏蔽異構(gòu)環(huán)境，提供統(tǒng)一的對外數(shù)據(jù)服務(wù)功能。

1 系統(tǒng)架構(gòu)設(shè)計(jì)

通過引入系統(tǒng)面向的四類用戶，結(jié)合整個(gè)平臺(tái)進(jìn)行管理和監(jiān)控運(yùn)行監(jiān)管體系和平臺(tái)建設(shè)，并遵循氣象信息標(biāo)準(zhǔn)化體系規(guī)范，針對系統(tǒng)的六個(gè)層次分別進(jìn)行了細(xì)化與分析，其具體技術(shù)架構(gòu)如圖1所示。

圖1 系統(tǒng)總體框架設(shè)計(jì)

天津省級(jí)數(shù)據(jù)服務(wù)中心的總體設(shè)計(jì)機(jī)構(gòu)共分為5層：展現(xiàn)交互層、應(yīng)用功能層、數(shù)據(jù)存儲(chǔ)層、基礎(chǔ)支撐層與硬件層。

展現(xiàn)交互層：該層是天津氣象大數(shù)據(jù)共享平臺(tái)軟件進(jìn)行交互的入口，該層主要負(fù)責(zé)接收用戶提交的輸入請求，通過后端的接口層對業(yè)務(wù)邏輯層進(jìn)行訪問，從而獲得、并向用戶輸出可視化響應(yīng)。

應(yīng)用功能層：應(yīng)用功能層則負(fù)責(zé)接收前端用戶的輸入請求，并以業(yè)務(wù)邏輯過程能夠理解的方式將其轉(zhuǎn)化。同時(shí)，根據(jù)特定的業(yè)務(wù)邏輯向數(shù)據(jù)層有序地發(fā)送數(shù)據(jù)請求，并將返回的數(shù)據(jù)層數(shù)據(jù)進(jìn)行解釋和組合，形成用戶所需的信息，最終再返回到展現(xiàn)交互層。這一層在整個(gè)應(yīng)用軟件系統(tǒng)里，是業(yè)務(wù)邏輯處理與實(shí)現(xiàn)的核心。

應(yīng)用功能層采用基于組件化架構(gòu)思想進(jìn)行設(shè)計(jì)，即將天津氣象大數(shù)據(jù)共享平臺(tái)軟件的業(yè)務(wù)功能單元封裝成各個(gè)相對獨(dú)立又互相聯(lián)系的功能組件，通過支撐層的調(diào)度控制，各功能組件相互配合，協(xié)作完成系統(tǒng)的各項(xiàng)任務(wù)。

數(shù)據(jù)存儲(chǔ)層：該層針對氣象數(shù)據(jù)進(jìn)行管理，并向應(yīng)用服務(wù)層提供開放式訪問的標(biāo)準(zhǔn)化接口。該層負(fù)責(zé)提供訪問位于持久化容器中數(shù)據(jù)的功能，以及涉及從持久化介質(zhì)中寫入數(shù)據(jù)或者讀取數(shù)據(jù)的工作。

基于HBase存儲(chǔ)半結(jié)構(gòu)化混合數(shù)據(jù)，基于MySQL存儲(chǔ)結(jié)構(gòu)化觀測和預(yù)報(bào)資料，基于MongoDB存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)存儲(chǔ)層為系統(tǒng)提供對緩存進(jìn)行管理的功能，在此基礎(chǔ)上，分別對數(shù)據(jù)庫和文件庫的進(jìn)行統(tǒng)一的接口封裝，為應(yīng)用功能層提供統(tǒng)一基于時(shí)間索引、空間索引和要素索引的大數(shù)據(jù)SQL查詢器。

天津氣象大數(shù)據(jù)共享平臺(tái)軟件為加快上層訪問數(shù)據(jù)存儲(chǔ)層數(shù)據(jù)/文件的訪問速度，在數(shù)據(jù)庫與文件庫物理存儲(chǔ)基礎(chǔ)上使用緩存機(jī)制。

支撐層：支撐層描述了實(shí)現(xiàn)天津氣象大數(shù)據(jù)共享平臺(tái)軟件所使用的技術(shù)框架和所采用的關(guān)鍵技術(shù)，為應(yīng)用功能層各個(gè)業(yè)務(wù)組件、功能模塊起到支撐與組織的作用。支持層包括兩部分：系統(tǒng)級(jí)技術(shù)框架及關(guān)鍵技術(shù)。

系統(tǒng)級(jí)技術(shù)框架描述支撐整個(gè)系統(tǒng)應(yīng)用功能所使用技術(shù)架構(gòu)，主要包括：展示交互技術(shù)框架、自動(dòng)運(yùn)行技術(shù)框架、地理信息技術(shù)框架、OSGI插件微內(nèi)核技術(shù)框架、負(fù)載均衡與分布式計(jì)算框架和數(shù)據(jù)存儲(chǔ)技術(shù)框架。

關(guān)鍵技術(shù)指構(gòu)建系統(tǒng)級(jí)技術(shù)框架中所采用的技術(shù)，主要包括本地客觀預(yù)報(bào)產(chǎn)品生成技術(shù)、網(wǎng)絡(luò)協(xié)同技術(shù)等。

2 可擴(kuò)展性設(shè)計(jì)決策

為更好適應(yīng)未來氣象預(yù)報(bào)業(yè)務(wù)發(fā)展，系統(tǒng)需具有可擴(kuò)展性與開放性。可擴(kuò)展性具體表現(xiàn)為業(yè)務(wù)可擴(kuò)展性，可動(dòng)態(tài)加載氣象預(yù)報(bào)業(yè)務(wù)算法。

對業(yè)務(wù)擴(kuò)展性需求，采用的設(shè)計(jì)決策是：將具體的算法封裝成動(dòng)態(tài)鏈接庫，與具體的業(yè)務(wù)邏輯相分離，算法可替換，參數(shù)可配置，業(yè)務(wù)流程可配置。業(yè)務(wù)流程配置如圖2所示。

圖2 業(yè)務(wù)流程配置示意說明

針對系統(tǒng)的擴(kuò)展性需求，采用設(shè)計(jì)決策是：業(yè)務(wù)邏輯及公共服務(wù)層與展示層之間功能分離，模塊之間松耦合，分別部署在不同的物理節(jié)點(diǎn)，可重用業(yè)務(wù)邏輯及公共服務(wù)層。

3 系統(tǒng)存儲(chǔ)設(shè)計(jì)

3.1 系統(tǒng)存儲(chǔ)架構(gòu)設(shè)計(jì)

為了做到數(shù)據(jù)與應(yīng)用分離，使用戶對后臺(tái)變動(dòng)無感?；贛USIC服務(wù)接口，將全部數(shù)據(jù)庫打通，形成一個(gè)邏輯上統(tǒng)一的數(shù)據(jù)服務(wù)中心，對外透過API接口提供服務(wù)。整個(gè)存儲(chǔ)設(shè)計(jì)架構(gòu)如圖3所示。

圖3 系統(tǒng)存儲(chǔ)架構(gòu)設(shè)計(jì)圖

3.2 數(shù)據(jù)庫存儲(chǔ)配置

系統(tǒng)涉及到多種數(shù)據(jù)庫，如MySQL、MongeDB、HBase等。為進(jìn)一步提升系統(tǒng)響應(yīng)速度，特別針對各數(shù)據(jù)庫分別進(jìn)行了優(yōu)化處理。限于篇幅，僅以MySQL優(yōu)化為例：

MySQL提供了一些存儲(chǔ)分配參數(shù)，例如：數(shù)據(jù)庫的大小、鎖的數(shù)目，以及使用的緩沖區(qū)大小等。但這些分配參數(shù)的默認(rèn)值不能達(dá)到天津省級(jí)數(shù)據(jù)服務(wù)中心的功能需求。為進(jìn)一步優(yōu)化數(shù)據(jù)庫性能，根據(jù)天津省級(jí)數(shù)據(jù)服務(wù)中心的特點(diǎn)，針對系統(tǒng)的配置參數(shù)進(jìn)行了如下調(diào)整：

[mysqld]

server-id=115

basedir=/mysqldata

datadir=/mysqldata/data

log-bin=mysql-bin

log-bin-index=mysql-bin.index

sync-binlog=1

max-binlog-size=200M

expire_logs_day=3

skip-host-cache

skip-name-resolve

innodb_buffer_pool_size=40G

innodb_log_buffer_size=32M

max_connections=1000

event_scheduler=ON

4 并行加速算法

為了進(jìn)一步提升數(shù)據(jù)服務(wù)的速度，尤其是涉及到圖形渲染等高密度計(jì)算場景時(shí)，本文利用并行計(jì)算技術(shù)進(jìn)行數(shù)據(jù)顯示增速[15]，如：針對格點(diǎn)數(shù)據(jù)等值線提取、色斑渲染等功能。天津省級(jí)數(shù)據(jù)服務(wù)中心所使用的WebGIS以及其他需要渲染計(jì)算等方面，均采用了并行運(yùn)算。其具體策略為：結(jié)合OpenMP的CPU并行計(jì)算以及基于OpenCL的GPU并行計(jì)算技術(shù)，將其應(yīng)用與氣象格點(diǎn)數(shù)據(jù)計(jì)算處理和氣象信息圖形顯示分析中，提高基于WeBGL地圖渲染的執(zhí)行效率和運(yùn)算速度。

4.1 基于OpenMP的CPU并行算法

CPU并行框架底層基于OpenMP編程框架，透過使用計(jì)算機(jī)的多線程多核處理機(jī)制，提供了對CPU并行算法的高層抽象描述，以及線程粒度的控制和負(fù)載均衡，具體工作流程如圖4所示。

圖4 并行計(jì)算工作流程示意圖

OpenMP的算法設(shè)計(jì)基于如下阿姆達(dá)爾定律的最小化串行代碼原則進(jìn)行：

(1)

式中：a是并行計(jì)算部分占用的比例大小，n則是并行處理部分的結(jié)點(diǎn)個(gè)數(shù)，即處理器個(gè)數(shù)?？梢钥吹?，當(dāng)沒有串行，而僅有并行，即1-a=0時(shí)，最大加速比S=n；而當(dāng)僅有串行，并不存在并行，即a=0時(shí)，其最小加速比S=1；最大加速比的上限發(fā)生在n→∞時(shí)，此時(shí)，極限加速比S→1/(1-a)。為了使速度最大化，在并行處理節(jié)點(diǎn)個(gè)數(shù)固定的情況下，應(yīng)盡可能地提升并行計(jì)算部分所占的比例。

OpenMP中的執(zhí)行模型采用的是fork-join，其中，fork的含義表示喚醒已有線程或者創(chuàng)建線程，而join則代表了多線程的會(huì)合。當(dāng)Fork-join執(zhí)行模型最初執(zhí)行時(shí)，它僅有一個(gè)在運(yùn)行的線程：即“主線程”(Master Thread)。而當(dāng)需進(jìn)行并行計(jì)算時(shí)，系統(tǒng)則會(huì)由主線程派生出新線程來執(zhí)行并行任務(wù)。而此時(shí)，主線程與派生線程將會(huì)在并行執(zhí)行階段一同協(xié)同工作。當(dāng)并行運(yùn)算完結(jié)之后，派生線程會(huì)自動(dòng)阻塞或退出，而不再繼續(xù)執(zhí)行，控制流程將會(huì)回到單獨(dú)的主線程中。當(dāng)系統(tǒng)涉及高密度數(shù)據(jù)計(jì)算的時(shí)候，如：數(shù)據(jù)渲染和數(shù)據(jù)時(shí)間插值等操作，計(jì)算將會(huì)由CPU轉(zhuǎn)到GPU中進(jìn)行處理。

4.2 基于OpenCL的GPU并行算法

GPU并行計(jì)算基于開放運(yùn)算語言(Open Computing Language，OpenCL)，利用GPU強(qiáng)大的浮點(diǎn)數(shù)計(jì)算能力，輔助CPU完成大規(guī)模的并行計(jì)算任務(wù)。OpenCL可運(yùn)行在多種不同的平臺(tái)之上(Windows、Linux、Unix等)，通過對不同平臺(tái)底層的抽象與封裝，屏蔽了相異平臺(tái)底層的不同設(shè)計(jì)，并對應(yīng)用層提供了統(tǒng)一的接口服務(wù)。

而GPU渲染常采用構(gòu)建三角形帶和LOD(多細(xì)節(jié)層次)技術(shù)[16]以減少GPU固有的渲染數(shù)據(jù)量，則其渲染的數(shù)據(jù)量公式如下：

(2)

式中：m則是場景模型的總數(shù)；ky是Ny縮減的比例；Ny則是單個(gè)模型在場景中的總頂點(diǎn)數(shù)；x是反射次數(shù)；kb是在并行架構(gòu)下頂點(diǎn)的冗余度系數(shù)(在2-3之間)；kf是材質(zhì)種類所固有的反射系數(shù)；I是平均光強(qiáng)值；n是場景光源的個(gè)數(shù)。

設(shè)ty為同一線程塊處理面片集合的平均時(shí)間，Ab為同一批次處理的渲染數(shù)據(jù)量，T為處理渲染數(shù)據(jù)消耗的總時(shí)間，則有：

(3)

整體OpenCL并行計(jì)算框架的架構(gòu)設(shè)計(jì)由設(shè)備、上下文環(huán)境、程序、內(nèi)核、內(nèi)存對象、命令隊(duì)列六個(gè)部分組成，具體組成如圖5所示。

圖5 并行計(jì)算系統(tǒng)流程圖

設(shè)備：它是并行計(jì)算框架中的計(jì)算單元，一個(gè)GPU或者CPU將會(huì)對應(yīng)一個(gè)設(shè)備。而設(shè)備通過命令隊(duì)列，獲取自己需要執(zhí)行的計(jì)算指令。

上下文環(huán)境：上下文是一個(gè)抽象的容器，是整個(gè)并行計(jì)算框架的紐帶，上下文環(huán)境管理在設(shè)備上的列中的有序隊(duì)列與無序隊(duì)列。只有在一個(gè)上下文環(huán)境上的系統(tǒng)的設(shè)備才能彼此交流工作。

程序：這是所有代碼的集合，包含核函數(shù)和其他庫。OpenCl是一個(gè)動(dòng)態(tài)編譯的語言，代碼編譯后生成一個(gè)中間文件(可根據(jù)需要實(shí)現(xiàn)為虛擬機(jī)代碼或者匯編代碼)，在使用時(shí)連接進(jìn)入程序讀入處理器。

內(nèi)核：這是在設(shè)備上運(yùn)行的核函數(shù)及其參數(shù)組。為了進(jìn)一步提升計(jì)算速度，在其中特別使用了單指令多數(shù)據(jù)流技術(shù)。這是一種采用一個(gè)控制器來控制多個(gè)處理器，同時(shí)對一組數(shù)據(jù)(又稱“數(shù)據(jù)矢量”)里面的每一個(gè)各自進(jìn)行相同操作，從而達(dá)到空間上并行性的技術(shù)。

內(nèi)存對象：包括圖像和緩沖區(qū)，并行計(jì)算需要在不同設(shè)備上使用的內(nèi)存，內(nèi)存對象由上下文創(chuàng)建，從而實(shí)現(xiàn)上下文管理的多個(gè)設(shè)備，能夠?qū)?nèi)存對象中的數(shù)據(jù)進(jìn)行共享。

命令隊(duì)列：這是上下文環(huán)境給每個(gè)設(shè)備提交的指令序列，通過命令隊(duì)列，上下文環(huán)境將需要執(zhí)行的指令，發(fā)送到每個(gè)設(shè)備上。在順序執(zhí)行命令隊(duì)列里(默認(rèn))，命令將會(huì)按照接收的順序壓入到命令隊(duì)列中。亂序隊(duì)列允許OpenCL在實(shí)現(xiàn)時(shí)重排命令以便高效地執(zhí)行。如果使用亂序隊(duì)列，須指定依賴關(guān)系以確保正確地執(zhí)行順序。

OpenCl執(zhí)行分為三個(gè)階段，第一個(gè)階段進(jìn)行代碼編譯，創(chuàng)建上下文環(huán)境以及命令隊(duì)列，生成內(nèi)核與程序，并完成設(shè)備的初始化；第二個(gè)階段創(chuàng)建參數(shù)和數(shù)據(jù)，上下文環(huán)境創(chuàng)建內(nèi)存對象，并將計(jì)算需要使用的數(shù)據(jù)寫入其中；第三個(gè)階段上下文環(huán)境將需要執(zhí)行的計(jì)算指令發(fā)送到命令隊(duì)列中，并等待設(shè)備計(jì)算完成。設(shè)備計(jì)算完成之后，上下文環(huán)境讀取內(nèi)核對象處理的結(jié)果(存放在內(nèi)存對象中)，并釋放資源。

5 實(shí)踐與測試

為大數(shù)據(jù)分布式存儲(chǔ)數(shù)據(jù)中心的數(shù)據(jù)服務(wù)能力，特別對其進(jìn)行了綜合測試。測試使用的硬件配置為：CPU i5- 3470 3.20 GHz，內(nèi)存4 GB，支持谷歌內(nèi)核的主流瀏覽器，如Chrome。獲得的系統(tǒng)測試指標(biāo)如表1、表2所示。

表1 基于WebGIS的自動(dòng)站顯示指標(biāo)

表2 基于WebGIS的數(shù)據(jù)渲染顯示指標(biāo)

為了進(jìn)一步獲得系統(tǒng)的查詢性能，特別針對頁面響應(yīng)速度進(jìn)行了測試，獲得如表3所示的各項(xiàng)數(shù)據(jù)查詢結(jié)果。

表3 頁面查詢響應(yīng)速度表

其中，查詢類型為常規(guī)產(chǎn)品中的典型查詢項(xiàng)目，而響應(yīng)時(shí)間中的顯示則為第1次的顯示耗時(shí)。頁面的響應(yīng)速度比基于CIMISS的速度平均提升了860%。下面展示了幾類不同的查詢顯示效果圖。

圖6 自動(dòng)站實(shí)況溫度查詢效果圖

圖7 EC集合統(tǒng)計(jì)量：24小時(shí)降水

6 結(jié) 語

本文在不改變現(xiàn)有業(yè)務(wù)系統(tǒng)和系統(tǒng)架構(gòu)的基礎(chǔ)上，基于MUSIC接口，利用分布式和并行計(jì)算技術(shù)構(gòu)建了滿足省局氣象需求的大數(shù)據(jù)環(huán)境中心，提高了氣象數(shù)據(jù)顯示分析過程中各種復(fù)雜的氣象算法運(yùn)算的效率，并對系統(tǒng)中整個(gè)業(yè)務(wù)流程執(zhí)行效率和圖形顯示分析的人機(jī)交互體驗(yàn)也有較大的提升，為氣象數(shù)據(jù)的高質(zhì)量服務(wù)，提供了一個(gè)可行的解決方案。