一體化數(shù)據(jù)訪問服務關鍵技術

孫周軍，郭 捷，李高潔，喬文文，何文春

(1.廣東省氣象探測數(shù)據(jù)中心 數(shù)據(jù)共享科，廣東 廣州 510080；2.廣東省氣象公共服務中心，廣東 廣州 510080；3.國家氣象信息中心 系統(tǒng)工程室，北京 100081)

0 引 言

氣象行業(yè)主要采用傳統(tǒng)關系型數(shù)據(jù)庫、集中式文件存儲系統(tǒng)和磁帶庫對數(shù)據(jù)進行分級管理，在對歷史天氣進行研究過程中無法及時、便捷地使用完整時間序列的科研資料[1-3]；業(yè)務系統(tǒng)對數(shù)據(jù)的調用多為直接訪問數(shù)據(jù)源，與存儲系統(tǒng)高度耦合度，存儲系統(tǒng)的技術更新給業(yè)務應用的適配造成很大障礙；傳統(tǒng)的存儲策略和供給方式無法最大限度發(fā)揮訪問效率與并發(fā)供給能力；數(shù)據(jù)資源分散存儲和發(fā)布，沒有集中統(tǒng)一的資料發(fā)布途徑，科研人員無法獲悉資料用法，管理與應用脫節(jié)嚴重。對海量數(shù)據(jù)的集中治理和高效服務已經(jīng)是制約氣象業(yè)務高質量發(fā)展的關鍵問題。

本文提出一體化數(shù)據(jù)訪問服務方法(integrated database for easy access，IDEA)，基于數(shù)據(jù)存儲與應用系統(tǒng)間的中間層，作為異構數(shù)據(jù)系統(tǒng)與應用系統(tǒng)之間的適配器，消除數(shù)據(jù)存儲與應用間的強依賴關系；集中多源地球科學數(shù)據(jù)管理，統(tǒng)一多種異構數(shù)據(jù)格式，融合實時與歷史數(shù)據(jù)形成數(shù)據(jù)完整序列；利用服務總線和服務化技術，向氣象行業(yè)及時集中發(fā)布數(shù)據(jù)資源，打通地球科學數(shù)據(jù)管理與科研應用的信息通道，提升了科學數(shù)據(jù)的管理和應用效能。

1 業(yè)務現(xiàn)狀

(1)地域范圍廣：氣象學研究的是大氣圈內各層大氣的運動規(guī)律，涉及到地球多圈層，且大氣圈與星際太空并無明顯分界。只要是科研需要，且觀測手段能夠達到的地方，幾乎均采用立體觀測平臺，多手段測量獲取相關數(shù)據(jù)。我國除過擁有涵蓋本土的觀測數(shù)據(jù)外，在WMO組織框架下，也有共享收集到全球部分觀測、預報預測產(chǎn)品等數(shù)據(jù)。

(2)時空密度大：目前，全國已經(jīng)建成5萬多地面氣象觀測站，觀測頻率達每分鐘每次，160多部多普勒天氣雷達，觀測頻次達到6分鐘每次；80多探空觀測站，觀測頻率達秒級每次；8顆氣象衛(wèi)星，靜止衛(wèi)星觀測頻率達到6分鐘每次；閃電定位、GPS/MET、負氧離子、大氣成分等觀測已遍布全國，觀測設備的布設密度大，觀測頻次也大幅提升。

(3)數(shù)據(jù)種類多：氣象業(yè)務和科研活動中涉及到氣象領域本身和社會多行業(yè)的相關數(shù)據(jù)。氣象領域以觀測平臺分類有天基、空基和地基觀測資料等，包括衛(wèi)星遙感、雷達、高空、海洋、輻射、農氣、地面常規(guī)觀測等資料，以及由業(yè)務系統(tǒng)或科研產(chǎn)生的預報、預警、服務產(chǎn)品、實驗數(shù)據(jù)等；社會多行業(yè)的數(shù)據(jù)包括水利、農業(yè)、旅游、交通、漁業(yè)、航空、環(huán)保等專業(yè)數(shù)據(jù)，以及互聯(lián)網(wǎng)相關數(shù)據(jù)。按照格式分類，包括文本、圖片、視頻、柵格等。

(4)高時效性：氣象數(shù)據(jù)在不同的業(yè)務場景及時的被獲取和應用，才能充分的發(fā)揮其價值，高時效性是氣象資料的基本特征之一。天氣預報、氣候預測、防災減災和公眾服務是氣象業(yè)務活動的重要內容，臨近預報在0-2小時內有效，短時預報在0-12小時有效，短期預報在隨后1-3天有效等；數(shù)值天氣預報也一直努力在更短時間內計算出范圍更廣、時間更長的預報，氣象觀測數(shù)據(jù)作為其參數(shù)輸入，對其采集頻次和傳輸時效要求達到秒級。

(5)一致性要求高：氣象部門按照分級結構劃分為觀測臺站、地市、省和國家氣象局，所從事的業(yè)務和科研活動內容非常相似。各級氣象局在進行數(shù)據(jù)質量控制、統(tǒng)計分析、公共信息發(fā)布等采用不同方法和參數(shù)變量，導致部門內數(shù)據(jù)存在差異，既造成不良的社會影響，也給科研工作也帶來諸多不便。氣象數(shù)據(jù)的一致性需要由頂層進行統(tǒng)籌規(guī)劃和解決。

因此，氣象部門需要迫切建立具有高擴展性、高并發(fā)性、高時效性的規(guī)范化、集約化的統(tǒng)一氣象科研數(shù)據(jù)治理策略和平臺，為氣象科研與業(yè)務系統(tǒng)正常運行提供強有力的數(shù)據(jù)支撐。

2 系統(tǒng)設計

2.1 系統(tǒng)架構

圖1給出了平臺的系統(tǒng)架構。平臺涉及氣象數(shù)據(jù)從生產(chǎn)到業(yè)務應用，涵蓋數(shù)據(jù)探測感知、存儲管理和數(shù)據(jù)服務等環(huán)節(jié)的統(tǒng)一規(guī)劃。感知層是數(shù)據(jù)的來源，涵蓋多行業(yè)的各類異構地球科學數(shù)據(jù)，通過質量控制、編碼解碼、統(tǒng)計分析、格式轉換形成統(tǒng)一數(shù)據(jù)源。數(shù)據(jù)存儲層是數(shù)據(jù)的存儲管理，通過多態(tài)數(shù)據(jù)庫(關系型數(shù)據(jù)庫、分析型數(shù)據(jù)庫、內存數(shù)據(jù)庫、文件/對象數(shù)據(jù)庫等)、數(shù)據(jù)同步、讀寫分離、分庫分表等進行的分類整理和全序列存儲管理。分布式服務層是數(shù)據(jù)的調用方法和算法封裝，包括統(tǒng)計分析、圖像渲染、等值線追蹤、站點數(shù)據(jù)插值等，通過Docker容器進行發(fā)布管理，形成分布式的服務層。平臺服務層是面向管理用戶提供數(shù)據(jù)、算法、可視化服務、眾創(chuàng)服務發(fā)布管理和性能監(jiān)視等功能，通過RESTful、Web Service、服務總線、在線調試、性能監(jiān)視等提供標準化的調用API接口和使用資源清單。應用層則是該平臺提供數(shù)據(jù)、算法和服務的最終用戶應用系統(tǒng)。

圖1 系統(tǒng)架構

2.2 軟件架構

圖2給出了平臺的軟件架構。平臺的應用層由多個等功能Web應用服務器組成，利用硬件負載均衡服務器組件集群形成高可用架構；Web應用服務器采用混合MVC架構和Hibernate持久化架構，系統(tǒng)邏輯清晰、層次分明、松散耦合，使得系統(tǒng)具有較強的擴展性和兼容性。緩存層是提升整套業(yè)務系統(tǒng)并發(fā)能力的核心。采用了雙Redis[4]集群作為氣象數(shù)據(jù)的高速緩存，對緩存有效時限內的相同數(shù)據(jù)請求，直接通過內存提供數(shù)據(jù)服務，避免對底層數(shù)據(jù)庫和存儲系統(tǒng)發(fā)出IO請求，降低了存儲層的并發(fā)壓力。數(shù)據(jù)層主要包括平臺字典數(shù)據(jù)和多圈層地球科學數(shù)據(jù)的存儲，與緩存層和應用層分布在不同的網(wǎng)絡區(qū)域。

圖2 軟件架構

2.3 部署架構

圖3給出了平臺的部署架構。平臺主要有兩個集群：①基于Socket的格點服務集群；②基于HTTP的一體化數(shù)據(jù)服務集群，包含了格點集群服務的HTTP協(xié)議實現(xiàn)。

圖3 系統(tǒng)架構

基于Socket的格點集群服務：分別在獨立的兩臺服務器(GIFT-1、GIFT-2)上部署格點數(shù)據(jù)服務(GridDataServer)軟件，由高可用軟件組建主備集群，主服務器綁定服務IP對外發(fā)布服務，主備間通過心跳私網(wǎng)進行數(shù)據(jù)同步和服務健康性的信息傳遞。由于精細化格點預報訂正平臺對數(shù)據(jù)的交互操作時效性要求非常高，因此采用SOCKET進行原生數(shù)據(jù)傳輸交換。

基于HTTP的一體化數(shù)據(jù)服務集群：分別在5臺服務器上部署一體化數(shù)據(jù)訪問服務總線，由兩臺硬件負載均衡將其組件為總線集群；Redis緩存服務利用格點服務集群高可用軟件和服務器，搭建Redis集群提供緩存服務；MySQL、Oracle等利用自身數(shù)據(jù)庫的集群架構，文件數(shù)據(jù)、衛(wèi)星數(shù)據(jù)、圖形產(chǎn)品和格點數(shù)據(jù)按照類別存儲在不同服務器上，并對應部署FileDataServer、SateDataServer、ImageDataServer、GridDataServer等微服務，形成數(shù)據(jù)服務層；一體化數(shù)據(jù)訪問服務總線根據(jù)訪問路由策略，從目前微服務中獲取數(shù)據(jù)。平臺各環(huán)節(jié)均采用了集群、高可用方法從而避免了系統(tǒng)單點故障的發(fā)生。

2.4 功能劃分

圖4給出了平臺的主要功能劃分。平臺主要由服務總線、資源管理和數(shù)據(jù)服務三大模塊構成。

圖4 功能分布

服務總線是平臺用戶的統(tǒng)一出入口。提供數(shù)據(jù)、接口和算法等資源的分類瀏覽和檢索服務；通過基于角色權限控制技術確保平臺的訪問安全；通過建立資源訪問黑、白名單確保數(shù)據(jù)、算法和服務資源安全；系統(tǒng)建立總體訪問量、用戶訪問量等流量信息內存模型，新的請求發(fā)起之前進行流量限制策略對比，達到限制則立即中斷訪問，確保系統(tǒng)在有效負載下運行；平臺的各類數(shù)據(jù)存放在不同存儲系統(tǒng)，算法與服務也以微服務方式部署在不同主機，服務總線收到用戶的資源訪問請求后，根據(jù)訪問接口名稱、數(shù)據(jù)種類與時間戳進行綜合判斷確定提供服務的訪問鏈路進行重新路由定位，它是平臺的核心內容之一；平臺根據(jù)每次調用的詳細日志記錄，分析各個接口的平均耗時、最大耗時，以及時間段內的訪問量和緩存命中率，綜合分析平臺運行的性能等；在線調試是提供給用戶的可視化在線資源調用模擬環(huán)境。

資源管理是管理員和眾創(chuàng)人員注冊、發(fā)布和變更各類資源的統(tǒng)一入口。各類資源的需求都會隨業(yè)務需求發(fā)生變化，例如新增數(shù)據(jù)種類，新增服務算法，修改算法具體實現(xiàn)、變更接口參數(shù)、變更訪問路由策略等，該模塊提供了以上可視化的操作功能。

接口服務是平臺部署的各類數(shù)據(jù)訪問、內嵌算法服務和眾創(chuàng)算法服務微服務集。主要涵蓋站點、格點、文件、圖形產(chǎn)品、衛(wèi)星數(shù)據(jù)等的寫入、讀取功能；內置有統(tǒng)計分析、圖形渲染與格點數(shù)據(jù)的融合、插值、裁剪等算法，眾創(chuàng)算法服務主要由第三方公司編寫的具有復用性的算法或業(yè)務功能微服務。

以上三大模塊構成平臺的整體框架，其中平臺還涉及到多類數(shù)據(jù)的融合、格式轉換、日志維護等，這些功能相互協(xié)調才能形成完整的平臺。

3 關鍵技術

平臺的綜合運用多種IT技術，其中多源異構數(shù)據(jù)融合是利用同步技術將結構化與格式轉換技術將非結構化的數(shù)據(jù)集中統(tǒng)一存儲，解決數(shù)據(jù)格式、存儲策略、存儲技術和管理系統(tǒng)集中統(tǒng)一化問題，是平臺數(shù)據(jù)支撐基礎；網(wǎng)格數(shù)據(jù)裁剪和插值等技術，主要是面向基于位置氣象應用場景提供的微服務算法，是平臺算法服務的部分內容；熔斷技術是平臺主動檢測微服務性能、響應時間是否正常，當異常發(fā)生時則主動將該服務進行隔離，避免過多請求排隊等待該服務響應，導致平臺整體性能和容量被擠占無法正常服務，是平臺正常運行的關鍵；高可用和高并發(fā)是決定平臺承載容量的關鍵，緩存、數(shù)據(jù)壓降低平臺響應延時，提升并發(fā)能力；高可用軟件保證核心數(shù)據(jù)的熱備，負載均衡保證服務節(jié)點共擔服務壓力，提升數(shù)據(jù)與服務的可靠性。下面詳細對關鍵技術實現(xiàn)進行詳述。

3.1 結構化數(shù)據(jù)融合

采用同步技術實現(xiàn)數(shù)據(jù)的主-備分離存儲，主庫提供數(shù)據(jù)的寫入服務，備庫提供檢索服務，讀寫分離策略是提升系統(tǒng)服務能力的常用手段。平臺涉及的數(shù)據(jù)庫的同步技術根據(jù)捕獲數(shù)據(jù)源發(fā)生變更方法分為ETL、觸發(fā)器和歸檔日志同步3種。ETL(extract-transform-load)同步，即將源數(shù)據(jù)抽取出來后，進行數(shù)據(jù)字段轉換等處理操作，再插入到目標存儲系統(tǒng)中的過程，該方法最為簡單，但同步時效性最差。觸發(fā)器同步，在源數(shù)據(jù)表上創(chuàng)建觸發(fā)器對表格數(shù)據(jù)的變更記錄在表中，自行開發(fā)程序讀取變更記錄在目標數(shù)據(jù)庫進行數(shù)據(jù)變更操作回放，達到同步目的。歸檔日志同步，數(shù)據(jù)庫在運行過程中均會對數(shù)據(jù)的變更產(chǎn)生歸檔日志，由第三方軟件產(chǎn)品抽取日志，并對變更數(shù)據(jù)進行可選擇處理后在目標庫進行數(shù)據(jù)變更操作回放，達到數(shù)據(jù)同步目的。主流的工具有(oracle goldengate，OGG)，可兼容絕大多數(shù)關系型數(shù)據(jù)庫同步等。

圖5給出了平臺的數(shù)據(jù)同步業(yè)務流程。采用3種同步技術將分散、凌亂、異構數(shù)據(jù)整合到緩沖數(shù)據(jù)庫臨時存儲短時數(shù)據(jù)，利用OGG將數(shù)據(jù)同步到應用數(shù)據(jù)庫中的短時數(shù)據(jù)表，隨時間推移短時數(shù)據(jù)轉變?yōu)闅v史數(shù)據(jù)被遷移到按年存儲的歷史表中，服務平臺根據(jù)用戶請求數(shù)據(jù)的時間參數(shù)決定訪問對應數(shù)據(jù)表，從而向業(yè)務提供合適的數(shù)據(jù)和增強系統(tǒng)的并發(fā)承載能力。

圖5 平臺數(shù)據(jù)同步業(yè)務流程

3.2 格點數(shù)據(jù)融合

氣象行業(yè)對于網(wǎng)格數(shù)據(jù)的較多采用GRIB、NetCDF、HDF、AWX和自定義二進制格式進行存儲。格式不同，但格點數(shù)據(jù)的使用方法非常類似，為此許婧[5]、劉立明[6]、肖華東[7]等利用Mars系統(tǒng)對氣象模式數(shù)據(jù)管理和業(yè)務應用進行研究，但從實際的使用效果來看，復雜命令集和自定義功能擴展的局限性給氣象業(yè)務系統(tǒng)開發(fā)提出較高技術要求。

因此，根據(jù)實際業(yè)務需求(例如：裁剪、插值、升降尺度等操作)設計符合氣象業(yè)務需求的統(tǒng)一格點數(shù)據(jù)格式，建立集中存儲的格點數(shù)據(jù)庫和格點數(shù)據(jù)統(tǒng)一化處理模塊，將天氣、氣候、海洋、環(huán)境模式，大氣再分析和天氣實況等進行規(guī)整化處理，為開發(fā)格點產(chǎn)品服務集提供數(shù)據(jù)基礎。圖6詳細描述了格點數(shù)據(jù)融合業(yè)務流程。

圖6 格點數(shù)據(jù)融合業(yè)務流程

3.3 裁剪技術

數(shù)值模式產(chǎn)品大多為涵蓋為全球、半球、洲際或局部地區(qū)，實際應用中區(qū)域性需求非常普遍，為提高業(yè)務處理效率需要對數(shù)據(jù)進行按需裁剪。根據(jù)文獻[8]中提出網(wǎng)格裁剪的內縮和外擴方法，根據(jù)用戶裁剪范圍的始、終點落在網(wǎng)格點的具體方位不同給出對應的處理方法，圖7為具體處理，本文設計了內縮和外擴方法的具體實現(xiàn)算法。

圖7 內縮算法效果

算法1： 內縮和外擴裁剪算法—左上角定位

輸入：ltP左上坐標，rbP右下坐標，xArray是X方向的升序經(jīng)度值數(shù)組，yArray是Y方向的升序緯度值數(shù)組，offsetleft為采用內縮或外擴標識位。

輸出：ret取值點的下標值

(1)functionfindLeftTopP(ltP.x,rbP.y,xArray,yArray,offsetleft)

(2)ret←0

(3)tmpIndex1←0,tmpIndex2←0,i←0;

(4)whilei

(5)ifltP.x-xArray[i]<=0.00001then

(6)tmpIndex1←tmpIndex2←i;

(7)break;

(8)elseifltP.x-xArray[i]>0.00001then

(9)break;

(10)else

(11)tmpIndex1←i;

(12)tmpIndex2←i+1;

(13)i++;

(14)endif

(15)endwhile

(16)ifoffsetleftthen

(17)ret←tmpIndex1

(18)else

(19)ret←tmpIndex2

(20)endif

(21)returnret

(22)endfunction

3.4 插值算法

基于用戶位置的氣象服務場景中，需要從網(wǎng)格數(shù)據(jù)中提取當前位置的氣象要素(天氣實況和預報)，因此需要通過插值方法從相鄰網(wǎng)格中計算當前位置的氣象要素值。本系統(tǒng)采用氣象中常用的最近距離法[9]、反距離加權[10](IDW)和雙線性插值算法(BL)。網(wǎng)格密度小于1 km*1 km 時采用NN算法較為合理，否則可采用IDW或BL插值算法。本文給出具體的任意位置氣象要素插值算法如下：

算法2： 任意點求值算法

輸入：lon經(jīng)度值，lat緯度值，type插值算法類型

輸出：ret氣象要素值

(1)functioninterpolate(lon,lat,type)

(2)ret←UNDEFINED

(3)xArray←getXPointsFromGridFile()

(4)yArray←getXPointsFromGridFile()

(5)ifisInThePoint(xArray,yArray,lon,lat)then

(6) ret←findVal(findP(lon,xArray,lat,yArray));

(7)else

(8)ltP←findVal(findLeftTopP (lon,lat))

(9)lbP←findVal(findLeftButP (lon,lat))

(10)rtP←findVal(findRighTopP (lon,lat))

(11)rbP←findVal(findRighButP (lon,lat))

(12)switch(type)

(13)caseNN:

(14)ret←NNInterpolate(ltP,lbP,rtP,rbP)

(15)caseIDW:

(16)ret←IDWInterpolate(ltP,lbP,rtP,rbP)

(17)caseBL:

(18) ret←BLInterpolate(ltP,lbP,rtP,rbP)

(19)endswitch

(20)endif

(21)returnret

(22)endfunction

(23)

(24)functionfindP(lon,xArray,lat,yArray)

(25)i←0,j←0;

(26)whilexArray[i++]-lon<0.00001do

(27) break;

(28)endwhile

(29)whileyArray[i++]-lat<0.00001do

(30) break;

(31)endwhile

(32)point.x←i,point.y←j;

(33)returnpoint;

(34)endfunction

(35)

(36)functionfindVal(point)

(37)valArray←getXPointsFromGridFile()

(38)xRowGridLen←xArray.len

(39)yRowGridLen←yArray.len

(40)index←(int)(point.x/xRowGridLen)+point.x%xRowGridLen+(int)(point.y/yRowGridLen)

(41)returnvalArray[index]

(42)endfunction

3.5 熔斷設計

平臺的服務總線會根據(jù)用戶調用的數(shù)據(jù)內容將請求路由到后臺服務，當后臺服務出現(xiàn)故障、性能下降或超出承載能力時，則需要通知服務總線限制或暫停對該類調用提供服務，避免服務總線負載大量的不可達服務而使整個平臺無法提供其它數(shù)據(jù)服務的情況。

設計鏈路狀態(tài)數(shù)據(jù)結構S={r,s,a,mi,ma,ut}， 其中r為平臺能唯一標識的服務鏈路，s為服務是否可達狀態(tài)，a為服務平均響應時間，mi為服務響應最小時間，ma為服務響應最大時間，ut為鏈路狀態(tài)的更新時間。設計鏈路健康性檢查，定時探測更新平臺中的所有服務鏈路健康狀態(tài)，利用高速緩存持久化保存。服務總線收到請求首先檢查服務鏈路狀態(tài)，然后依據(jù)表1所示熔斷規(guī)則進行處理。

表1 服務熔斷處理策略

3.6 格點服務高可用設計

格點服務是數(shù)字網(wǎng)格預報業(yè)務的基礎，它提供了網(wǎng)格數(shù)據(jù)的寫入、讀取和插值服務，該服務的中斷或數(shù)據(jù)缺失直接影響預報業(yè)務的中斷，利用RoseMirrorHA[11]設計了服務高可用和主、備數(shù)據(jù)準實時同步的架構。圖8由2臺服務器、高可用軟件、公網(wǎng)與私網(wǎng)組成，兩臺服務器安裝相同的業(yè)務軟件，高可用軟件創(chuàng)建服務IP對外提供服務，當用戶發(fā)起讀取或寫入數(shù)據(jù)請求時，由主服務器進行響應，高可用軟件將發(fā)生變化的數(shù)據(jù)塊通過私網(wǎng)同步到備份服務器。當主服務器宕機或格點服務掉線，備服務器會探知主服務器異常發(fā)生，則綁定服務IP并接管格點服務，由此達到數(shù)據(jù)一致且服務高可用的效果。

圖8 格點服務高可用架構

3.7 高并發(fā)策略

數(shù)據(jù)的存儲層性能和網(wǎng)絡傳輸速率是影響系統(tǒng)并發(fā)的兩個關鍵因素，系統(tǒng)利用緩存技術減少系統(tǒng)對數(shù)據(jù)存儲的讀寫操作，利用壓縮技術減少數(shù)據(jù)與客戶端之間數(shù)據(jù)量，從而提升平臺的響應能力。

(1)高速緩存：服務總線根據(jù)調用請求中的參數(shù)值，以接口定義中的參數(shù)順序形成唯一的Key，若命中緩存，則從緩存中讀取數(shù)據(jù)；否則，從存儲系統(tǒng)檢索數(shù)據(jù)，將原始結果加工為字符型Value，存儲到緩存系統(tǒng)后，返回給用戶，從而緩解大量相同數(shù)據(jù)請求對存儲系統(tǒng)造成IO的沖擊，提高數(shù)據(jù)服務響應能力和并發(fā)能力。主要實現(xiàn)算法如下：

算法3： 緩存算法

輸入：apiObj接口定義對象

輸出：retObj返回數(shù)據(jù)結果對象

(1)functiongetDatasFromCache(apiObj)

(2)ret←newObject{}

(3)key←getKeyStr(apiObj)

(4) if Redis.contains(key)

(5)ret←Redis.get(key)

(6) else

(7)ret←getDatasFromDisk()//根據(jù)存儲類型具體實現(xiàn)方法有所差別

(8) Redis.put(key,ret,apiObj.expireTime)

(9) end if

(10) returnretObj;

(11)endfunction

(12)functiongetKeyStr(apiObj)

(13)ret←UNDEFINED

(14)list←sortParameters(apiObj.parameters)

(15)whilei

(16)p←list.get(i)

(17)ret←‘.’+p.val

(18)i++

(19)endwhile

(20)returnret

(21)endfunction

(22)functionsortParameters(ps)

(23)fori=ps.size→0do

(24)forj=0→i-1do

(25)ifps[j]>ps[j+1]

(26)temp←ps[j]

(27)ps[j]←ps[j+1]

(28)ps[j+1]←temp

(29)endif

(30)endfor

(31)endfor

(32)endfunction

(2)數(shù)據(jù)壓縮：平臺采用HTTP協(xié)議與客戶端進行數(shù)據(jù)交換，對于格點、衛(wèi)星、圖形產(chǎn)品和文件等二進制數(shù)據(jù)，需要對數(shù)據(jù)進行Base64編碼后才能返回用戶，但Base64編碼會讓數(shù)據(jù)量增長原有長度的1/3，從而增加網(wǎng)絡的傳輸時延，特別是在大數(shù)據(jù)量情況下影響非常大。因此，平臺調用設計啟用與關閉數(shù)據(jù)壓縮的系統(tǒng)參數(shù)，由調用用戶控制是否進行壓縮傳輸。平臺默認使用GZIP壓縮算法進行數(shù)據(jù)傳輸，具體的編解碼過程和效率可參見文獻[12]。

(3)負載均衡：用戶通過網(wǎng)絡直接與Web服務器相連接，但如果服務器出現(xiàn)故障，則無法正常提供服務；即使服務器正常工作，但當很多用戶同時訪問服務器，超過服務器的承載能力，則會出現(xiàn)響應慢甚至無法連接的情況，這兩種情況都影響系統(tǒng)可用性和并發(fā)性。將多個等功能的服務器組成集群，由負載均衡將用戶的訪問請求分發(fā)到不同的服務器，可提高平臺整體的承載能力，也可快速擴展系統(tǒng)承載力，同時容忍部分服務器宕機情況發(fā)生，很好解決了上面提到的兩個問題。

4 性能分析與業(yè)務應用

4.1 性能分析

針對一體化數(shù)據(jù)訪問平臺和省級綜合氣象信息共享平臺(簡稱：CIMISS)[13]進行性能對比測試，測試終端環(huán)境如下：硬件環(huán)境：CPU I5-4590 3.3 GHz；內存8 GB；硬盤500 GB；千兆網(wǎng)；軟件環(huán)境：JMeter3.1，Windows 10 64位。

表2以調取廣東某觀測時國家氣象站資料為例，分別在10、20、50、100、150、200并發(fā)下測得兩套系統(tǒng)的平均響應時效和業(yè)務吞吐量，一體化訪問平臺的優(yōu)于CIMISS系統(tǒng)，且在200并發(fā)時平均響應314 ms響應，事務處理能力達到530 TPS，能夠滿足業(yè)務應用需求。

表2 站點數(shù)據(jù)訪問性能測試

表3以調取廣東范圍格點預報資料為例，10-200并發(fā)時，一體化訪問服務平臺訪問效率和吞吐量遠遠于CIMISS系統(tǒng)，且在200并發(fā)時在15 ms內響應，事務處理能力達到4787 TPS，能夠滿足全省智能網(wǎng)格預報業(yè)務的訪問需求。

表3 格點數(shù)據(jù)訪問性能測試

表4以調取華南區(qū)域雷達拼圖產(chǎn)品為例，在10、20并發(fā)時CIMISS的時效性和吞吐量相差不大，但在50-200并發(fā)時一體化平臺明顯優(yōu)于CIMISS平臺，且在200并發(fā)時系統(tǒng)能在41 ms內響應，事務處理能力達到2017 TPS，能夠滿足全省圖形產(chǎn)品訪問的業(yè)務支撐。

表4 圖形產(chǎn)品訪問性能測試

綜合以上的響應性能和并發(fā)能力對比測試，一體化數(shù)據(jù)訪問平臺的設計改善了數(shù)據(jù)訪問的時效和系統(tǒng)的吞吐量，且在200并發(fā)時能在秒級以內響應用戶請求，平臺的事務處理能力最少530 TPS，最大達到4787 TPS，完全滿足每日全省的氣象業(yè)務應用訪問需求，達到預期的設計目的。

4.2 業(yè)務應用

系統(tǒng)自應用以來，用戶訪問量逐年增長，2019年相比2014年度數(shù)據(jù)下載量增長100倍，訪問量增長近50倍，如圖9所示。目前，系統(tǒng)單日數(shù)據(jù)訪問下載量達3.2 TB，單日訪問次數(shù)達3000萬次，成功支撐了廣東省精細化格點預報訂正平臺[8]、廣東省SWIFT系統(tǒng)平臺[8]、珠海城市生態(tài)氣象綜合系統(tǒng)[14]、繽紛微天氣公眾服務平臺等核心業(yè)務。

圖9 平臺逐年訪問量統(tǒng)計

5 結束語

本文分析了氣象領域的數(shù)據(jù)感知現(xiàn)狀和數(shù)據(jù)治理與應用中存在的問題，形成的一體化數(shù)據(jù)訪問服務平臺為氣象數(shù)據(jù)的治理和分析應用提供了統(tǒng)一環(huán)境，搭建了數(shù)據(jù)管理者與使用者之間的關鍵通道。該平臺對氣象行業(yè)和技術有以下貢獻：①綜合利用多態(tài)數(shù)據(jù)存儲管理技術和數(shù)據(jù)同步技術將地球多圈層科研數(shù)據(jù)按照存儲格式分類規(guī)整處理，形成了一體化的綜合型氣象數(shù)據(jù)倉庫。②采用同步技術和分布式服務技術從邏輯上屏蔽了數(shù)據(jù)源的異構性，借用服務總線設計思路形成標準化的數(shù)據(jù)、算法等服務集，為氣象業(yè)務形成一體化的數(shù)據(jù)調用環(huán)境。③提供的數(shù)據(jù)可視化與算法服務，滿足了氣象業(yè)務中多數(shù)產(chǎn)品制作需求，推動了數(shù)據(jù)服務向應用服務的觀念轉型。④在全國氣象行業(yè)率先以RESTful API的方式向業(yè)務單位發(fā)布數(shù)據(jù)，為全國氣象綜合業(yè)務系統(tǒng)的建設提供先進經(jīng)驗。

隨著氣象業(yè)務應用復雜度增加，其對數(shù)據(jù)的種類和數(shù)量也在增加，可視化服務的個性化需求更加突出，平臺面臨數(shù)據(jù)、算法和服務能力的多重挑戰(zhàn)。后期研究中除兼容更多先進存儲技術外，針對用戶個性化需求研究算法服務眾創(chuàng)功能，結合微服務和容器技術降低平臺的耦合度，增強平臺的橫向擴展能力和服務處理能力。