氣象數據一體化平臺設計方案

1、項目編號：RJ20150020設計方案氣象數據一體化信息服務平臺 設計方案2016年1月南京助事達軟件科技有限公司目 錄1概述31.1背景與預期31.2建設內容42設計方案52.1系統(tǒng)架構52.1.1.平臺總體架構圖52.1.2.數據流概覽62.2分布式解析引擎62.2.1.分布式解析引擎概述62.2.2.分布式解析設計架構72.3氣象分布式數據庫設計122.3.1.氣象一體化平臺分布式數據庫設計概述122.3.2.分布式數據庫設計架構152.4氣象資料云服務引擎172.4.1.應用授權機制172.4.2.授權認證機制172.4.3.服務請求基礎參數體系建立172.5服務版本管理體系建立182

2、.5.1.版本管理設計182.5.2.建立服務API幫助文檔181概述1.1 背景與預期針對以往基礎數據庫建設分散、標準不統(tǒng)一、服務能力差等問題，按照“系統(tǒng)集成，數據集中，資源集約，功能完善，突出特色”的思路，經過兩年半的努力，依托江蘇預報業(yè)務一體化平臺項目建設，初步建成全省統(tǒng)一的基礎數據環(huán)境，有效提高了信息資源的利用率和數據服務能力，為本省率先實現(xiàn)氣象現(xiàn)代化提供了有力支撐。信息中心在全省氣象信息業(yè)務建設的基礎上，先后出臺幾十項標準或規(guī)范，為一體化體系提供標準支撐，完善了我省氣象信息的標準規(guī)范體系；優(yōu)化數據傳輸流程，時效性可靠性提升顯著，省內區(qū)域自動站可實現(xiàn)60秒內、雷達數據8分鐘之內、省際共

3、享上海市區(qū)域自動站100秒內到達預報員桌面；通過“軟CAST”同步機制，省市間數據實現(xiàn)了秒級流轉；完成了自動站、土壤水份、精細化等50多類數據的解析入庫，數據解析的種類和覆蓋范圍在不斷擴充，確保了數據的完整性、一致性。架設全省云平臺實現(xiàn)硬件資源的統(tǒng)一管理與分配，達到資源集約化、應用多樣化的目標。為進一步提高和增強氣象數據服務能力，科學準確的做好數據服務工作，結合前期預報業(yè)務一體化平臺使用和市縣推廣應用情況，在氣象數據傳輸、數據存儲和數據應用方面，提出諸多改進措施和方案，旨在不斷的提高氣象數據服務能力和質量。1.2 建設內容根據江蘇氣象現(xiàn)代化發(fā)展的需求，在現(xiàn)有工作基礎上，進一步完善全省基礎資源配

4、置和管理，開展智能化、個性化的基礎數據環(huán)境信息服務平臺的設計和開發(fā)，繼續(xù)優(yōu)化各類基礎資料的收集處理流程，做好統(tǒng)一數據環(huán)境在市縣的推廣應用，著手開展適合本省的實時質量控制方法研究和質控系統(tǒng)的設計和開發(fā)工作，提高數據服務質量。通過建立團隊協(xié)作機制，聯(lián)合進行數據處理和信息技術應用開發(fā)，建立數據規(guī)范；完成實時/歷史數據庫設計、解碼和入庫。2設計方案22.1 系統(tǒng)架構1.2.2.1.2.1.1. 平臺總體架構圖圖表 1平臺總體架構圖2.1.2. 數據流概覽圖表 2數據流概覽2.2 分布式解析引擎2.2.2.2.1. 分布式解析引擎概述氣象資料的來源有多種，包括上百種類型的氣象資料報文、各個業(yè)務系統(tǒng)產出的

5、氣象服務產品、來自于CIMISS的數據資料等等。由于資料種類繁多、場地分散、解析入庫方式及質量參差不齊等等各種問題的存在，同樣為了滿足集中管理、統(tǒng)一標準的業(yè)務目標需求，我們最終使用了氣象數據分布式解析引擎來實現(xiàn)其各種功能。2.2.2. 分布式解析設計架構 圖表 3分布式解析設計架構分布式解析云的核心主要由四個部分組成：a) 解析云服務主要通過實時發(fā)布遠程對象的方式為各個功能域提供分進程間信息共享平臺。共享的遠程對象主要包括：報文資源文件夾監(jiān)控對象、分布式解析器運行時對象、服務全局控制對象、智能化解析配置對象、全局報文解析組件適配對象等。實質：遠程對象以信道作為發(fā)布渠道，來進行客戶端和服務器之間

6、的通信。信道包括客戶端的信道部分和服務器的信道部分。發(fā)布的內容以消息作為載體，消息包含遠程對象的信息、被調用方法的名稱以及所有的參數。 圖表 4分布式客戶端與服務間通信原理報文資源文件夾監(jiān)控對象：每種資源文件都存儲在一個或多個文件夾中，當有新的文件加入時解析云自動將待解析的文件加入到解析資源池（即任務隊列）。當分布式解析器中有存在空閑的解析器時，此解析器則會自動向服務申請一個解析任務。之后，當一個任務被解析器處理完畢后，其就會從任務隊列中自動刪除，同時將相對應的原始數據文件自動移動到已處理文件目錄下面。分布式解析器運行時對象：每個報文解析器分別部署在一個或多個服務器上，那么各個解析器運行狀態(tài)的

7、管理就十分的重要。為了滿足全局監(jiān)控，定向管理的目標，云解析平臺將分布式解析器運行時對象作為各功能域內部可見的全局對象進行發(fā)布。即各個解析器運行后自動向云服務發(fā)送注冊請求，云服務接受請求后則將此解析器加入到解析器隊列中用于后期的監(jiān)控及管理。服務全局控制對象：主要負責服務的啟動、暫停、重啟以及重新加載配置文件等工作。智能化解析配置對象：此對象主要為分布式解析引擎提供解析知識庫，為了實現(xiàn)解析組件的可插拔我們將智能解析配置對象也作為全局對象進行發(fā)布?？梢詮脑平馕龉芾砥髦袑ζ鋬热葸M行更改，更改后云服務自動通知各個解析器接下來的解析工作使用新的解析知識庫進行報文識別及智能解析。全局報文解析組件適配對象：為

8、了使報文的識別實現(xiàn)動態(tài)化擴展，我們將解析適配器對象進行全局發(fā)布，當云解析管理器對解析適配器信息進行更改后云解析服務將自動應用新的解析適配方案。所有的分布式解析器都使用云解析服務提供的統(tǒng)一解析適配器進行解析適配工作，所以當云服務的適配器方案改變后各個解析器自動使用新的方案進行適配工作。b) 云解析管理器云解析管理器是云解析服務的一個客戶端，主要用于輔助云解析服務工作，為云解析服務提供可視化操作界面。如云解析服務提供的各個實時對象的管理及運行時參數的維護管理等工作都在云解析器中進行操作。如報文解析組件適配信息配置、智能化解析知識庫配置、分布式客戶端監(jiān)控、資源池監(jiān)控、解析組件配置、數據源配置、運行日

9、志管理等。c) 分布式解析引擎分布式解析引擎是云解析服務的運算核心，所有類型的數據都通過此引擎進行解析運算。報文解析引擎由三大支撐組件（數據類型識別組件、智能化解析組件和解析組件適配器）和解析組件池組成。數據類型識別組件：數據類型識別組件主要對當前申請到的解析資源進行自動識別，主要通過數據文件名、數據段特殊標記以及其他特性化配置方式進行識別。數據類型被識別后向解析引擎反饋此文件的解析適配標識。解析組件適配器：解析組件適配器主要將數據類型識別組件反饋的解析適配標識進行適配，并從解析組件工廠中構造一個適合此適配標記的解析組件智能化解析組件：智能化解析組件主要將智能解析知識庫中的信息翻譯成解析器能夠

10、識別的信息結構，并將此信息結構提供給解析組件進行報文解析。解析組件池：由一系列報文解析組件組成，如重要天氣報解析組件、A文件解析組件、高空資料解析組件、自動站解析組件等等。每個解析組件都遵從解析引擎的報文解析流程，最終完成報文的解析。報文解析流程如下：圖表 5報文解析流程d) 分布式解析器分布式報文解析器主要有如下幾個特性：1.分布式:即此解析器可以在多臺服務器上同時運行，同樣也可以在一臺服務器上運行多個實例。2.可擴展性:解析器中搭載的是解析組件引擎，而解析組件隊列可在遠程服務中直接獲取，所以當云解析服務更新組件配置或加入新的解析組件時各個解析器同時受益。3.并行計算:每個解析器的都在獨立的

11、進程中進行運算，所以當多個解析器同時對解析任務池中的任務進行解析時大大縮短了解析的時間縮短，提高解析效率。4.可管理性:每個解析組件運行后首先會注冊到解析云服務，同時解析云服務會將此信息反饋給解析服務管理器，管理器收到信息后將此解析組件加入到本地的可視化解析組件管理列表中，對其進行實施監(jiān)控。當一個解析器出錯或強行退出時，解析云自動注銷其消息訂閱事件，并通知解析云服務管理器，管理器從管理列表中將此解析器移除，或提醒管理員此解析器已下線。2.3 氣象分布式數據庫設計2.3.2.3.1. 氣象一體化平臺分布式數據庫設計概述從目前江蘇省氣象信息的數據結構及分布情況分析，我們的數據屬于異構數據庫。即現(xiàn)有

12、的數據使用了多個DBMS，如SQL Server，Oracle等。由于各種氣象資料較為繁雜，存儲的數據結構也不盡相同。所以我們建立的分布式數據庫管理架構不但要解決分布式存儲的問題還需要解決異構數據庫的問題。本架構設計的核心原理是通過分布式數據服務全局共享數據節(jié)點索引對象。并使用分布式數據庫管理引擎來對各個數據節(jié)點進行高效的存取操作。數據索引需要建立在一個全局共同遵守的標準之上，這個標準中規(guī)定了在不同數據分片場景下各個數據節(jié)點應共同包含或通過邏輯映射的方式包含相應的屬性。如在水平分片場景下，各個數據節(jié)點應共同擁有日期屬性，日期屬性可分為（年、月、旬、候、時間）等多個分類方式。如同屬于年分類的場景

13、下，則需要共同擁有年屬性。如在垂直分片場景下，各個數據節(jié)點應共同擁有要素類型屬性。分布式存儲的核心問題是對數據分片和數據分配方式，分片的方式分為水平分片、垂直分片、導出分片和混合分片。水平分片：即按一定的條件把全局關系的所有元組劃分成若干不相交的子集，每個子集為關系的一個片段。根據分析我們可以通過時間節(jié)點對數據進行水平分片。垂直分片：即把一個全局關系的屬性集分成若干子集，并在這些子集上作投影運算，每個投影稱為垂直分片。如我們可以通過氣象要素進行空間的垂直分片。導出分片：又稱為導出水平分片，即水平分片的條件不是本關系屬性的條件，而是其他關系屬性的條件。我們一般在特殊的數據應用場景中使用此分片方式

14、。如對數據按站點所在的城市為條件進行數據分片，因站點所在的城市這個屬性一般不在要素基本屬性中存在，而是在站點信息關系表中存在，那么此種分片則稱為導出分片?；旌戏制壕C合了以上三種分片方式進行數據分片。數據分配方式分為：集中式、分割式、全復制式和混合式。根據氣象數據的特點我們建議采用分割式的數據分配方式，即所有數據只有一份，它被分割成若干邏輯片段，每個邏輯片段被指派在一個特定的場地上。同時服務器的磁盤陣列使用冗余磁盤陣列(RAID)的方式進行管理，并建議使用RAID10（即RAID 0+ 1）。虛擬化技術虛擬化是一種資源管理技術，是將計算機的各種實體資源，如服務器、網絡、內存及存儲等，予以抽象、

15、轉換后呈現(xiàn)出來，打破實體結構間的不可切割的障礙，使用戶可以比原本的組態(tài)更好的方式來應用這些資源。這些資源的新虛擬部份是不受現(xiàn)有資源的架設方式，地域或物理組態(tài)所限制。一般所指的虛擬化資源包括計算能力和資料存儲。在實際的生產環(huán)境中，虛擬化技術主要用來解決高性能的物理硬件產能過剩和老的舊的硬件產能過低的重組重用，透明化底層物理硬件，從而最大化的利用物理硬件。因為我們需要將數據節(jié)點存儲在多個場地上，為了節(jié)約硬件產品，并充分利用硬件的計算資源以及存儲資源，我們可以將一臺工作站虛擬成多個存儲場地。2.3.2. 分布式數據庫設計架構圖表 6分布式數據庫總體設計方案分布式數據庫的核心模塊分為：分布式數據庫通訊

16、服務(CM)、分布式數據庫管理器(DDBMS)、云存儲接口(Cloud Data API)、Data Client、Data Query Standard Lib 和Data Save Standard Lib。分布式數據庫通訊服務:負責在分布式數據庫的各場地之間傳送全局對象、消息和數據，完成通信功能。圖表 7分布式查詢核心原理圖核心的全局對象是分布式數據索引對象(Data Index Struct)，每個分布式客戶端上線后將自動注冊到分布式數據庫通訊服務，通訊服務自動將其加入到Distributed Client Stack中，同時根據客戶端報送的數據節(jié)點名稱，服務自動為其初始化局部數據庫數

17、據索引對象，并將關鍵索引存儲為Hash Table的key-value模式。并為其訂閱全局數據檢索和數據保存事件等，當有數據檢索請求時，服務通過并行化編程技術使所有分布式客戶端同時處理此事件，當某個分布式客戶端處理發(fā)現(xiàn)本地索引中無相關key或不滿足其數據分片條件時則直接退出響應。如果相關條件都在其索引范圍內，則進行本地化數據查詢操作，并將結果以Data Set的形式返回至事件源。所有并行流程執(zhí)行完成后事件源將Data Set集反饋給查詢者。分布式數據庫管理系統(tǒng)(DDBMS)：分布式數據庫管理系統(tǒng)主要用于2.4 氣象資料云服務引擎2.4.2.4.1. 應用授權機制即每一個接入服務的應用都需要申請

18、一個AppKey，此Key對應著一套數據訪問授權，同時記錄應用名稱、開發(fā)者、軟件功能等信息。2.4.2. 授權認證機制即所有服務請求都必須提交AppKey，請求的數據訪問權限都必須在此AppKey的權限框架下。所有數據請求到達服務器端后進入統(tǒng)一的認證通道，認證通過后服務通過相關的請求參數反饋相應的數據，否則提示應用請求認證失敗。2.4.3. 服務請求基礎參數體系建立為規(guī)范化管理，每一個服務請求應能夠包含部分基礎請求參數，如區(qū)域來源（如地區(qū)標記）、資料類型、返回值類型（JSON、XML、其他格式文件）、等。2.5 服務版本管理體系建立為保障服務的可擴展性以及服務的兼容性，必須建立完善的版本管理體系。2.5.2.5.1. 版本管理設計為保障后期服務功能的升級不會影響前期的使用，每一個服務的升級都對應一個不同的版本號。升級后的服務和升級前的服務都可以獨立運行