一種構建高性能仿真基礎數據資源池的方法 ①

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

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

0 引言

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

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

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

1 傳統數據資源管理和使用方式

體系效能仿真平臺傳統方式的數據資源管理功能是以關系型數據庫工具為基礎，使用表單應用系統作為結構化數據的管理和維護的人機交互界面，使用數據庫視圖、Web服務等方式實現對平臺頂層功能的發布。主要包括數據存儲功能、數據管理功能、數據發布接口三部分。

數據管理功能方面，一般是由想定、規劃、仿真等頂層功能要求決定。然而不同要求的場景對仿真想定的數據模型結構和精細化程度各不相同，且很難在軟件的開發階段就將需要的各類數據模型結構和要管理的數據完整清晰地提出。因此，數據管理功能開發常會出現問題，如數據需求不斷變化導致數據管理功能的代碼不斷更動，項目周期難控，軟件技術狀態難控。

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

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

2 仿真基礎數據資源池設計

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

天基孿生體功能架構如圖 1 所示。

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

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

(2)基礎資源池：提供統一的數據資源服務，集中管理空間環境、實體特征參數、仿真實體數據、遙測實體數據、實體已有計劃任務、疊加/應急任務信息等。

仿真計算在基礎數據資源池服務的支撐下，以實時的方式不間斷仿真推演，并再現物理世界天基的系統結構、過程數據、行為等。并將仿真結果存儲基礎數據資源池。仿真計算通過遙測實體數據對數字仿真模型進行校準。

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

想定設計、任務規劃是對未來的任務進行設計和規劃管理，并將結果保存基礎數據資源池，同時疊加到正在實施運行的仿真計算中。仿真計算允許用戶以超實時的方式推演預測未來情況。

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

圖1 天基孿生體功能架構

2.2 功能要求

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

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

綜上所述，仿真基礎數據資源池應具備以下幾方面能力：

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

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

(3) 架構上支持可擴展和高可用。

2.3 總體架構設計

仿真基礎數據資源池系統可分為應用層和基礎層兩部分：

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

(2) 基礎層是系統設計的核心，為展現層的各功能提供關鍵功能和基礎工具，關系型數據引擎(Mysql)、對象數據檢索引擎(ElasticSearch)、數據采集(Logstach)、消息隊列(Kafka)。

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

圖2 仿真基礎數據資源池系統架構

ElasticSearch是一個能夠提供高并發、易擴展、高可用的開源分布式搜索引擎，能夠為系統提供一個易于查詢和共享的接口，成為了企業級大數據存儲與檢索解決方案的關鍵工具[2]。另外，ElasticSearch是基于聲明的面向對象數據結構存儲引擎，在實現靈活的數據類型擴展定義與管理方面有著先天的優勢。ElasticSearch也具備關系型數據管理的特點[3]。其提供了多種方法用來實現在ElasticSearch中進行關系型數據的管理。

綜上所述，本系統將ElasticSearch作為實現可配置、易擴展數據管理和高性能數據發布功能的核心組件。并利用其提供的功能完備的JavaAPI進行二次開發和封裝，實現了支撐數據管理、數據發布接口、數據采集接口功能模塊的基礎組件。

2.3.1 元數據管理模塊

元數據管理模塊，實現數據的可配置化管理和發布基本功能，并使系統具備第2.2節提及的能力1。系統在存入數據之前必須先要通過配置描述要存入數據的數據結構。系統完成開發前無須確定需要管理的數據具體結構。在系統功能正式部署后，可根據實際需要明確并配置數據結構，實現數據的管理和發布。隨著需求對數據結構更動，用戶可通過元數據管理功能對數據結構進行更動，形成新的數據結構版本。用以滿足不斷更新的數據結構需求。

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

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

表單草稿，是一個HTML片段，與表單結構布局相同的，同時包含更多設計時標簽，用來提供基于現有表單做進一步元數據更動的功能。更動后的輸出物是該類型數據的下一版本。

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

為使系統具備高效的存儲檢索數據的能力，Mysql數據庫僅用來存儲元數據管理模塊相關的信息，并不存儲數據本身。為保證元數據與數據的對應關系，元數據管理模塊基于ElasticSearch的Setting和Mapping API進行擴展開發實現了庫的索引的管理功能和數據結構的設置功能組件，保證了兩庫間數據結構定義的一致性和同步性。從數據表單設計到創建ElasticSearch索引的系統工作流程如圖3所示。

表1 數據結構具體信息表

圖3 元數據配置信息處理流程

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

2.3.2 數據管理模塊

數據管理功能實現對數據輸入、查詢、編輯等管理，與元數據管理模塊結合，一起使系統具備第2.2節提及的能力1。本模塊是基于ElasticSearch的CRUD API擴展開發實現的。該API屬于RESTful Web類型的接口，CRUD對應為PUT、GET、POST、DELETE[5]。每個請求和響應都是典型的JSON格式。數據管理功能操作表如表 2所示。

表2 數據管理功能操作表

2.3.3 數據發布接口模塊

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

圖4 仿真遙測數據樣例

表3 數據發布接口查詢功能表

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

2.3.4 數據采集接口模塊

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

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

(1)生產者的負載與消費者的負載解耦；

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

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

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

Logstash是一個高性能數據處理管道，能夠同時從多個來源采集數據，并進行自定的轉換處理，然后將數據發送到指定的目標位置[8]。當然，這里定義的目標位置是ElasticSearch。

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

圖5 大并發數據處理流程圖

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

3 測試結果

測試使用的環境條件如下，ElasticSearch集群使用3節點，kafka集群使用1節點，服務器CPU配置為Intel Xeon X5675 3 GHz 2顆, 內存為 16 G，硬盤500 G。為了與傳統體系效能仿真平臺的基礎數據資源管理功能的性能進行比較，使用相同配置的物理服務器進行部署測試。

3.1 并發檢索性能測試

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

表4為并發檢索性能測試結果對比圖的說明。

圖6 并發檢索性能測試結果對比圖

3.2 數據采集測試

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

表4 并發檢索性能測試結果表

4 結束語

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