面向裝備試驗(yàn)數(shù)據(jù)的融合存儲(chǔ)技術(shù)研究與應(yīng)用

曹芳芳, 任慧敏, 上官子糧, 丁派克

(北京航天自動(dòng)控制研究所, 北京 100076)

0 引言(Introduction)

隨著信息化技術(shù)的發(fā)展,融合存儲(chǔ)技術(shù)在各行各業(yè)中被大范圍應(yīng)用。數(shù)據(jù)融合存儲(chǔ)技術(shù)包括對(duì)各種信息源數(shù)據(jù)的采集、傳輸、處理、校核及存儲(chǔ)。數(shù)據(jù)融合存儲(chǔ)技術(shù)主要應(yīng)用領(lǐng)域有多源影像復(fù)合、機(jī)器人和智能儀器系統(tǒng)、戰(zhàn)場(chǎng)和無人駕駛飛機(jī)、圖像分析與理解、目標(biāo)檢測(cè)與跟蹤、自動(dòng)目標(biāo)識(shí)別等。

近年來,裝備信息化、智能化技術(shù)發(fā)展迅速,航天產(chǎn)品在設(shè)計(jì)、生產(chǎn)、試驗(yàn)、交付等各個(gè)階段產(chǎn)生了大規(guī)模的試驗(yàn)數(shù)據(jù),這些數(shù)據(jù)分散存儲(chǔ)在各系統(tǒng)中,種類龐雜、數(shù)據(jù)量巨大、存儲(chǔ)與管理困難。由于各種智能設(shè)備的信息化水平參差不齊,功能各異,彼此之間相互獨(dú)立,因此存在試驗(yàn)數(shù)據(jù)來源多樣化、數(shù)據(jù)格式多樣化、數(shù)據(jù)存儲(chǔ)位置越來越離散化等特點(diǎn),導(dǎo)致嚴(yán)重的信息孤島現(xiàn)象。

由于試驗(yàn)數(shù)據(jù)缺少統(tǒng)一的標(biāo)準(zhǔn)、規(guī)范,所以數(shù)據(jù)格式和數(shù)據(jù)內(nèi)容差異很大,不同業(yè)務(wù)場(chǎng)景對(duì)數(shù)據(jù)的消費(fèi)和應(yīng)用也不同,對(duì)數(shù)據(jù)的存儲(chǔ)與管理和共享使用帶來很多困難。為消除數(shù)據(jù)割裂局面,解決現(xiàn)有數(shù)據(jù)積累、存儲(chǔ)管理、檢索查詢、協(xié)同復(fù)用等問題,試驗(yàn)數(shù)據(jù)的融合存儲(chǔ)與管理已成為當(dāng)前迫切要解決的問題[1]。

1 研究思路(Research ideas)

目前,數(shù)據(jù)融合存儲(chǔ)的思路是把不同來源、格式、特點(diǎn)的數(shù)據(jù)在邏輯上或物理上有機(jī)地集中起來,從而提供全面的數(shù)據(jù)共享。這些數(shù)據(jù)管理方法通常只針對(duì)特定的數(shù)據(jù)類型和數(shù)據(jù)應(yīng)用場(chǎng)景,數(shù)據(jù)的讀取方式和數(shù)據(jù)服務(wù)都比較單一,無法提供統(tǒng)一的數(shù)據(jù)接口和數(shù)據(jù)服務(wù)標(biāo)準(zhǔn)。對(duì)于航天裝備系統(tǒng)而言,需要對(duì)試驗(yàn)數(shù)據(jù)進(jìn)行重新組織和連接,擁有清晰的數(shù)據(jù)標(biāo)準(zhǔn)接口和結(jié)構(gòu),在保證數(shù)據(jù)一致性和安全的前提下,讓數(shù)據(jù)更易獲取,最終打破數(shù)據(jù)應(yīng)用間的數(shù)據(jù)孤島。

裝備試驗(yàn)數(shù)據(jù)從結(jié)構(gòu)上劃分為結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)。從數(shù)據(jù)類型上劃分為二進(jìn)制數(shù)據(jù)流、數(shù)據(jù)庫文件、圖像、音視頻類等數(shù)據(jù)文件。對(duì)于不同的數(shù)據(jù)類型,構(gòu)建數(shù)據(jù)業(yè)務(wù)寬表,對(duì)接不同數(shù)據(jù)源;通過數(shù)據(jù)源插件配置管理的方式,實(shí)現(xiàn)對(duì)多來源數(shù)據(jù)的智能匹配和接入;針對(duì)海量數(shù)據(jù)的快速處理要求,基于Spark(ApacheSpark是專為大規(guī)模數(shù)據(jù)處理而設(shè)計(jì)的快速通用的計(jì)算引擎)的優(yōu)秀資源調(diào)度能力結(jié)合集群的計(jì)算能力實(shí)現(xiàn)在多源異構(gòu)的采集場(chǎng)景下的分布式數(shù)據(jù)快速處理[2];針對(duì)多類型數(shù)據(jù)的檢索訪問問題,通過倒排索引機(jī)制實(shí)現(xiàn)海量數(shù)據(jù)文件的快速檢索[3];通過數(shù)據(jù)分析接口的設(shè)計(jì)將數(shù)據(jù)應(yīng)用與平臺(tái)進(jìn)行剝離,對(duì)外釋放數(shù)據(jù)服務(wù)接口,通過服務(wù)注冊(cè)的模式完成對(duì)數(shù)據(jù)業(yè)務(wù)的部署和應(yīng)用,確保業(yè)務(wù)的可擴(kuò)展、可發(fā)展。試驗(yàn)數(shù)據(jù)融合存儲(chǔ)技術(shù)的總體設(shè)計(jì)思路如圖1所示。

圖1 總體設(shè)計(jì)思路Fig.1 Overall design idea

平臺(tái)融合多種類型數(shù)據(jù)庫作為多源異構(gòu)試驗(yàn)數(shù)據(jù)的存儲(chǔ)底座,包括關(guān)系型數(shù)據(jù)庫、時(shí)序數(shù)據(jù)庫、HBase(Hadoop數(shù)據(jù)庫)、分布式文件系統(tǒng),面向不同的數(shù)據(jù)源智能匹配數(shù)據(jù)入庫方式。將分散的裝備實(shí)測(cè)數(shù)據(jù)、試驗(yàn)數(shù)據(jù)、仿真數(shù)據(jù)、地理環(huán)境信息數(shù)據(jù)等數(shù)據(jù)信息進(jìn)行統(tǒng)一的存儲(chǔ)、管理和維護(hù)。

2 試驗(yàn)數(shù)據(jù)融合存儲(chǔ)技術(shù)研究(Research on experimental data fusion storage technology)

對(duì)于多來源試驗(yàn)數(shù)據(jù)的采集接入需求,梳理當(dāng)前裝備存儲(chǔ)設(shè)備的采集協(xié)議和方式,將設(shè)備IP信息、采集協(xié)議、用戶名權(quán)限等信息以配置文件的方式進(jìn)行存儲(chǔ)和加載,增強(qiáng)代碼的復(fù)用性。針對(duì)各類數(shù)據(jù)源不同的底層接口,面向用戶提供基于流程選擇的統(tǒng)一接口,采用多線程方式完成多來源數(shù)據(jù)的并發(fā)采集。對(duì)于規(guī)格化的試驗(yàn)數(shù)據(jù)通過適配關(guān)系型數(shù)據(jù)源插件自動(dòng)提交入庫任務(wù),對(duì)于非規(guī)格化的數(shù)據(jù)庫文件,適配非結(jié)構(gòu)化的數(shù)據(jù)源插件,提交加載任務(wù)。為使用者提供簡(jiǎn)化、統(tǒng)一的人機(jī)交互操作方式,實(shí)現(xiàn)一鍵獲取數(shù)據(jù)、一鍵下載數(shù)據(jù)、一鍵自動(dòng)加載數(shù)據(jù)源。

2.1 數(shù)據(jù)源插件技術(shù)研究

針對(duì)結(jié)構(gòu)化試驗(yàn)數(shù)據(jù),采用關(guān)系型數(shù)據(jù)庫存儲(chǔ)信息數(shù)據(jù)、基礎(chǔ)信息數(shù)據(jù)、基礎(chǔ)模型數(shù)據(jù)、仿真試驗(yàn)數(shù)據(jù)等。針對(duì)非結(jié)構(gòu)化數(shù)據(jù),采用分布式列數(shù)據(jù)庫和分布式文件系統(tǒng)進(jìn)行統(tǒng)一的存儲(chǔ)[4-6]。由于裝備系統(tǒng)的自主可控要求,試驗(yàn)數(shù)據(jù)融合存儲(chǔ)平臺(tái)要求兼容國(guó)產(chǎn)平臺(tái),而國(guó)產(chǎn)服務(wù)器的計(jì)算性能和網(wǎng)絡(luò)數(shù)據(jù)傳輸速度等比X86架構(gòu)的進(jìn)口服務(wù)器性能差,因此需提供一種高可靠性的分布式數(shù)據(jù)存儲(chǔ)方案應(yīng)對(duì)海量半結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)需求。本文選擇將分布式列數(shù)據(jù)庫HBase和HDFS(Hadoop分布式文件系統(tǒng))構(gòu)成分布式文件存儲(chǔ)系統(tǒng),其中HBase是一種高可靠性、高性能、面向列、可伸縮、能實(shí)時(shí)讀寫的分布式存儲(chǔ)系統(tǒng),利用HBase的高可靠性存儲(chǔ)技術(shù)可以在普通的PC Server上搭建大規(guī)模結(jié)構(gòu)化存儲(chǔ)集群。

面向上述多種類型的數(shù)據(jù)庫,本文設(shè)計(jì)了數(shù)據(jù)源插件技術(shù)實(shí)現(xiàn)新數(shù)據(jù)源的注冊(cè)、發(fā)現(xiàn)和適配運(yùn)行。數(shù)據(jù)源插件是基于Java SPI(Service Provider Interface)技術(shù),封裝統(tǒng)一的數(shù)據(jù)源驅(qū)動(dòng)接口,完成新增數(shù)據(jù)源的開發(fā)適配,實(shí)現(xiàn)動(dòng)態(tài)新增數(shù)據(jù)源。數(shù)據(jù)源插件工作過程示意圖如圖2所示。

圖2 數(shù)據(jù)源插件工作過程示意圖Fig.2 Schematic diagram of working process of data source plug-in

基于控制反轉(zhuǎn)機(jī)制,將數(shù)據(jù)源與數(shù)據(jù)庫驅(qū)動(dòng)包進(jìn)行隔離,保證新增數(shù)據(jù)源與已適配的數(shù)據(jù)源鏈接方式、驅(qū)動(dòng)包、驅(qū)動(dòng)類名稱等兼容。

當(dāng)多客戶端重復(fù)請(qǐng)求加載插件時(shí),為避免網(wǎng)絡(luò)高頻占用,采用本地緩存的方式,首次加載插件時(shí)先查看服務(wù)器本地文件夾下是否有對(duì)應(yīng)的插件,如果沒有則通過遠(yuǎn)程調(diào)用請(qǐng)求文件中心的接口,將對(duì)應(yīng)插件下載并緩存到本地。如果本地發(fā)現(xiàn)已有對(duì)應(yīng)插件,但為了避免插件的替換熱部署導(dǎo)致現(xiàn)場(chǎng)版本不是最新的插件,此時(shí)會(huì)對(duì)比緩存區(qū)的插件的MD5碼和插件數(shù)據(jù)庫中的MD5碼,保證插件是最新的版本。數(shù)據(jù)源插件更新流程圖如圖3所示。

圖3 數(shù)據(jù)源插件更新流程圖Fig.3 Flow chart of data source plug-in

面向不同屬性的數(shù)據(jù)源類型分別接入異構(gòu)數(shù)據(jù)庫,并根據(jù)屬性配置形成不同的數(shù)據(jù)索引主題,便于數(shù)據(jù)的檢索。

2.2 分布式采集處理技術(shù)

傳統(tǒng)的Java數(shù)據(jù)庫連接(Java Database Connect,JDBC)數(shù)據(jù)采集,在讀取大數(shù)據(jù)量時(shí),效率低下,需要將數(shù)據(jù)全部讀取到內(nèi)存,可能會(huì)出現(xiàn)內(nèi)存溢出,導(dǎo)致采集失敗的情況,嚴(yán)重時(shí)會(huì)導(dǎo)致程序異常退出。同時(shí),由于它只能通過單節(jié)點(diǎn)、單線程的方式進(jìn)行數(shù)據(jù)處理,所以對(duì)集群的資源利用率偏低,不能充分利用CPU資源,已經(jīng)不能滿足多源異構(gòu)數(shù)據(jù)源采集的業(yè)務(wù)場(chǎng)景和性能要求。

Spark的優(yōu)秀資源調(diào)度能力結(jié)合集群的計(jì)算能力,更適合多源異構(gòu)數(shù)據(jù)源的采集處理場(chǎng)景[7-8]。本文采用Spark技術(shù)實(shí)現(xiàn)多源異構(gòu)數(shù)據(jù)源的采集處理,其采集處理過程如圖4所示。

圖4 Spark采集處理流程圖Fig.4 Flow chart of Spark collection and processing

利用Spark的分布式處理能力,通過多個(gè)執(zhí)行節(jié)點(diǎn)批量讀取數(shù)據(jù)和處理任務(wù),有效提高數(shù)據(jù)的處理能力。Spark內(nèi)部會(huì)根據(jù)數(shù)據(jù)處理任務(wù),構(gòu)造有向無環(huán)圖,并劃分成不同階段,再劃分為不同的任務(wù),最后將任務(wù)分發(fā)到不同的執(zhí)行節(jié)點(diǎn)上執(zhí)行,實(shí)現(xiàn)了大數(shù)據(jù)量的分而治之。每個(gè)執(zhí)行節(jié)點(diǎn)還可以分配多個(gè)線程,采用多線程處理數(shù)據(jù),充分利用集群的優(yōu)勢(shì)將每個(gè)節(jié)點(diǎn)的CPU充分利用起來。

2.3 海量數(shù)據(jù)文件檢索技術(shù)研究

常見的Google、百度等網(wǎng)站的搜索都是根據(jù)網(wǎng)頁中的關(guān)鍵字生成索引,在搜索時(shí)輸入關(guān)鍵字,將該關(guān)鍵字匹配到所有網(wǎng)頁后返回信息流。傳統(tǒng)的數(shù)據(jù)庫全文檢索需要掃描整個(gè)表,如果數(shù)據(jù)量大就會(huì)出現(xiàn)卡滯、緩慢甚至檢索失敗的情況,即使建立了索引庫,維護(hù)成本也很高,對(duì)于insert和update操作都需要重新構(gòu)建索引[9]。所以,對(duì)于裝備非結(jié)構(gòu)化試驗(yàn)數(shù)據(jù)采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫和常規(guī)全文搜索方式已無法滿足其性能要求。

為了解決裝備結(jié)構(gòu)化數(shù)據(jù)搜索和非結(jié)構(gòu)化數(shù)據(jù)搜索性能問題,需要采用更適合裝備試驗(yàn)數(shù)據(jù)特點(diǎn),更加健壯、強(qiáng)大的全文搜索方式。本文引入ElasticSearch(數(shù)據(jù)搜索分析引擎)的倒排索引機(jī)制加速文件的檢索速度。倒排索引是以分詞的方式支持快速模糊查詢,以分詞內(nèi)存化的方式加速查詢速度。適合倒排索引方式的數(shù)據(jù)特點(diǎn)主要如下:①搜索的數(shù)據(jù)對(duì)象是大量非結(jié)構(gòu)化的文本數(shù)據(jù);②文件記錄量達(dá)到數(shù)十萬個(gè)或數(shù)百萬個(gè)甚至更多;③支持大量基于交互式文本的查詢;④需求非常靈活的全文搜索查詢;⑤對(duì)不同記錄類型、非文本數(shù)據(jù)操作或安全事務(wù)處理的需求相對(duì)較少的情況。倒排索引的方式與裝備海量數(shù)據(jù)文件的精確和模糊檢索場(chǎng)景非常契合。海量數(shù)據(jù)文件檢索原理圖如圖5所示。

圖5 海量數(shù)據(jù)文件檢索原理圖Fig.5 Principle diagram of mass data file retrieval

當(dāng)一個(gè)查詢被觸發(fā),所有已知的數(shù)據(jù)段將按順序被查詢,單詞統(tǒng)計(jì)模塊會(huì)對(duì)所有段的結(jié)果進(jìn)行聚合,以保證每個(gè)詞和每個(gè)文檔的關(guān)聯(lián)都被準(zhǔn)確計(jì)算,而不需要對(duì)數(shù)據(jù)庫中所有的數(shù)據(jù)內(nèi)容進(jìn)行過濾查詢,可有效提升數(shù)據(jù)的查詢速度。當(dāng)有新的數(shù)據(jù)寫入索引時(shí),單詞統(tǒng)計(jì)模塊會(huì)根據(jù)業(yè)務(wù)進(jìn)行詞劃分,不同的關(guān)鍵詞對(duì)應(yīng)不同的數(shù)據(jù)ID,并同步增加詞頻統(tǒng)計(jì)值。采用這種倒排索引可有效降低新文檔添加到索引庫的難度。

2.4 數(shù)據(jù)分析接口設(shè)計(jì)研究

數(shù)據(jù)分析接口是響應(yīng)數(shù)據(jù)接口指令并提供數(shù)據(jù)業(yè)務(wù)的邏輯處理過程。通過數(shù)據(jù)接口封裝保證了數(shù)據(jù)平臺(tái)與業(yè)務(wù)之間的剝離,便于業(yè)務(wù)的拓展和開發(fā)。在分析用戶的使用場(chǎng)景后,本系統(tǒng)對(duì)外提供的數(shù)據(jù)接口主要有JDBC接口、Restful接口、SDK接口。其中,JDBC接口提供SQL語句化的數(shù)據(jù)檢索處理方式;Restful接口是基于Http協(xié)議的標(biāo)準(zhǔn)化數(shù)據(jù)分析接口;SDK接口是為上層應(yīng)用服務(wù)提供API函數(shù)接口和基本的數(shù)值計(jì)算接口。

2.4.1 JDBC接口的設(shè)計(jì)與實(shí)現(xiàn)

解析用戶的數(shù)據(jù)檢索指令,將其標(biāo)準(zhǔn)化為類SQL查詢語句。通過標(biāo)準(zhǔn)化的類SQL查詢語句從索引數(shù)據(jù)庫中抽取對(duì)應(yīng)的數(shù)據(jù)信息,將索引信息與數(shù)據(jù)內(nèi)容進(jìn)行對(duì)應(yīng),完成數(shù)據(jù)的提取和反饋。SQL數(shù)據(jù)流處理過程示意圖如圖6所示。

圖6 SQL數(shù)據(jù)流處理過程Fig.6 The diagram of the SQL data flow process

2.4.2 Restful接口的設(shè)計(jì)與實(shí)現(xiàn)

基于Http協(xié)議封裝為標(biāo)準(zhǔn)化的Restful數(shù)據(jù)分析接口。標(biāo)準(zhǔn)化的數(shù)據(jù)分析接口是專門用于結(jié)構(gòu)化數(shù)據(jù)計(jì)算的程序語言,將平臺(tái)的分析功能通過自然語言的方式進(jìn)行抽象,標(biāo)準(zhǔn)化為數(shù)據(jù)分析接口。使平臺(tái)提供的應(yīng)用服務(wù)具備可擴(kuò)展性,即不會(huì)因?yàn)槲磥響?yīng)用需求變更而更改底層數(shù)據(jù)的讀取方式,使平臺(tái)具有高內(nèi)聚、低耦合的特性。本文設(shè)計(jì)的數(shù)據(jù)分析接口示意圖如圖7所示。

圖7 數(shù)據(jù)分析接口示意圖Fig.7 Schematic diagram of data analysis interface

圖7中,“date”是指數(shù)據(jù)源,即從數(shù)據(jù)庫里讀取的數(shù)據(jù)。“Index1,Index2,…”是在數(shù)據(jù)源讀取的數(shù)據(jù)中選擇Index1、Index2等幾列?！癏ead 100”是指讀前100條數(shù)據(jù)。

2.4.3 SDK接口的設(shè)計(jì)與實(shí)現(xiàn)

該接口是為用戶提供Java的API接口,也為上層數(shù)據(jù)應(yīng)用提供了高效的讀寫接口,包括大文件的存取操作和基礎(chǔ)數(shù)值函數(shù)。主要封裝的API函數(shù)接口有建庫函數(shù)、刪庫函數(shù)、數(shù)據(jù)表的單條插入、刪除和批處理函數(shù)、寫入文件函數(shù)和讀取文件函數(shù)等。

3 試驗(yàn)數(shù)據(jù)存儲(chǔ)平臺(tái)的應(yīng)用(Application of experimental data storage platform)

基于上述技術(shù)設(shè)計(jì)實(shí)現(xiàn)了試驗(yàn)數(shù)據(jù)存儲(chǔ)平臺(tái),將該平臺(tái)應(yīng)用到航天裝備中,針對(duì)該型號(hào)在系統(tǒng)試驗(yàn)過程中產(chǎn)生的數(shù)據(jù)流、音視頻數(shù)據(jù)和數(shù)據(jù)庫文件等信息,實(shí)現(xiàn)了采集處理、數(shù)據(jù)入庫,以及數(shù)據(jù)文件的檢入、檢出等功能。

3.1 平臺(tái)吞吐能力分析

從平臺(tái)的數(shù)據(jù)吞吐能力、線程并發(fā)處理能力及數(shù)據(jù)檢索能力幾個(gè)方面進(jìn)行對(duì)比與分析。Insert吞吐能力是指每秒可以寫多少條記錄,Read吞吐能力是指每秒可以讀多少條記錄,Scan吞吐能力是指每秒可以查看多少條記錄,延遲時(shí)間是指對(duì)應(yīng)操作需要的時(shí)長(zhǎng)。選擇三臺(tái)8核、32 GB性能的機(jī)器搭建集群測(cè)試融合管理平臺(tái)的數(shù)據(jù)吞吐能力,數(shù)據(jù)統(tǒng)一選擇UDP(User Datapram Protocol,用戶數(shù)據(jù)報(bào)協(xié)議)實(shí)時(shí)數(shù)據(jù)流,每條數(shù)據(jù)包含15個(gè)字段,每個(gè)字段的字段長(zhǎng)度為32字節(jié),測(cè)試情況如表1所示。

表1 平臺(tái)數(shù)據(jù)吞吐能力測(cè)試結(jié)果

從表1中的測(cè)試結(jié)果可以看出,數(shù)據(jù)量的增大并不影響數(shù)據(jù)的吞吐能力和讀取時(shí)間。采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫時(shí),寫入1億條相同的數(shù)據(jù)大概需要2 min,數(shù)據(jù)讀取速度很慢。通過表1中的測(cè)試結(jié)果可以得出本文平臺(tái)的數(shù)據(jù)吞吐能力更強(qiáng)、更可靠。

3.2 多數(shù)據(jù)源接入效果展示效果

選擇將不同類型數(shù)據(jù)庫接入試驗(yàn)數(shù)據(jù)管理平臺(tái)。數(shù)據(jù)源插件管理效果與試驗(yàn)數(shù)據(jù)查詢效果如圖8和圖9所示。

圖8 數(shù)據(jù)源插件管理效果圖Fig.8 The diagram of data source plug-in management

圖9 試驗(yàn)數(shù)據(jù)查詢效果圖 Fig.9 Test data query rendering

4 結(jié)論(Conclusion)

聚焦裝備復(fù)雜試驗(yàn)數(shù)據(jù)結(jié)構(gòu)、存儲(chǔ)冗余管理、訪問速度提升等幾個(gè)方面,本文通過數(shù)據(jù)源插件技術(shù)、分布式采集處理技術(shù)、海量數(shù)據(jù)文件索引技術(shù)和數(shù)據(jù)分析接口的設(shè)計(jì)研究,完成了試驗(yàn)數(shù)據(jù)管理平臺(tái)的設(shè)計(jì)應(yīng)用,并在某裝備型號(hào)上進(jìn)行了應(yīng)用驗(yàn)證。通過對(duì)比分析得出平臺(tái)運(yùn)行穩(wěn)定、可靠且具備較強(qiáng)的數(shù)據(jù)吞吐能力的結(jié)論,實(shí)現(xiàn)了對(duì)海量試驗(yàn)數(shù)據(jù)的快速采集和穩(wěn)定存儲(chǔ),為裝備研制、試驗(yàn)鑒定等提供了平臺(tái)支撐。該融合存儲(chǔ)技術(shù)可擴(kuò)展應(yīng)用于運(yùn)載火箭等其他航天產(chǎn)品的數(shù)據(jù)處理領(lǐng)域,也可用于裝備研制及人體健康狀態(tài)評(píng)估分析,為模型校驗(yàn)、目標(biāo)識(shí)別、任務(wù)規(guī)劃提供實(shí)測(cè)數(shù)據(jù),促進(jìn)裝備試驗(yàn)研究的成果應(yīng)用。