陸 超，李曉瑜，孫婧博

(1.中國(guó)航發(fā)四川燃?xì)鉁u輪研究院 高空模擬技術(shù)重點(diǎn)實(shí)驗(yàn)室，四川 綿陽(yáng) 621000；2.電子科技大學(xué) 信息與軟件工程學(xué)院，成都 610054；3.中國(guó)航發(fā)航空發(fā)動(dòng)機(jī)研究院，北京 101300)

1 引言

充分有效地利用航空發(fā)動(dòng)機(jī)試驗(yàn)產(chǎn)生的豐富數(shù)據(jù)資源，對(duì)發(fā)動(dòng)機(jī)研發(fā)過(guò)程具有重大意義。但由于試驗(yàn)數(shù)據(jù)體量大、增速快，不同部門(mén)間數(shù)據(jù)傳遞效率低下；且傳統(tǒng)的數(shù)據(jù)庫(kù)技術(shù)側(cè)重于存儲(chǔ)，對(duì)數(shù)據(jù)應(yīng)用的支持有限，不能有效地開(kāi)展數(shù)據(jù)挖掘與分析工作。同時(shí)，發(fā)動(dòng)機(jī)試驗(yàn)過(guò)程中還會(huì)產(chǎn)生一些非傳感器的數(shù)據(jù)，如視頻、圖像、文檔等形式的信息，而已有的平臺(tái)和技術(shù)難以將這些多媒體數(shù)據(jù)與試驗(yàn)數(shù)據(jù)相關(guān)聯(lián)，因此需要對(duì)數(shù)據(jù)進(jìn)行清洗和升維，之后再使用數(shù)據(jù)融合技術(shù)，對(duì)這些來(lái)自各部門(mén)的多源異構(gòu)數(shù)據(jù)進(jìn)行整合關(guān)聯(lián)。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)(如Oracle)對(duì)結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)較為有效，但隨著數(shù)據(jù)體量的增加、發(fā)動(dòng)機(jī)研發(fā)需求的提高以及大數(shù)據(jù)技術(shù)的興起，這類數(shù)據(jù)庫(kù)面向時(shí)序型數(shù)據(jù)時(shí)存在效率低下、功能單一等問(wèn)題，難以滿足發(fā)動(dòng)機(jī)研發(fā)的業(yè)務(wù)需求。如試驗(yàn)中針對(duì)某次發(fā)動(dòng)機(jī)故障，往往需要將常規(guī)測(cè)試、特種測(cè)試、視頻音頻、各專業(yè)的后處理圖表等信息整合后進(jìn)行綜合分析，面對(duì)這種情況，關(guān)系型數(shù)據(jù)庫(kù)就難以勝任，而通過(guò)人工手段將這些割裂的信息關(guān)聯(lián)、整合，費(fèi)時(shí)耗力且效果不理想。

本文簡(jiǎn)要介紹了航空發(fā)動(dòng)機(jī)試驗(yàn)在數(shù)據(jù)存儲(chǔ)和管理上的痛點(diǎn)和新需求，并對(duì)航空發(fā)動(dòng)機(jī)試驗(yàn)過(guò)程中產(chǎn)生的時(shí)序型傳感器數(shù)據(jù)的清洗和升維方法進(jìn)行了研究，提出了一種面向航空發(fā)動(dòng)機(jī)試驗(yàn)的多源數(shù)據(jù)融合平臺(tái)，并對(duì)該平臺(tái)進(jìn)行了簡(jiǎn)要的測(cè)試和試驗(yàn)，驗(yàn)證了該平臺(tái)的技術(shù)可行性。

2 技術(shù)方案

2.1 多源異構(gòu)數(shù)據(jù)

航空發(fā)動(dòng)機(jī)在試驗(yàn)過(guò)程中會(huì)產(chǎn)生大量的傳感器數(shù)據(jù)，這些數(shù)據(jù)由各傳感器以固定的采集頻率獲取，可將其稱為時(shí)間序列數(shù)據(jù)。如果和普通數(shù)據(jù)一樣采用關(guān)系型數(shù)據(jù)庫(kù)對(duì)時(shí)間序列數(shù)據(jù)進(jìn)行存儲(chǔ)，將存在諸多弊端，如按時(shí)間區(qū)間檢索數(shù)據(jù)的效率較低、支持的查詢功能單一等，且這些傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)也難以應(yīng)對(duì)傳感器屬性的升維要求。存儲(chǔ)在數(shù)據(jù)庫(kù)中的數(shù)據(jù)很難在時(shí)間軸上自動(dòng)對(duì)齊，不同設(shè)備下的不同傳感器在數(shù)據(jù)中難以管理。此外，試驗(yàn)過(guò)程中不止產(chǎn)生由傳感器采集到的時(shí)序數(shù)據(jù)，還會(huì)產(chǎn)生一些視頻文件、圖像文件，以及某次試驗(yàn)后人為產(chǎn)生的分析報(bào)告等輸出文檔。如果對(duì)這些多源異構(gòu)數(shù)據(jù)按屬性、時(shí)間等信息關(guān)聯(lián)，難以在現(xiàn)有數(shù)據(jù)平臺(tái)下實(shí)現(xiàn)。正是由于傳統(tǒng)數(shù)據(jù)庫(kù)存在著上述弊端，加之航空發(fā)動(dòng)機(jī)試驗(yàn)中又不斷提出新的需求，就要求研發(fā)一種新的數(shù)據(jù)存儲(chǔ)與管理平臺(tái)，來(lái)提供高效的數(shù)據(jù)讀寫(xiě)、查詢、檢索及分析功能，并支持對(duì)傳感器型數(shù)據(jù)的靈活擴(kuò)展[1]。

2.2 時(shí)序數(shù)據(jù)管理——IoTDB

IoTDB[2]是一種新型的針對(duì)時(shí)間序列數(shù)據(jù)的開(kāi)源數(shù)據(jù)管理引擎。IoTDB 最早由清華大學(xué)大數(shù)據(jù)系統(tǒng)軟件團(tuán)隊(duì)研發(fā)，并于2018 年捐贈(zèng)給Apache，隨后進(jìn)行了為期近兩年的孵化，最終于2020 年9 月，由Apache 軟件基金會(huì)(ASF)宣布成為Apache 頂級(jí)項(xiàng)目。IoTDB 具有時(shí)序數(shù)據(jù)收集、存儲(chǔ)與分析一體化的功能，以及體量輕、性能高、易使用的特點(diǎn)。此外，IoTDB 還提供了低硬件成本的存儲(chǔ)解決方案，10 億數(shù)據(jù)點(diǎn)硬盤(pán)成本低于1.4 元；高通量的時(shí)間序列數(shù)據(jù)讀寫(xiě)，支持百萬(wàn)級(jí)低功耗連接設(shè)備數(shù)據(jù)接入；面向時(shí)間序列的豐富查詢語(yǔ)義，實(shí)現(xiàn)跨設(shè)備、跨傳感器的時(shí)間序列對(duì)齊；能完美對(duì)接Hadoop 與Spark 生態(tài)，適用于工業(yè)互聯(lián)網(wǎng)應(yīng)用中海量時(shí)間序列數(shù)據(jù)高速寫(xiě)入和復(fù)雜分析查詢的需求。

航空發(fā)動(dòng)機(jī)試驗(yàn)過(guò)程產(chǎn)生的數(shù)據(jù)為時(shí)間序列數(shù)據(jù)，由各傳感器按照一定頻率采集得到，這與IoTDB 中所存儲(chǔ)與管理的數(shù)據(jù)類型基本一致。同時(shí)，由于IoTDB 國(guó)產(chǎn)自主可控，具有存儲(chǔ)成本低、數(shù)據(jù)寫(xiě)入速度快(百萬(wàn)數(shù)據(jù)點(diǎn)秒級(jí)寫(xiě)入)、數(shù)據(jù)查詢速度快(TB 級(jí)數(shù)據(jù)毫秒級(jí)查詢)、功能完備(數(shù)據(jù)的增刪改查、豐富的聚合函數(shù)、相似性匹配)、查詢分析一體化(一份數(shù)據(jù)，滿足實(shí)時(shí)查詢與分析挖掘)、簡(jiǎn)單易用等特點(diǎn)，使用IoTDB 作為多源數(shù)據(jù)融合的基礎(chǔ)數(shù)據(jù)存儲(chǔ)與管理平臺(tái)將大大提升數(shù)據(jù)存取效率。

2.3 其他相關(guān)數(shù)據(jù)管理

對(duì)高空試驗(yàn)數(shù)據(jù)進(jìn)行綜合分析和處理時(shí)，通常涉及到試驗(yàn)傳感器產(chǎn)生的時(shí)序數(shù)據(jù)以及相關(guān)試驗(yàn)場(chǎng)景下產(chǎn)生的視頻文件、圖像文件、分析報(bào)告等其他相關(guān)數(shù)據(jù)文件。在確定時(shí)序數(shù)據(jù)存儲(chǔ)和管理平臺(tái)的基礎(chǔ)上，也需要選擇合適的數(shù)據(jù)平臺(tái)對(duì)這些非時(shí)序型數(shù)據(jù)文件進(jìn)行存儲(chǔ)管理，為此選擇Hadoop 作為數(shù)據(jù)融合的分布式平臺(tái)。

Hadoop[3]是一個(gè)開(kāi)源的、高效的分布式計(jì)算平臺(tái)，可在分布式環(huán)境下為用戶提供海量數(shù)據(jù)的存儲(chǔ)和處理能力。HDFS[4]是Hadoop 的核心模塊之一。當(dāng)1 個(gè)文件被存儲(chǔ)到HDFS 中時(shí)，它不是作為1 個(gè)完整的單一實(shí)體存儲(chǔ)，而是被切分成了多個(gè)較小的部分(稱為“數(shù)據(jù)塊”)，且這些數(shù)據(jù)塊通常具有相同的大小。如HDFS 可能將每個(gè)數(shù)據(jù)塊的大小設(shè)定為128 MB，這意味著1 個(gè)500 MB 的文件將被切分成4 個(gè)128 MB 的數(shù)據(jù)塊和1 個(gè)88 MB 的數(shù)據(jù)塊，且這些數(shù)據(jù)塊被存儲(chǔ)在HDFS 集群的多個(gè)節(jié)點(diǎn)上。通過(guò)將文件的不同部分存儲(chǔ)在不同的節(jié)點(diǎn)上，從而實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ)。為了提高可靠性，每個(gè)數(shù)據(jù)塊通常會(huì)在集群中的不同節(jié)點(diǎn)上進(jìn)行多次復(fù)制。如1 個(gè)數(shù)據(jù)塊可能有3 個(gè)副本，每個(gè)副本存儲(chǔ)在不同的節(jié)點(diǎn)上。這樣，即使某個(gè)節(jié)點(diǎn)發(fā)生故障，文件的該部分?jǐn)?shù)據(jù)也不會(huì)丟失。這種將文件切分成等大數(shù)據(jù)塊的方法，使得HDFS 能夠有效地處理和存儲(chǔ)大型文件，同時(shí)也便于在集群的不同節(jié)點(diǎn)上并行處理數(shù)據(jù)。通過(guò)這種方式，Hadoop 能夠進(jìn)行高效的大數(shù)據(jù)分析和處理。

IoTDB 可無(wú)縫支持Hadoop 生態(tài)，為此可以通過(guò)結(jié)合IoTDB與Hadoop生態(tài)搭建多源數(shù)據(jù)融合平臺(tái)。

2.4 多源數(shù)據(jù)融合分析架構(gòu)

基于IoTDB 處理時(shí)序數(shù)據(jù)時(shí)的各種優(yōu)勢(shì)以及Hadoop 成熟的生態(tài)及應(yīng)用，提出了一種面向航空發(fā)動(dòng)機(jī)試驗(yàn)的多源數(shù)據(jù)融合平臺(tái)，該平臺(tái)架構(gòu)如圖1所示。數(shù)據(jù)采集端按照一定的采集頻率收集各個(gè)傳感器的通道數(shù)據(jù)，采集段所獲取的數(shù)據(jù)通過(guò)JDBC接口將數(shù)據(jù)存入時(shí)序數(shù)據(jù)庫(kù)IoTDB 部署的服務(wù)器中；IoTDB 可以將存儲(chǔ)的數(shù)據(jù)定時(shí)以TsFile 文件的形式上傳至Hadoop/Spark 集群中，方便后續(xù)進(jìn)行各種數(shù)據(jù)挖掘與數(shù)據(jù)分析操作。為了不影響已有業(yè)務(wù)，存入IoTDB 的數(shù)據(jù)來(lái)自于原來(lái)存儲(chǔ)時(shí)序數(shù)據(jù)的數(shù)據(jù)庫(kù)，這樣IoTDB 中的數(shù)據(jù)并不是實(shí)時(shí)的，因此IoTDB 中的數(shù)據(jù)主要用于數(shù)據(jù)挖掘與分析。虛線方框部分為平臺(tái)的大數(shù)據(jù)集群框架，圖中只給出了4個(gè)節(jié)點(diǎn)，包括3 個(gè)數(shù)據(jù)節(jié)點(diǎn)和1 個(gè)主節(jié)點(diǎn)，實(shí)際應(yīng)用中節(jié)點(diǎn)數(shù)量可以根據(jù)自身需求和數(shù)據(jù)量來(lái)分配[5]。

圖1 發(fā)動(dòng)機(jī)簡(jiǎn)化模型Fig.1 Simplified engine model

對(duì)于文本、圖片、視頻、音頻、附件等非結(jié)構(gòu)化數(shù)據(jù)，可直接存儲(chǔ)在Hadoop 生態(tài)下的分布式文件系統(tǒng)HDFS 中。使用MapReduce 或Spark 對(duì)平臺(tái)下存放的各種數(shù)據(jù)進(jìn)行分析處理，整個(gè)平臺(tái)提供數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)清洗、數(shù)據(jù)融合、機(jī)器學(xué)習(xí)、大數(shù)據(jù)分析等功能。通過(guò)Ambari[6-8]對(duì)集群進(jìn)行管理。Ambari 是一種支持Hadoop 集群部署、監(jiān)控和管理的開(kāi)源工具，相較于傳統(tǒng)手工部署方式，其極大地提高了Hadoop 集群部署的效率。在本文提出的多源數(shù)據(jù)融合平臺(tái)中，Ambari 被單獨(dú)部署在另外1臺(tái)服務(wù)器中(分布式集群的監(jiān)控主機(jī))。Ambari 對(duì)服務(wù)器性能要求不高，通過(guò)Ambari 可監(jiān)控集群狀態(tài)和進(jìn)行節(jié)點(diǎn)管理，如節(jié)點(diǎn)的新增和刪除，以及集群組件的部署安裝。Ambari 以Web 形式提供相應(yīng)的服務(wù)，通過(guò)外接顯示器可視化展示集群狀態(tài)。

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

3.1 IoTDB 存儲(chǔ)性能測(cè)試

為了驗(yàn)證IoTDB 存儲(chǔ)成本低的特性，對(duì)存儲(chǔ)在IoTDB 中時(shí)序數(shù)據(jù)所占硬盤(pán)容量的大小進(jìn)行相應(yīng)的測(cè)試。假設(shè)傳感器數(shù)目為500，且1 min 采樣50 次，對(duì)500 個(gè)傳感器的插入進(jìn)行測(cè)試，插入10 000條數(shù)據(jù)大約32.4 MB，平均插入1條數(shù)據(jù)約3.3 KB，為了直觀地展示500 個(gè)傳感器在采樣頻率為50 Hz 的情況下所產(chǎn)生的時(shí)序數(shù)據(jù)在IoTDB 中的存儲(chǔ)容量隨時(shí)間變化的特點(diǎn)，表1 以不同刻度的時(shí)間對(duì)比展示出了容量變化。可看出，傳感器無(wú)休止地采集數(shù)據(jù)1 年，數(shù)據(jù)所占硬盤(pán)容量?jī)H需82 GB。顯然，在實(shí)際的航空發(fā)動(dòng)機(jī)研制過(guò)程中，傳感器并不是無(wú)休止地采集數(shù)據(jù)，因此實(shí)際所占容量只會(huì)比這更小，由此驗(yàn)證了IoTDB 低存儲(chǔ)成本的特性。

表1 時(shí)序數(shù)據(jù)在IoTDB 中容量變化Table 1 Time series data capacity changes in IoTDB

3.2 IoTDB 數(shù)據(jù)檢索效率測(cè)試

對(duì)IoTDB 的數(shù)據(jù)檢索效率進(jìn)行對(duì)比測(cè)試，對(duì)比數(shù)據(jù)庫(kù)為MangoDB，對(duì)比結(jié)果如表2 所示。MangoDB 從1 個(gè)表中隨機(jī)查詢150 條數(shù)據(jù)，總共耗時(shí)596 s，平均查詢1 條數(shù)據(jù)耗時(shí)4 s。而IoTDB 的數(shù)據(jù)查詢效率為毫秒級(jí)，隨機(jī)以時(shí)間戳為條件查詢1 條數(shù)據(jù)，耗時(shí)在10～100 ms。相較于被廣泛使用的NoSQL 數(shù)據(jù)庫(kù)MangoDB，查詢效率明顯提高，由此驗(yàn)證了IoTDB 高效的時(shí)序數(shù)據(jù)檢索效率[9-10]。

表2 IoTDB 與MangoDB 檢索耗時(shí)對(duì)比Table 2 Comparison of retrieval time between IoTDB and MangoDB

3.3 基于IoTDB 的時(shí)間序列數(shù)據(jù)管理

使用IoTDB 創(chuàng)建時(shí)間序列時(shí)，可以為其添加別名及額外的標(biāo)簽和屬性信息。在IoTDB 中，標(biāo)簽和屬性的唯一區(qū)別是，IoTDB 為標(biāo)簽信息在內(nèi)存中維護(hù)了1 個(gè)倒排索引，可以通過(guò)設(shè)置的標(biāo)簽信息作為查詢條件對(duì)通道信息(即傳感器信息)進(jìn)行查詢。為此，可以使用IoTDB 提供的標(biāo)簽存儲(chǔ)數(shù)據(jù)升維后的各個(gè)屬性，標(biāo)簽值為對(duì)應(yīng)的屬性值。在實(shí)際的試驗(yàn)測(cè)試中發(fā)現(xiàn)，IoTDB 在通道數(shù)為2 000 時(shí)以標(biāo)簽信息來(lái)查詢所匹配的通道的效率也是毫秒級(jí)，單次查詢平均為幾十毫秒。

4 基于IoTDB 的數(shù)據(jù)清洗與升維

航空發(fā)動(dòng)機(jī)試驗(yàn)數(shù)據(jù)在進(jìn)入IoTDB 數(shù)據(jù)庫(kù)存儲(chǔ)與管理前，需要經(jīng)過(guò)數(shù)據(jù)接入、數(shù)據(jù)清洗及數(shù)據(jù)升維3 個(gè)步驟，如圖2 所示[11]。數(shù)據(jù)升維是數(shù)據(jù)由單一“數(shù)值”變?yōu)椤岸嗑S數(shù)據(jù)”的蛻變過(guò)程，其主要內(nèi)容是通過(guò)什么樣的方法和規(guī)則、對(duì)數(shù)據(jù)增加哪些屬性。原有數(shù)據(jù)系統(tǒng)在設(shè)計(jì)和存儲(chǔ)形式上難以對(duì)數(shù)據(jù)屬性進(jìn)行升維，也無(wú)法提供快速的針對(duì)航空發(fā)動(dòng)機(jī)試驗(yàn)數(shù)據(jù)的基于屬性的查詢。根據(jù)航空發(fā)動(dòng)機(jī)專業(yè)特點(diǎn)擬定了升維屬性條目，主要包含基本屬性、測(cè)試屬性、表達(dá)屬性、應(yīng)用屬性、關(guān)聯(lián)屬性等類別，并對(duì)原始數(shù)據(jù)庫(kù)的屬性進(jìn)行擴(kuò)充，以此構(gòu)建內(nèi)涵更加豐富的數(shù)據(jù)，為實(shí)現(xiàn)多數(shù)據(jù)檢索數(shù)據(jù)功能及數(shù)據(jù)關(guān)聯(lián)研究提供了保證。而屬性升維通過(guò)IoTDB 提供的標(biāo)簽點(diǎn)功能來(lái)實(shí)現(xiàn)，IoTDB 為標(biāo)簽信息在內(nèi)存中維護(hù)了1 個(gè)倒排索引，據(jù)此可使用標(biāo)簽作為查詢條件快速檢索內(nèi)容。通過(guò)對(duì)升維后的屬性進(jìn)行關(guān)聯(lián)，可以將包含相同屬性內(nèi)容的傳感器關(guān)聯(lián)起來(lái)，并提供基于升維后屬性的多條件查詢功能。

圖2 基于IoTDB 的數(shù)據(jù)清洗與升維流程圖Fig.2 Data cleaning and dimension improvement flow chart based on IoTDB

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

為解決傳統(tǒng)航空發(fā)動(dòng)機(jī)試驗(yàn)過(guò)程中多源異構(gòu)數(shù)據(jù)難以得到充分、有效利用的不足，提出一種面向航空發(fā)動(dòng)機(jī)試驗(yàn)的多源數(shù)據(jù)融合平臺(tái)。該平臺(tái)以開(kāi)源時(shí)序型數(shù)據(jù)庫(kù)IoTDB 和大數(shù)據(jù)存儲(chǔ)與分析平臺(tái)Hadoop/Spark 為核心組件構(gòu)建，不僅能對(duì)傳感器采集的時(shí)間序列數(shù)據(jù)進(jìn)行高效的存儲(chǔ)、檢索、管理和分析，還能對(duì)發(fā)動(dòng)機(jī)試驗(yàn)中產(chǎn)生的各種非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行分布式存儲(chǔ)和處理。對(duì)IoTDB 性能和功能的測(cè)試表明，IoTDB 能滿足面向航空發(fā)動(dòng)機(jī)試驗(yàn)的多源異構(gòu)數(shù)據(jù)融合的需求。最后，基于IoTDB 數(shù)據(jù)平臺(tái)，對(duì)航空發(fā)動(dòng)機(jī)試驗(yàn)過(guò)程中產(chǎn)生的時(shí)間序列型數(shù)據(jù)的清洗、升維方法進(jìn)行了測(cè)試和驗(yàn)證，證明以該平臺(tái)為依托，可以構(gòu)建面向航空發(fā)動(dòng)機(jī)試驗(yàn)的大數(shù)據(jù)生態(tài)。