一種構(gòu)建高性能仿真基礎(chǔ)數(shù)據(jù)資源池的方法 ①

皇 威，王 通，李清毅，殷建豐

(中國(guó)航天科技集團(tuán)有限公司第五研究院總體部，北京 100094)

0 引言

天基體系數(shù)字孿生體仿真平臺(tái)(以下簡(jiǎn)稱天基孿生體)項(xiàng)目，是基于仿真技術(shù)再現(xiàn)物理天基體系結(jié)構(gòu)、過(guò)程數(shù)據(jù)、行為等的天基體系數(shù)字仿真鏡像，并允許通過(guò)在數(shù)字仿真鏡像中疊加新的體系級(jí)任務(wù)，以仿真推演的方式預(yù)測(cè)其可行性和執(zhí)行效能。對(duì)于可達(dá)到預(yù)期要求的任務(wù)方案，會(huì)被平臺(tái)推送至物理天基系統(tǒng)并執(zhí)行，實(shí)現(xiàn)數(shù)字與物理的聯(lián)動(dòng)。天基孿生體的主體功能組成包含想定、規(guī)劃、仿真、評(píng)估、可視化五方面頂層系統(tǒng)，而對(duì)于這五方面頂層系統(tǒng)來(lái)說(shuō)，它們擁有共同的“資源數(shù)據(jù)服務(wù)”作為技術(shù)支撐，來(lái)保證頂層系統(tǒng)的正常運(yùn)行。因此，資源數(shù)據(jù)服務(wù)功能是體系效能仿真平臺(tái)的基礎(chǔ)，為平臺(tái)中諸多頂層應(yīng)用提供通用基礎(chǔ)數(shù)據(jù)資源的存儲(chǔ)和查詢服務(wù)。保證資源數(shù)據(jù)服務(wù)自身的穩(wěn)定運(yùn)行和高效的數(shù)據(jù)查詢是平臺(tái)工作的基礎(chǔ)和前提。天基孿生體的仿真計(jì)算規(guī)模巨大，對(duì)模型精細(xì)化程度要求很高，需要處理、存儲(chǔ)、檢索的數(shù)據(jù)規(guī)模巨大、數(shù)據(jù)類型龐雜，傳統(tǒng)基礎(chǔ)數(shù)據(jù)服務(wù)能力已無(wú)法與其匹配。目前沒(méi)有在支撐體系級(jí)規(guī)模的仿真、規(guī)劃、評(píng)估分析應(yīng)用的基礎(chǔ)數(shù)據(jù)資源服務(wù)方向的公開文獻(xiàn)。大量相關(guān)公開文獻(xiàn)集中在解決系統(tǒng)及層面的數(shù)據(jù)管理層面上，如“基于ElasticSearch的海量AIS數(shù)據(jù)存儲(chǔ)方法”，主要論述了系統(tǒng)級(jí)數(shù)據(jù)在線實(shí)時(shí)檢索處理能力。

據(jù)工業(yè)4.0研究院考證，數(shù)字孿生體(Digital Twin)這個(gè)概念是由美國(guó)空軍研究實(shí)驗(yàn)室(U.S. Air Force Research Laboratory, AFRL)在2011年首先提出，該概念迅速得到了系統(tǒng)工程領(lǐng)域的行業(yè)人士認(rèn)同。美國(guó)國(guó)防部提出利用Digital Twin技術(shù)，用于航空航天飛行器的健康維護(hù)與保障。GE公司借助Digital Twin這一概念，實(shí)現(xiàn)物理機(jī)械和分析技術(shù)的融合。近兩年，達(dá)索、PTC、西門子都基于Digital Twin概念，面向產(chǎn)品生命周期管控推出了各具特點(diǎn)的系統(tǒng)級(jí)仿真平臺(tái)[1]。隨著工業(yè)4.0和中國(guó)制造2025浪潮的到來(lái)，國(guó)內(nèi)航空航天和汽車領(lǐng)域也在對(duì)數(shù)字孿生體概念和相關(guān)技術(shù)進(jìn)行開展深入的研究和實(shí)踐，相關(guān)研究和實(shí)踐主要以系統(tǒng)仿真領(lǐng)域?yàn)橹?。天孿系統(tǒng)是國(guó)內(nèi)率先開展的天基領(lǐng)域體系級(jí)數(shù)字孿生體項(xiàng)目。在提升天基體系管控能力，挖掘天基體系工作效能方面有著重要的意義。

本文充分分析天基孿生體項(xiàng)目對(duì)基礎(chǔ)數(shù)據(jù)服務(wù)的實(shí)際需求，研究并綜合利用對(duì)象數(shù)據(jù)定義與管理、分布式存儲(chǔ)、大數(shù)據(jù)采集處理、高性能檢索等技術(shù)優(yōu)勢(shì)，設(shè)計(jì)出一種新的基礎(chǔ)數(shù)據(jù)資源服務(wù)構(gòu)建模式——仿真基礎(chǔ)數(shù)據(jù)資源池系統(tǒng)，開發(fā)元數(shù)據(jù)管理、數(shù)據(jù)管理、數(shù)據(jù)發(fā)布接口、數(shù)據(jù)采集接口的五個(gè)組件，為天基孿生體頂層應(yīng)用提供靈活的配置化數(shù)據(jù)管理、穩(wěn)定的集群化數(shù)據(jù)服務(wù)、高效的數(shù)據(jù)檢索能力，保障天基體系多領(lǐng)域綜合應(yīng)用的任務(wù)規(guī)劃能力、仿真計(jì)算能力、評(píng)估分析能力、效能挖掘能力得以實(shí)現(xiàn)。并為下一步天基、地基裝備大規(guī)模聯(lián)合任務(wù)的深度規(guī)劃精準(zhǔn)管控能力奠定技術(shù)基礎(chǔ)。

1 傳統(tǒng)數(shù)據(jù)資源管理和使用方式

體系效能仿真平臺(tái)傳統(tǒng)方式的數(shù)據(jù)資源管理功能是以關(guān)系型數(shù)據(jù)庫(kù)工具為基礎(chǔ)，使用表單應(yīng)用系統(tǒng)作為結(jié)構(gòu)化數(shù)據(jù)的管理和維護(hù)的人機(jī)交互界面，使用數(shù)據(jù)庫(kù)視圖、Web服務(wù)等方式實(shí)現(xiàn)對(duì)平臺(tái)頂層功能的發(fā)布。主要包括數(shù)據(jù)存儲(chǔ)功能、數(shù)據(jù)管理功能、數(shù)據(jù)發(fā)布接口三部分。

數(shù)據(jù)管理功能方面，一般是由想定、規(guī)劃、仿真等頂層功能要求決定。然而不同要求的場(chǎng)景對(duì)仿真想定的數(shù)據(jù)模型結(jié)構(gòu)和精細(xì)化程度各不相同，且很難在軟件的開發(fā)階段就將需要的各類數(shù)據(jù)模型結(jié)構(gòu)和要管理的數(shù)據(jù)完整清晰地提出。因此，數(shù)據(jù)管理功能開發(fā)常會(huì)出現(xiàn)問(wèn)題，如數(shù)據(jù)需求不斷變化導(dǎo)致數(shù)據(jù)管理功能的代碼不斷更動(dòng)，項(xiàng)目周期難控，軟件技術(shù)狀態(tài)難控。

數(shù)據(jù)存儲(chǔ)功能方面，普遍是由關(guān)系型數(shù)據(jù)庫(kù)工具存儲(chǔ)數(shù)據(jù)，隨著體系仿真規(guī)模和精細(xì)化程度的持續(xù)提升，需要處理、存儲(chǔ)、檢索的數(shù)據(jù)規(guī)模日趨巨大。傳統(tǒng)存儲(chǔ)方式的效率較低、檢索性能弱的現(xiàn)象就變得十分顯著，無(wú)法適應(yīng)頂層各功能對(duì)數(shù)據(jù)請(qǐng)求的相應(yīng)要求，已經(jīng)成為平臺(tái)整體運(yùn)行效率的瓶頸。

數(shù)據(jù)發(fā)布接口方面，通常數(shù)據(jù)發(fā)布接口的具體功能與本身的數(shù)據(jù)管理功能耦合較緊，而且與需要使用數(shù)據(jù)的頂層功能有很高的相關(guān)性，因此由需求的不斷變化導(dǎo)致的項(xiàng)目周期難控、軟件技術(shù)狀態(tài)復(fù)雜等問(wèn)題也較為嚴(yán)重。另外，由于平臺(tái)運(yùn)行過(guò)程中諸多系統(tǒng)會(huì)有大量并發(fā)的數(shù)據(jù)請(qǐng)求，數(shù)據(jù)接口服務(wù)的并發(fā)處理能力和高可用能力很難保證，容易造成平臺(tái)的單點(diǎn)失效。

2 仿真基礎(chǔ)數(shù)據(jù)資源池設(shè)計(jì)

2.1 天基孿生體總體功能概述

天基孿生體功能架構(gòu)如圖 1 所示。

天基孿生體功能組成包括兩個(gè)層面：

(1)頂層應(yīng)用層：想定設(shè)計(jì)、任務(wù)規(guī)劃、仿真計(jì)算、評(píng)估分析、可視化、指令生成。

(2)基礎(chǔ)資源池：提供統(tǒng)一的數(shù)據(jù)資源服務(wù)，集中管理空間環(huán)境、實(shí)體特征參數(shù)、仿真實(shí)體數(shù)據(jù)、遙測(cè)實(shí)體數(shù)據(jù)、實(shí)體已有計(jì)劃任務(wù)、疊加/應(yīng)急任務(wù)信息等。

仿真計(jì)算在基礎(chǔ)數(shù)據(jù)資源池服務(wù)的支撐下，以實(shí)時(shí)的方式不間斷仿真推演，并再現(xiàn)物理世界天基的系統(tǒng)結(jié)構(gòu)、過(guò)程數(shù)據(jù)、行為等。并將仿真結(jié)果存儲(chǔ)基礎(chǔ)數(shù)據(jù)資源池。仿真計(jì)算通過(guò)遙測(cè)實(shí)體數(shù)據(jù)對(duì)數(shù)字仿真模型進(jìn)行校準(zhǔn)。

可視化系統(tǒng)通過(guò)基礎(chǔ)數(shù)據(jù)資源池服務(wù)獲取仿真數(shù)據(jù)、實(shí)體特征參數(shù)、遙測(cè)實(shí)體數(shù)據(jù)等，并以三維、二維可視化方式推送給隨時(shí)接入的用戶。

想定設(shè)計(jì)、任務(wù)規(guī)劃是對(duì)未來(lái)的任務(wù)進(jìn)行設(shè)計(jì)和規(guī)劃管理，并將結(jié)果保存基礎(chǔ)數(shù)據(jù)資源池，同時(shí)疊加到正在實(shí)施運(yùn)行的仿真計(jì)算中。仿真計(jì)算允許用戶以超實(shí)時(shí)的方式推演預(yù)測(cè)未來(lái)情況。

評(píng)估分析，對(duì)規(guī)劃輸出的各個(gè)方案的推演結(jié)果進(jìn)行評(píng)估分析，在半人工參與的情況下確定優(yōu)選方案，通過(guò)指令生成模塊將方案以指令的方式推送給物理世界天基體系。

圖1 天基孿生體功能架構(gòu)

2.2 功能要求

所謂數(shù)據(jù)資源池，即數(shù)據(jù)提供者將分散的、異構(gòu)的數(shù)據(jù)資源合并到一起，以多租戶的方式提供給多個(gè)數(shù)據(jù)消費(fèi)者使用，根據(jù)消費(fèi)者的需求動(dòng)態(tài)接入所需的數(shù)據(jù)資源。資源位置對(duì)消費(fèi)者透明，消費(fèi)者無(wú)需了解所使用資源的確切位置、存儲(chǔ)形式?；诮y(tǒng)一的接口規(guī)范與數(shù)據(jù)資源交互。資源池具有資源取用便捷、彈性伸縮、靈活擴(kuò)展的特性。因此，對(duì)于大型復(fù)雜軟件系統(tǒng)設(shè)計(jì)而言，使用資源池的設(shè)計(jì)理念設(shè)計(jì)基礎(chǔ)數(shù)據(jù)服務(wù)層，是軟件行業(yè)的主流趨勢(shì)。本項(xiàng)目因此采用資源池理念設(shè)計(jì)了天基孿生體的基礎(chǔ)數(shù)據(jù)層，即基礎(chǔ)數(shù)據(jù)資源池。一方面使天基孿生體軟件在架構(gòu)上縱向的分層解耦，化簡(jiǎn)了設(shè)計(jì)開發(fā)實(shí)施難度；另一方面，為天基孿生體未來(lái)迭代發(fā)展提供具有前瞻性和先進(jìn)性的基礎(chǔ)層。

天基孿生體要求基礎(chǔ)數(shù)據(jù)資源池管理的數(shù)據(jù)主要包含仿真對(duì)象實(shí)體的特性參數(shù)信息、仿真過(guò)程實(shí)體特征參數(shù)信息、仿真過(guò)程實(shí)體輸出信息、實(shí)時(shí)遙測(cè)數(shù)據(jù)等多種信息。尤其是仿真過(guò)程實(shí)體輸出信息，大量精細(xì)化模型輸出的時(shí)間密度達(dá)到秒級(jí)的長(zhǎng)時(shí)序Log數(shù)據(jù)需要被存儲(chǔ)管理，同時(shí)還要向頂層功能提供高效的數(shù)據(jù)檢索服務(wù)，因此對(duì)于數(shù)據(jù)的存儲(chǔ)和檢索提出了高可用、高并發(fā)的要求。從存儲(chǔ)數(shù)據(jù)的格式方面看，天基孿生體要求基礎(chǔ)數(shù)據(jù)資源池管理的數(shù)據(jù)對(duì)象結(jié)構(gòu)是可定義可擴(kuò)展的，數(shù)據(jù)對(duì)象結(jié)構(gòu)會(huì)隨仿真模型、評(píng)估模型等要求的不同而變化。

綜上所述，仿真基礎(chǔ)數(shù)據(jù)資源池應(yīng)具備以下幾方面能力：

(1) 功能上對(duì)于存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)，具備可配置、易擴(kuò)展能力，并擁有通用化的數(shù)據(jù)訪問(wèn)接口；

(2) 性能上支持高并發(fā)數(shù)據(jù)的存儲(chǔ)；支持秒級(jí)的海量數(shù)據(jù)檢索；

(3) 架構(gòu)上支持可擴(kuò)展和高可用。

2.3 總體架構(gòu)設(shè)計(jì)

仿真基礎(chǔ)數(shù)據(jù)資源池系統(tǒng)可分為應(yīng)用層和基礎(chǔ)層兩部分：

(1) 應(yīng)用層是面向用戶提供交互處理功能模塊，包括元數(shù)據(jù)管理模塊、數(shù)據(jù)管理模塊、數(shù)據(jù)發(fā)布接口模塊、數(shù)據(jù)采集接口模塊；

(2) 基礎(chǔ)層是系統(tǒng)設(shè)計(jì)的核心，為展現(xiàn)層的各功能提供關(guān)鍵功能和基礎(chǔ)工具，關(guān)系型數(shù)據(jù)引擎(Mysql)、對(duì)象數(shù)據(jù)檢索引擎(ElasticSearch)、數(shù)據(jù)采集(Logstach)、消息隊(duì)列(Kafka)。

Mysql用來(lái)存儲(chǔ)管理元數(shù)據(jù)信息。ElasticSearch Cluster為數(shù)據(jù)管理及數(shù)據(jù)發(fā)布和檢索提供技術(shù)支撐。Logstach與Kafka結(jié)合在實(shí)現(xiàn)數(shù)據(jù)的采集功能。具體如圖2所示。

圖2 仿真基礎(chǔ)數(shù)據(jù)資源池系統(tǒng)架構(gòu)

ElasticSearch是一個(gè)能夠提供高并發(fā)、易擴(kuò)展、高可用的開源分布式搜索引擎，能夠?yàn)橄到y(tǒng)提供一個(gè)易于查詢和共享的接口，成為了企業(yè)級(jí)大數(shù)據(jù)存儲(chǔ)與檢索解決方案的關(guān)鍵工具[2]。另外，ElasticSearch是基于聲明的面向?qū)ο髷?shù)據(jù)結(jié)構(gòu)存儲(chǔ)引擎，在實(shí)現(xiàn)靈活的數(shù)據(jù)類型擴(kuò)展定義與管理方面有著先天的優(yōu)勢(shì)。ElasticSearch也具備關(guān)系型數(shù)據(jù)管理的特點(diǎn)[3]。其提供了多種方法用來(lái)實(shí)現(xiàn)在ElasticSearch中進(jìn)行關(guān)系型數(shù)據(jù)的管理。

綜上所述，本系統(tǒng)將ElasticSearch作為實(shí)現(xiàn)可配置、易擴(kuò)展數(shù)據(jù)管理和高性能數(shù)據(jù)發(fā)布功能的核心組件。并利用其提供的功能完備的JavaAPI進(jìn)行二次開發(fā)和封裝，實(shí)現(xiàn)了支撐數(shù)據(jù)管理、數(shù)據(jù)發(fā)布接口、數(shù)據(jù)采集接口功能模塊的基礎(chǔ)組件。

2.3.1 元數(shù)據(jù)管理模塊

元數(shù)據(jù)管理模塊，實(shí)現(xiàn)數(shù)據(jù)的可配置化管理和發(fā)布基本功能，并使系統(tǒng)具備第2.2節(jié)提及的能力1。系統(tǒng)在存入數(shù)據(jù)之前必須先要通過(guò)配置描述要存入數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。系統(tǒng)完成開發(fā)前無(wú)須確定需要管理的數(shù)據(jù)具體結(jié)構(gòu)。在系統(tǒng)功能正式部署后，可根據(jù)實(shí)際需要明確并配置數(shù)據(jù)結(jié)構(gòu)，實(shí)現(xiàn)數(shù)據(jù)的管理和發(fā)布。隨著需求對(duì)數(shù)據(jù)結(jié)構(gòu)更動(dòng)，用戶可通過(guò)元數(shù)據(jù)管理功能對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行更動(dòng)，形成新的數(shù)據(jù)結(jié)構(gòu)版本。用以滿足不斷更新的數(shù)據(jù)結(jié)構(gòu)需求。

該模塊主要包含數(shù)據(jù)類型管理功能和元數(shù)據(jù)配置功能。元數(shù)據(jù)信息管理模塊主要功能是查看系統(tǒng)所管理的所有數(shù)據(jù)類別信息。有多少種數(shù)據(jù)類別表示系統(tǒng)可以管理多少種數(shù)據(jù)。元數(shù)據(jù)配置功能主要功能是查看、創(chuàng)建、編輯某種數(shù)據(jù)類型的具體數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)通過(guò)Web表單設(shè)計(jì)器完成。表單設(shè)計(jì)器可將用戶設(shè)計(jì)的輸出物自動(dòng)分解為一張表單，一個(gè)表單草稿，一個(gè)數(shù)據(jù)結(jié)構(gòu)描述。

表單，是一個(gè)包含數(shù)據(jù)編輯控件和布局信息的HTML片段，用來(lái)提供人機(jī)界面的數(shù)據(jù)交互顯示。

表單草稿，是一個(gè)HTML片段，與表單結(jié)構(gòu)布局相同的，同時(shí)包含更多設(shè)計(jì)時(shí)標(biāo)簽，用來(lái)提供基于現(xiàn)有表單做進(jìn)一步元數(shù)據(jù)更動(dòng)的功能。更動(dòng)后的輸出物是該類型數(shù)據(jù)的下一版本。

數(shù)據(jù)結(jié)構(gòu)描述，是一個(gè)基于當(dāng)前表單HTML片段提取出的，可以以樹狀形式展現(xiàn)數(shù)據(jù)結(jié)構(gòu)的描述文檔。這里采用的是JSON格式，JSON文檔的節(jié)點(diǎn)包含數(shù)據(jù)類型(如：int、double、string、datetime等)、節(jié)點(diǎn)ID、節(jié)點(diǎn)名稱、界面控件類型等，為數(shù)據(jù)的管理提供必不可少的基礎(chǔ)信息。具體如表1所示。

為使系統(tǒng)具備高效的存儲(chǔ)檢索數(shù)據(jù)的能力，Mysql數(shù)據(jù)庫(kù)僅用來(lái)存儲(chǔ)元數(shù)據(jù)管理模塊相關(guān)的信息，并不存儲(chǔ)數(shù)據(jù)本身。為保證元數(shù)據(jù)與數(shù)據(jù)的對(duì)應(yīng)關(guān)系，元數(shù)據(jù)管理模塊基于ElasticSearch的Setting和Mapping API進(jìn)行擴(kuò)展開發(fā)實(shí)現(xiàn)了庫(kù)的索引的管理功能和數(shù)據(jù)結(jié)構(gòu)的設(shè)置功能組件，保證了兩庫(kù)間數(shù)據(jù)結(jié)構(gòu)定義的一致性和同步性。從數(shù)據(jù)表單設(shè)計(jì)到創(chuàng)建ElasticSearch索引的系統(tǒng)工作流程如圖3所示。

表1 數(shù)據(jù)結(jié)構(gòu)具體信息表

圖3 元數(shù)據(jù)配置信息處理流程

數(shù)據(jù)表單設(shè)計(jì)結(jié)果生成兩個(gè)輸出內(nèi)容：一是用于描述內(nèi)容展示布局的HTML片段；二是數(shù)據(jù)結(jié)構(gòu)樹JSON文檔。JSON文檔中的部分信息(name、valueType、format)可生成用來(lái)定義ElasticSearch索引創(chuàng)建所需的JSON文檔，該索引相關(guān)JSON可直接用來(lái)創(chuàng)建ElasticSearch索引并設(shè)置數(shù)據(jù)結(jié)構(gòu)。索引相關(guān)JSON主要包含兩部分信息，Setting和Mapping。Setting中包含索引分片和索引副本數(shù)量等。Mapping內(nèi)容是數(shù)據(jù)各屬性字段的描述信息，包括字段名、類型、格式等[4]。Mapping的設(shè)置有利于保障ElasticSearch檢索功能的正確性和執(zhí)行效率。

2.3.2 數(shù)據(jù)管理模塊

數(shù)據(jù)管理功能實(shí)現(xiàn)對(duì)數(shù)據(jù)輸入、查詢、編輯等管理，與元數(shù)據(jù)管理模塊結(jié)合，一起使系統(tǒng)具備第2.2節(jié)提及的能力1。本模塊是基于ElasticSearch的CRUD API擴(kuò)展開發(fā)實(shí)現(xiàn)的。該API屬于RESTful Web類型的接口，CRUD對(duì)應(yīng)為PUT、GET、POST、DELETE[5]。每個(gè)請(qǐng)求和響應(yīng)都是典型的JSON格式。數(shù)據(jù)管理功能操作表如表 2所示。

表2 數(shù)據(jù)管理功能操作表

2.3.3 數(shù)據(jù)發(fā)布接口模塊

數(shù)據(jù)發(fā)布接口模塊為平臺(tái)頂層功能提供數(shù)據(jù)查詢檢索手段，使系統(tǒng)具備第2.2節(jié)提及的能力2。由于平臺(tái)要求數(shù)據(jù)資源池存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)是靈活的、可配置的，為適應(yīng)查詢檢索要求，系統(tǒng)必須提供一套完善的適用于查詢各種數(shù)據(jù)結(jié)構(gòu)的輕量化外部接口，方便多個(gè)外部功能的接入和數(shù)據(jù)查詢。經(jīng)綜合考慮，利用ElasticSearch的檢索數(shù)據(jù)方面的優(yōu)勢(shì)，將其檢索API進(jìn)行封裝開發(fā)，對(duì)外使用RESTful接口形式暴露出Search API[6]。封裝后的數(shù)據(jù)服務(wù)為平臺(tái)的頂層應(yīng)用提供兩種數(shù)據(jù)查詢檢索接口使用模式。以仿真遙測(cè)數(shù)據(jù)為例。它是一種典型的JSON文檔，包含的key有title、satId、info等，如圖4所示。其查詢語(yǔ)法具體如表 4所示。

圖4 仿真遙測(cè)數(shù)據(jù)樣例

表3 數(shù)據(jù)發(fā)布接口查詢功能表

根據(jù)表3所示，第1種查詢方式是通過(guò)URL參數(shù)構(gòu)造查詢條件，并通過(guò)GET方式向服務(wù)器提交查詢請(qǐng)求。第2種查詢方式使用JSON文檔定義查詢規(guī)則，并將JSON文檔基于Body體發(fā)送給服務(wù)器。很明顯，第2種基于Body體發(fā)送查詢規(guī)則請(qǐng)求提供更加豐富的查詢方法。外部系統(tǒng)查詢數(shù)據(jù)時(shí)，對(duì)于簡(jiǎn)單查詢可以使用第一種URI Search查詢方式，對(duì)于復(fù)雜規(guī)則查詢則需要使用Request Body Search查詢方式。

2.3.4 數(shù)據(jù)采集接口模塊

數(shù)據(jù)采集接口模塊主要是為平臺(tái)頂層功能提供高效可靠的數(shù)據(jù)存儲(chǔ)功能，即具備第2.2節(jié)提及的能力3。平臺(tái)產(chǎn)生的數(shù)據(jù)特點(diǎn)是總體數(shù)據(jù)量大、存儲(chǔ)請(qǐng)求密集、實(shí)時(shí)性高、水平可擴(kuò)展的特點(diǎn)。為適應(yīng)該特點(diǎn)，需要在ElasticSearch基礎(chǔ)上引入兩個(gè)工具，一個(gè)是Kafka，另一個(gè)是Logstash。

Apache Kafka是用scala語(yǔ)言實(shí)現(xiàn)的一個(gè)分布式消息隊(duì)列工具，使用zookeeper進(jìn)行集群的管理。Kafka采用解耦的設(shè)計(jì)思想，并基于非原始的發(fā)布訂閱邏輯，生產(chǎn)者負(fù)責(zé)產(chǎn)生數(shù)據(jù)，直接推送給消費(fèi)者。而是在中間加入持久化層——broker，生產(chǎn)者把數(shù)據(jù)存放在broker中，消費(fèi)者從broker中取數(shù)據(jù)[7]。這樣就帶來(lái)了幾個(gè)好處：

(1)生產(chǎn)者的負(fù)載與消費(fèi)者的負(fù)載解耦；

(2)消費(fèi)者按照自己的能力讀取數(shù)據(jù)；

(3)消費(fèi)者可以自定義消費(fèi)的數(shù)量。

另外，由于Kafka采用了基于主題(topic)分區(qū)的思想，使得某個(gè)分區(qū)內(nèi)部的順序可以保證有序性。這樣，不同的生產(chǎn)者和消費(fèi)者可以以分區(qū)為單位，約定讀取數(shù)據(jù)的位置。

Logstash是一個(gè)高性能數(shù)據(jù)處理管道，能夠同時(shí)從多個(gè)來(lái)源采集數(shù)據(jù)，并進(jìn)行自定的轉(zhuǎn)換處理，然后將數(shù)據(jù)發(fā)送到指定的目標(biāo)位置[8]。當(dāng)然，這里定義的目標(biāo)位置是ElasticSearch。

數(shù)據(jù)采集接口模塊完整的數(shù)據(jù)處理過(guò)程如圖5所示。

圖5 大并發(fā)數(shù)據(jù)處理流程圖

首先仿真各實(shí)體輸出的數(shù)據(jù)依據(jù)Kafka的topics(主題)分區(qū)傳入Kafka中緩存，Logstash按照自身配置文件的input(輸入)節(jié)點(diǎn)的約定從多個(gè)Kafka的多個(gè)topics分區(qū)中獲取type(類型)各異的數(shù)據(jù)，經(jīng)過(guò)轉(zhuǎn)換、過(guò)濾等處理后形成約定格式的數(shù)據(jù)，output(輸出)根據(jù)type配置輸出并存入到ElasticSearch的不同index中，共查詢分析所用。

3 測(cè)試結(jié)果

測(cè)試使用的環(huán)境條件如下，ElasticSearch集群使用3節(jié)點(diǎn)，kafka集群使用1節(jié)點(diǎn)，服務(wù)器CPU配置為Intel Xeon X5675 3 GHz 2顆, 內(nèi)存為 16 G，硬盤500 G。為了與傳統(tǒng)體系效能仿真平臺(tái)的基礎(chǔ)數(shù)據(jù)資源管理功能的性能進(jìn)行比較，使用相同配置的物理服務(wù)器進(jìn)行部署測(cè)試。

3.1 并發(fā)檢索性能測(cè)試

使用500萬(wàn)條仿真過(guò)程數(shù)據(jù)進(jìn)行測(cè)試，測(cè)試工具為 VS12LoadTest，模擬300用戶并發(fā)訪問(wèn)條件下測(cè)試系統(tǒng)的請(qǐng)求處理和響應(yīng)的能力。測(cè)試過(guò)程采樣時(shí)間間隔為6 s，持續(xù)時(shí)間為5 min。每個(gè)用戶使用從20個(gè)屬性中隨機(jī)選擇一個(gè)后再和創(chuàng)建時(shí)間屬性的隨機(jī)時(shí)間范圍進(jìn)行組合檢索。測(cè)試結(jié)果如圖6所示。仿真基礎(chǔ)數(shù)據(jù)資源池系統(tǒng)的平均檢索請(qǐng)求處理時(shí)間為570 ms，較傳統(tǒng)仿真數(shù)據(jù)資源管理系統(tǒng)6.95 s的數(shù)據(jù)檢索能力，性能提升10倍左右。

表4為并發(fā)檢索性能測(cè)試結(jié)果對(duì)比圖的說(shuō)明。

圖6 并發(fā)檢索性能測(cè)試結(jié)果對(duì)比圖

3.2 數(shù)據(jù)采集測(cè)試

數(shù)據(jù)采集能力測(cè)試使用PDI工具，將仿真過(guò)程數(shù)據(jù)寫入系統(tǒng)，總數(shù)據(jù)量500萬(wàn)行，共1.35 Gb，平均處理速率3.2萬(wàn)行/s，總耗時(shí)156 s。較傳統(tǒng)仿真數(shù)據(jù)處理系統(tǒng)的0.68萬(wàn)行/s的速率，提升近5倍。

表4 并發(fā)檢索性能測(cè)試結(jié)果表

4 結(jié)束語(yǔ)

傳統(tǒng)天基體系效能仿真平臺(tái)的數(shù)據(jù)資源管理系統(tǒng)的性能已成為影響體系仿真向深度和廣度發(fā)展的主要瓶頸。通過(guò)介紹天基孿生體的總體功能架構(gòu)，引出了其對(duì)基礎(chǔ)數(shù)據(jù)資源服務(wù)技術(shù)要求，包括海量數(shù)據(jù)管理、高并發(fā)數(shù)據(jù)處理與檢索、數(shù)據(jù)類型易擴(kuò)展等。進(jìn)而，本文提出了一種新的支撐天基孿生體的分布式數(shù)據(jù)存儲(chǔ)管理系統(tǒng)——仿真基礎(chǔ)數(shù)據(jù)資源池。通過(guò)研究ElasticSearch索引服務(wù)的數(shù)據(jù)存儲(chǔ)與檢索優(yōu)化方案，Kafka消息隊(duì)列解耦工作原理，以及Logstash高效數(shù)據(jù)處理方法，設(shè)計(jì)了適合天基孿生體頂層業(yè)務(wù)應(yīng)用的仿真過(guò)程數(shù)據(jù)存儲(chǔ)模型，開發(fā)了元數(shù)據(jù)管理、數(shù)據(jù)管理、數(shù)據(jù)發(fā)布接口、數(shù)據(jù)采集接口四個(gè)重要組件，建立了以ElasticSearch為核心組件的滿足支持高并發(fā)數(shù)據(jù)的存儲(chǔ)和秒級(jí)的海量數(shù)據(jù)檢索要求的分布式數(shù)據(jù)系統(tǒng)。使系統(tǒng)的數(shù)據(jù)存儲(chǔ)檢索服務(wù)能力較傳統(tǒng)數(shù)據(jù)管理系統(tǒng)得到明顯提升，為天基孿生體項(xiàng)目奠定了可靠的技術(shù)基礎(chǔ)。