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

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

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

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 功能要求

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

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

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

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

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

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

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

仿真基礎(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è)計的核心，為展現(xiàn)層的各功能提供關(guān)鍵功能和基礎(chǔ)工具，關(guān)系型數(shù)據(jù)引擎(Mysql)、對象數(shù)據(jù)檢索引擎(ElasticSearch)、數(shù)據(jù)采集(Logstach)、消息隊列(Kafka)。

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

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

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

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

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

元數(shù)據(jù)管理模塊，實現(xiàn)數(shù)據(jù)的可配置化管理和發(fā)布基本功能，并使系統(tǒng)具備第2.2節(jié)提及的能力1。系統(tǒng)在存入數(shù)據(jù)之前必須先要通過配置描述要存入數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。系統(tǒng)完成開發(fā)前無須確定需要管理的數(shù)據(jù)具體結(jié)構(gòu)。在系統(tǒng)功能正式部署后，可根據(jù)實際需要明確并配置數(shù)據(jù)結(jié)構(gòu)，實現(xiàn)數(shù)據(jù)的管理和發(fā)布。隨著需求對數(shù)據(jù)結(jié)構(gòu)更動，用戶可通過元數(shù)據(jù)管理功能對數(shù)據(jù)結(jié)構(gòu)進(jìn)行更動，形成新的數(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è)計通過Web表單設(shè)計器完成。表單設(shè)計器可將用戶設(shè)計的輸出物自動分解為一張表單，一個表單草稿，一個數(shù)據(jù)結(jié)構(gòu)描述。

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

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

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

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

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

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

數(shù)據(jù)表單設(shè)計結(jié)果生成兩個輸出內(nèi)容：一是用于描述內(nèi)容展示布局的HTML片段；二是數(shù)據(jù)結(jié)構(gòu)樹JSON文檔。JSON文檔中的部分信息(name、valueType、format)可生成用來定義ElasticSearch索引創(chuàng)建所需的JSON文檔，該索引相關(guān)JSON可直接用來創(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ù)管理功能實現(xiàn)對數(shù)據(jù)輸入、查詢、編輯等管理，與元數(shù)據(jù)管理模塊結(jié)合，一起使系統(tǒng)具備第2.2節(jié)提及的能力1。本模塊是基于ElasticSearch的CRUD API擴(kuò)展開發(fā)實現(xiàn)的。該API屬于RESTful Web類型的接口，CRUD對應(yīng)為PUT、GET、POST、DELETE[5]。每個請求和響應(yīng)都是典型的JSON格式。數(shù)據(jù)管理功能操作表如表 2所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 測試結(jié)果

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

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

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

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

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

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

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

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

4 結(jié)束語

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