面向裝備試驗數據的融合存儲技術研究與應用

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

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

0 引言(Introduction)

隨著信息化技術的發展,融合存儲技術在各行各業中被大范圍應用。數據融合存儲技術包括對各種信息源數據的采集、傳輸、處理、校核及存儲。數據融合存儲技術主要應用領域有多源影像復合、機器人和智能儀器系統、戰場和無人駕駛飛機、圖像分析與理解、目標檢測與跟蹤、自動目標識別等。

近年來,裝備信息化、智能化技術發展迅速,航天產品在設計、生產、試驗、交付等各個階段產生了大規模的試驗數據,這些數據分散存儲在各系統中,種類龐雜、數據量巨大、存儲與管理困難。由于各種智能設備的信息化水平參差不齊,功能各異,彼此之間相互獨立,因此存在試驗數據來源多樣化、數據格式多樣化、數據存儲位置越來越離散化等特點,導致嚴重的信息孤島現象。

由于試驗數據缺少統一的標準、規范,所以數據格式和數據內容差異很大,不同業務場景對數據的消費和應用也不同,對數據的存儲與管理和共享使用帶來很多困難。為消除數據割裂局面,解決現有數據積累、存儲管理、檢索查詢、協同復用等問題,試驗數據的融合存儲與管理已成為當前迫切要解決的問題[1]。

1 研究思路(Research ideas)

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

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

圖1 總體設計思路Fig.1 Overall design idea

平臺融合多種類型數據庫作為多源異構試驗數據的存儲底座,包括關系型數據庫、時序數據庫、HBase(Hadoop數據庫)、分布式文件系統,面向不同的數據源智能匹配數據入庫方式。將分散的裝備實測數據、試驗數據、仿真數據、地理環境信息數據等數據信息進行統一的存儲、管理和維護。

2 試驗數據融合存儲技術研究(Research on experimental data fusion storage technology)

對于多來源試驗數據的采集接入需求,梳理當前裝備存儲設備的采集協議和方式,將設備IP信息、采集協議、用戶名權限等信息以配置文件的方式進行存儲和加載,增強代碼的復用性。針對各類數據源不同的底層接口,面向用戶提供基于流程選擇的統一接口,采用多線程方式完成多來源數據的并發采集。對于規格化的試驗數據通過適配關系型數據源插件自動提交入庫任務,對于非規格化的數據庫文件,適配非結構化的數據源插件,提交加載任務。為使用者提供簡化、統一的人機交互操作方式,實現一鍵獲取數據、一鍵下載數據、一鍵自動加載數據源。

2.1 數據源插件技術研究

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

面向上述多種類型的數據庫,本文設計了數據源插件技術實現新數據源的注冊、發現和適配運行。數據源插件是基于Java SPI(Service Provider Interface)技術,封裝統一的數據源驅動接口,完成新增數據源的開發適配,實現動態新增數據源。數據源插件工作過程示意圖如圖2所示。

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

基于控制反轉機制,將數據源與數據庫驅動包進行隔離,保證新增數據源與已適配的數據源鏈接方式、驅動包、驅動類名稱等兼容。

當多客戶端重復請求加載插件時,為避免網絡高頻占用,采用本地緩存的方式,首次加載插件時先查看服務器本地文件夾下是否有對應的插件,如果沒有則通過遠程調用請求文件中心的接口,將對應插件下載并緩存到本地。如果本地發現已有對應插件,但為了避免插件的替換熱部署導致現場版本不是最新的插件,此時會對比緩存區的插件的MD5碼和插件數據庫中的MD5碼,保證插件是最新的版本。數據源插件更新流程圖如圖3所示。

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

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

2.2 分布式采集處理技術

傳統的Java數據庫連接(Java Database Connect,JDBC)數據采集,在讀取大數據量時,效率低下,需要將數據全部讀取到內存,可能會出現內存溢出,導致采集失敗的情況,嚴重時會導致程序異常退出。同時,由于它只能通過單節點、單線程的方式進行數據處理,所以對集群的資源利用率偏低,不能充分利用CPU資源,已經不能滿足多源異構數據源采集的業務場景和性能要求。

Spark的優秀資源調度能力結合集群的計算能力,更適合多源異構數據源的采集處理場景[7-8]。本文采用Spark技術實現多源異構數據源的采集處理,其采集處理過程如圖4所示。

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

利用Spark的分布式處理能力,通過多個執行節點批量讀取數據和處理任務,有效提高數據的處理能力。Spark內部會根據數據處理任務,構造有向無環圖,并劃分成不同階段,再劃分為不同的任務,最后將任務分發到不同的執行節點上執行,實現了大數據量的分而治之。每個執行節點還可以分配多個線程,采用多線程處理數據,充分利用集群的優勢將每個節點的CPU充分利用起來。

2.3 海量數據文件檢索技術研究

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

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

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

當一個查詢被觸發,所有已知的數據段將按順序被查詢,單詞統計模塊會對所有段的結果進行聚合,以保證每個詞和每個文檔的關聯都被準確計算,而不需要對數據庫中所有的數據內容進行過濾查詢,可有效提升數據的查詢速度。當有新的數據寫入索引時,單詞統計模塊會根據業務進行詞劃分,不同的關鍵詞對應不同的數據ID,并同步增加詞頻統計值。采用這種倒排索引可有效降低新文檔添加到索引庫的難度。

2.4 數據分析接口設計研究

數據分析接口是響應數據接口指令并提供數據業務的邏輯處理過程。通過數據接口封裝保證了數據平臺與業務之間的剝離,便于業務的拓展和開發。在分析用戶的使用場景后,本系統對外提供的數據接口主要有JDBC接口、Restful接口、SDK接口。其中,JDBC接口提供SQL語句化的數據檢索處理方式;Restful接口是基于Http協議的標準化數據分析接口;SDK接口是為上層應用服務提供API函數接口和基本的數值計算接口。

2.4.1 JDBC接口的設計與實現

解析用戶的數據檢索指令,將其標準化為類SQL查詢語句。通過標準化的類SQL查詢語句從索引數據庫中抽取對應的數據信息,將索引信息與數據內容進行對應,完成數據的提取和反饋。SQL數據流處理過程示意圖如圖6所示。

圖6 SQL數據流處理過程Fig.6 The diagram of the SQL data flow process

2.4.2 Restful接口的設計與實現

基于Http協議封裝為標準化的Restful數據分析接口。標準化的數據分析接口是專門用于結構化數據計算的程序語言,將平臺的分析功能通過自然語言的方式進行抽象,標準化為數據分析接口。使平臺提供的應用服務具備可擴展性,即不會因為未來應用需求變更而更改底層數據的讀取方式,使平臺具有高內聚、低耦合的特性。本文設計的數據分析接口示意圖如圖7所示。

圖7 數據分析接口示意圖Fig.7 Schematic diagram of data analysis interface

圖7中,“date”是指數據源,即從數據庫里讀取的數據。“Index1,Index2,…”是在數據源讀取的數據中選擇Index1、Index2等幾列。“Head 100”是指讀前100條數據。

2.4.3 SDK接口的設計與實現

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

3 試驗數據存儲平臺的應用(Application of experimental data storage platform)

基于上述技術設計實現了試驗數據存儲平臺,將該平臺應用到航天裝備中,針對該型號在系統試驗過程中產生的數據流、音視頻數據和數據庫文件等信息,實現了采集處理、數據入庫,以及數據文件的檢入、檢出等功能。

3.1 平臺吞吐能力分析

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

表1 平臺數據吞吐能力測試結果

從表1中的測試結果可以看出,數據量的增大并不影響數據的吞吐能力和讀取時間。采用傳統的關系型數據庫時,寫入1億條相同的數據大概需要2 min,數據讀取速度很慢。通過表1中的測試結果可以得出本文平臺的數據吞吐能力更強、更可靠。

3.2 多數據源接入效果展示效果

選擇將不同類型數據庫接入試驗數據管理平臺。數據源插件管理效果與試驗數據查詢效果如圖8和圖9所示。

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

圖9 試驗數據查詢效果圖 Fig.9 Test data query rendering

4 結論(Conclusion)

聚焦裝備復雜試驗數據結構、存儲冗余管理、訪問速度提升等幾個方面,本文通過數據源插件技術、分布式采集處理技術、海量數據文件索引技術和數據分析接口的設計研究,完成了試驗數據管理平臺的設計應用,并在某裝備型號上進行了應用驗證。通過對比分析得出平臺運行穩定、可靠且具備較強的數據吞吐能力的結論,實現了對海量試驗數據的快速采集和穩定存儲,為裝備研制、試驗鑒定等提供了平臺支撐。該融合存儲技術可擴展應用于運載火箭等其他航天產品的數據處理領域,也可用于裝備研制及人體健康狀態評估分析,為模型校驗、目標識別、任務規劃提供實測數據,促進裝備試驗研究的成果應用。