田亞鵬，鄭硯普，付旭云

（1.哈爾濱工業(yè)大學（威海）船舶與海洋工程學院；

2.威海眾成信息科技股份有限公司 技術部，山東 威海 264209）

基于HBase的民用航空發(fā)動機大數(shù)據(jù)管理系統(tǒng)

田亞鵬1，鄭硯普2，付旭云1

（1.哈爾濱工業(yè)大學（威海）船舶與海洋工程學院；

2.威海眾成信息科技股份有限公司 技術部，山東 威海 264209）

為克服傳統(tǒng)關系型數(shù)據(jù)庫存儲管理海量航空發(fā)動機狀態(tài)監(jiān)控數(shù)據(jù)的不足，本研究提出了基于HBase的民用航空發(fā)動機大數(shù)據(jù)管理系統(tǒng)。首先分析了該系統(tǒng)的功能需求，給出了系統(tǒng)整體架構與模塊設計，并對關鍵技術進行了闡述。最后設計試驗對比HBase與Oracle的搜索效率。試驗結果表明檢索結果集較大時HBase的搜索效率明顯高于Oracle。本研究中提出的航空發(fā)動機大數(shù)據(jù)管理系統(tǒng)為發(fā)動機海量數(shù)據(jù)的存儲管理提供了一種解決方案。

民用航空發(fā)動機；大數(shù)據(jù)；NoSQL；HBase；搜索效率

0 引言

作為飛機的核心組成部分，航空發(fā)動機的健康管理是航空公司日常工作的重中之重。航空發(fā)動機是一個十分復雜的系統(tǒng)，其日常運營中會產(chǎn)生大量的狀態(tài)監(jiān)控數(shù)據(jù)。這些監(jiān)控數(shù)據(jù)能夠幫助工程師了解發(fā)動機當前狀態(tài)，判斷發(fā)動機有無發(fā)生故障，并根據(jù)當前狀態(tài)制定相應的維修計劃。因此實現(xiàn)對航空發(fā)動機數(shù)據(jù)的有效監(jiān)控與管理成為各航空公司的迫切需求。

以往航空發(fā)動機的狀態(tài)監(jiān)控數(shù)據(jù)都存儲在關系型數(shù)據(jù)庫中。工程上應用較廣泛的關系型數(shù)據(jù)庫包括Oracle、SQLServer、DB2、Sybase、Access等［1］。在存儲數(shù)據(jù)量較小時，采用傳統(tǒng)的關系型數(shù)據(jù)庫進行檢索，其檢索速度是可以滿足日常需求的。然而隨著發(fā)動機狀態(tài)監(jiān)控技術的進步以及航空公司機隊飛機數(shù)量的快速增加，航空公司收集到的狀態(tài)監(jiān)控數(shù)據(jù)量逐漸變的非常龐大，并且還有不斷增長的趨勢。以國內某航空公司為例，2013年時其飛機保有量大約為300架，每天大約有1300多個航班。在這種情況下，僅僅是快速存取記錄器（QAR）記錄的數(shù)據(jù)量就達到每年2TB的規(guī)模［2］。這僅僅是QAR的數(shù)據(jù)量，其他數(shù)據(jù)來源如飛機通信尋址報告系統(tǒng)（ACRAS）、原始設備制造商（OEM）等都會產(chǎn)生大量的監(jiān)控數(shù)據(jù)。隨著航空公司機隊規(guī)模的擴大以及技術的進步，其獲得的發(fā)動機狀態(tài)監(jiān)控數(shù)據(jù)量將變得更加巨大。

雖然關系型數(shù)據(jù)庫性能非常好，但它畢竟是通用型的數(shù)據(jù)庫，并不能完全適應所有用途。傳統(tǒng)的關系型數(shù)據(jù)庫需要固定的模式來描述數(shù)據(jù)，因此難以適應工況數(shù)據(jù)模式多變的特點；傳統(tǒng)的數(shù)據(jù)庫很難進行橫向擴展。對于容量擴充的需求只能通過停機維護和數(shù)據(jù)遷移來實現(xiàn)，時間和財力成本較高。此外，傳統(tǒng)的關系型數(shù)據(jù)庫難以滿足高并發(fā)讀寫的需求，簡單查詢時返回結果不夠快并且對硬件性能要求較高［3］。由于存在這些缺陷，僅依靠關系型數(shù)據(jù)庫本身的索引或者分區(qū)分表等方法來存儲規(guī)模日趨增長的發(fā)動機監(jiān)控數(shù)據(jù)，其存儲和使用效率會變的非常低下，嚴重時甚至會導致數(shù)據(jù)庫服務器崩潰。

針對航空公司有效存儲管理發(fā)動機海量監(jiān)控數(shù)據(jù)的迫切需求，本研究提出一種面向民用航空發(fā)動機海量監(jiān)控數(shù)據(jù)的存儲管理方法，并設計了相應的大數(shù)據(jù)存儲管理系統(tǒng)。使用關系型數(shù)據(jù)庫和分布式文件系統(tǒng)構成兩級存儲模式。上層利用Oracle實現(xiàn)航空發(fā)動機管理機制和基礎數(shù)據(jù)的組織；底層利用HBase分布式文件系統(tǒng)實現(xiàn)對海量數(shù)據(jù)的高性能存儲管理。這種結構可以實現(xiàn)航空發(fā)動機基礎數(shù)據(jù)與監(jiān)控數(shù)據(jù)的動態(tài)耦合，一定程度上實現(xiàn)了航空公司有效存儲管理海量監(jiān)控數(shù)據(jù)的需求。

1 系統(tǒng)需求分析

飛機從起飛到降落，發(fā)動機各個參數(shù)由飛機狀態(tài)監(jiān)控系統(tǒng)（ACMS）的傳感器實時測得并被編入發(fā)動機報，通過飛機通訊尋址與報告系統(tǒng)（ACARS）發(fā)往地面站。航空發(fā)動機的生產(chǎn)廠家（OEM）也會采用自己研制的發(fā)動機狀態(tài)監(jiān)控軟件對ACARS數(shù)據(jù)進行處理，并將處理后的數(shù)據(jù)（OEM數(shù)據(jù)）發(fā)送給航空公司。目前這兩類數(shù)據(jù)在航空公司的應用是比較廣泛和成熟的，因此本研究專門針對民用航空發(fā)動機這兩類數(shù)據(jù)設計一套海量數(shù)據(jù)存儲和管理系統(tǒng)。該系統(tǒng)應具有如下功能：

a）定制解析協(xié)議解析發(fā)動機監(jiān)控數(shù)據(jù)。如上所述，目前航空公司經(jīng)常使用ACARS報文數(shù)據(jù)和OEM數(shù)據(jù)對發(fā)動機進行管理。但這兩類數(shù)據(jù)原始形式并不能直接為工程師所用，必須采用專門的解析協(xié)議對其解析后方能使用。ACARS報文一般為txt格式文件，OEM數(shù)據(jù)一般為excel文檔。

b）監(jiān)控發(fā)動機參數(shù)中出現(xiàn)的不合理狀況并給出報警信息。需要針對不同發(fā)位、不同班次的發(fā)動機進行監(jiān)控并綜合各方面的信息判斷發(fā)動機當前狀態(tài)。在報警功能中報警規(guī)則應能夠根據(jù)工程師需求人工修改，并且報警歷史應該被保存以供工程師日后查看。

c）為用戶提供數(shù)據(jù)的圖形化展示。該部分應該為用戶提供包括數(shù)據(jù)圖形展示、圖形導出以及數(shù)據(jù)導出等功能。

d）保證工程師能及時檢索到所需數(shù)據(jù)。系統(tǒng)中將對海量數(shù)據(jù)（億級別以上）的檢索速度應該控制在15秒以內。

2 系統(tǒng)設計

針對航空公司有效存儲管理發(fā)動機海量監(jiān)控數(shù)據(jù)的迫切需求，本研究設計了一個基于HBase的民用航空發(fā)動機大數(shù)據(jù)管理系統(tǒng)。該系統(tǒng)可以分為四層，從下而上依次為數(shù)據(jù)層、業(yè)務邏輯層、表現(xiàn)層和客戶層。

數(shù)據(jù)層使用關系型數(shù)據(jù)庫和分布式文件系統(tǒng)構成兩級存儲模式。業(yè)務邏輯層主要功能是解析航空發(fā)動機監(jiān)控數(shù)據(jù)。表現(xiàn)層主要功能是報警管理和趨勢分析?？蛻魧邮莣eb瀏覽器，用戶在客戶端無需額外安裝任何軟件，只要有可運行的網(wǎng)絡并且計算機安裝了web瀏覽器即可訪問該系統(tǒng)。該系統(tǒng)的整體架構如圖1所示。下面對系統(tǒng)的業(yè)務邏輯層和表現(xiàn)層進行詳細闡述。

2.1 業(yè)務邏輯層

業(yè)務邏輯層的主要功能是定制解析協(xié)議，將原始ACARS報文和OEM數(shù)據(jù)解析成標準化、規(guī)范化并且可直接操作的有效數(shù)據(jù)。該層可進一步分解為SMI標簽管理、子標簽管理、標準化參數(shù)管理、參數(shù)監(jiān)控類型管理、ACARS模板管理和OEM模板管理六個模塊。

2.1.1 SMI標簽管理

SMI是區(qū)分報文的首層標志。報文的形式主要有參數(shù)監(jiān)視報（DFD）、故障報（CFD）、運控報（M10）、廠家報文（OEM）。前三種報文分別來自機載系統(tǒng)的三個不同模塊，其中DFD來自發(fā)動機參數(shù)監(jiān)視系統(tǒng)ACMS，CFD來自故障監(jiān)視系統(tǒng)CMC，M10來自運控系統(tǒng)ACARS，這三種類型的報文都通過ACARS統(tǒng)一向地面發(fā)送，地面站未對其進行區(qū)分。因此需要設置首層標志SMI來區(qū)分不同類型的報文。

2.1.2 子標簽管理

子標簽是區(qū)分報文的下一層標志。比如ACARS報文又可以進一步分成起飛狀態(tài)報（TKO），巡航狀態(tài)報（CRZ）等。采用子標簽可以對報文進行更加具體的分類。

2.1.3 標準化參數(shù)管理

各個發(fā)動機廠家對各項參數(shù)的命名并沒有統(tǒng)一規(guī)范。為方便管理數(shù)據(jù)，需要制定一套統(tǒng)一的發(fā)動機參數(shù)命名規(guī)范。根據(jù)該規(guī)范將各個廠家提供的數(shù)據(jù)標準化，這樣做有利于日后對發(fā)動機數(shù)據(jù)的管理和利用。

2.1.4 參數(shù)監(jiān)控類型管理

方便用戶根據(jù)自身需求選擇不同的參數(shù)監(jiān)控類型，比如氣路監(jiān)控、振動監(jiān)控等。

2.1.5 ACARS模板管理

該部分的主要功能是配置參數(shù)在報文中的位置，將每種報文中各個參數(shù)所在行列記錄在xml模板中。因為xml可以明確表示各個參數(shù)的屬性信息和所處位置，采用dom4j可以對xml文件進行解析和生成。xml模板的格式如圖2所示。

2.1.6 OEM模板管理

該部分主要確定OEM文件中各行各列的意義及其對應關系。在解析OEM文件時需要獲取標題所在行、數(shù)據(jù)開始行、發(fā)動機序列號（ESN）所在列、時間所在列、時間格式、各列參數(shù)與標準化參數(shù)的對應關系、參數(shù)是否需要導入數(shù)據(jù)庫、飛行階段設定規(guī)則等信息。這個模塊可以根據(jù)用戶需求自定義格式，增加操作靈活性。

2.2 表現(xiàn)層

表現(xiàn)層主要包括報警管理和趨勢分析兩個模塊。報警管理的主要功能是設定報警規(guī)則和查詢報警歷史信息。趨勢分析的主要功能是繪制數(shù)據(jù)基本圖和復合圖。

2.2.1 報警管理

一條報警規(guī)則的基本信息包括報警類型、報警條件和是否自動報警。報警類型包括超限報警和突變報警。報警條件設置支持簡單的閾值設置（上下限）、邏輯運算（與、或、非、異或等）、簡單的數(shù)學運算（加、減、乘、除等）和復雜的數(shù)學運算（絕對值、平方、立方、平方根、立方根、指數(shù)、對數(shù)、最大值、最小值等）。

報警條件中的參數(shù)來自標準化處理以后的參數(shù)，可支持多時間點和多發(fā)位運算。參數(shù)的發(fā)位由后綴“_1”（左發(fā)）、“_2”（右發(fā)）區(qū)分，如果只有一個發(fā)位，不加后綴。采樣點的位置由后綴$n表示，其中n為一整數(shù)，$n表示當前值的前第n點。如果沒有此后綴，則表示當前值。參數(shù)的來源由后綴@ACARS、@OEM區(qū)分。ACARS報文中發(fā)位可以根據(jù)參數(shù)后綴直接區(qū)分。OEM中發(fā)位需要根據(jù)發(fā)動機裝機信息確定。

2.2.2 報警歷史信息查詢

該部分中工程師可以查看所有報警記錄，并且能夠查看報警時對應的具體數(shù)據(jù)。在報警位置可根據(jù)自身經(jīng)驗添加處理意見。

2.2.3 基本圖繪制

用戶可以根據(jù)需求將一段時間內的數(shù)據(jù)以圖形的方式展現(xiàn)出來，從而讓用戶通過觀察圖形更好地判斷發(fā)動機當前和未來的狀態(tài)。該部分的主要功能有圖形展示、圖形文件導出以及數(shù)據(jù)文件導出。圖形展示功能中提供如下五種展示方式：

單參數(shù)VS時間：X軸為時間，Y軸為一種參數(shù)值；

單參數(shù)VS采樣點：X軸為采樣點，Y軸為一種參數(shù)值；

單參數(shù)VS單參數(shù)：X軸和Y軸均為單參數(shù)值，用戶可根據(jù)需求自己設置X軸和Y軸的參數(shù)；

多參數(shù)VS時間：X軸為時間，Y軸至少為一種參數(shù)值；

多參數(shù)VS采樣點：X軸為采樣點，Y軸至少為一種參數(shù)值；上述5種方式中均可以繪制至少一臺發(fā)動機的數(shù)據(jù)圖形。

其中多參數(shù)VS時間和多參數(shù)VS采樣點圖形可以選擇如下兩種繪圖方式：參數(shù)集中顯示（所有數(shù)據(jù)均在同一個界面中展示）；參數(shù)獨立顯示（每個界面僅顯示單個參數(shù)數(shù)據(jù)，N個界面對應N個參數(shù)）。

2.2.4 復合圖繪制

在基本圖的基礎上，可選擇在同一個界面上繪制多個基本圖形成復合圖。

3 關鍵技術

本系統(tǒng)采用NoSQL方式存儲航空發(fā)動機運行過程中產(chǎn)生的海量數(shù)據(jù)。NoSQL是一個云計算背景下蓬勃發(fā)展的分布式、非關系型數(shù)據(jù)庫系統(tǒng)，支持半結構化、結構化數(shù)據(jù)的高并發(fā)讀寫，存儲鍵值、列族、文檔、圖等多種數(shù)據(jù)類型。NoSQL具有良好的可伸縮性和可擴展性，能夠有效利用云計算所提供的海量數(shù)據(jù)存儲管理、分布式并行計算能力［4］。

目前出現(xiàn)了一些NoSQL非關系數(shù)據(jù)存儲系統(tǒng)，例如，Apache社區(qū)的HBase，F(xiàn)acebook的Cassandra，Amazon的Dynamo以及支持高效數(shù)據(jù)查詢的內存數(shù)據(jù)存儲系統(tǒng)Redis等等。這些數(shù)據(jù)存儲都采用了key-value數(shù)據(jù)模型.在key-value數(shù)據(jù)存儲系統(tǒng)中，HBase的使用最為廣泛［5］。

本系統(tǒng)使用HBase分布式數(shù)據(jù)庫存儲數(shù)據(jù)。HBase（Hadoop Database）是一個結構化數(shù)據(jù)的分布式存儲系統(tǒng)，是Hadoop項目的子項目，采用基于列而不是基于行的模式來存儲數(shù)據(jù)［6］。

本系統(tǒng)在存儲與管理發(fā)動機監(jiān)控數(shù)據(jù)時需要區(qū)分不同的發(fā)動機，因此HDFS（Hadoop實現(xiàn)的一個分布式文件系統(tǒng)）中以發(fā)動機序列號（ESN）作為文件相應目錄的唯一標識。Hadoop海量數(shù)據(jù)文件存儲結構如圖3所示。

系統(tǒng)中對發(fā)動機監(jiān)控數(shù)據(jù)的查詢主要依據(jù)時間和標準化監(jiān)控屬性ID，因此將標準化監(jiān)控屬性ID和時間的組合作為行健。系統(tǒng)對數(shù)據(jù)操作時還需要區(qū)分監(jiān)控數(shù)據(jù)產(chǎn)生的飛行階段和數(shù)據(jù)來源，因此除了保存監(jiān)控屬性值外，還需要保存飛行階段和數(shù)據(jù)來源信息。HBase數(shù)據(jù)模型如表1所示。

表1 HBase數(shù)據(jù)模型

RowKey是標準化監(jiān)控屬性ID和時間的組合。標準監(jiān)控屬性ID為固定32位長度。時間精確到秒，并統(tǒng)一使用yyyymmddhhmmss的格式，因此長度固定為14位。兩者組合起來，RowKey為固定長度的46位。

Column Family為一個列族，因為所有列都表示一個時間段內的發(fā)動機信息，本研究中只設一個列族，命名為MONITORDATA，意為監(jiān)控數(shù)據(jù)。

VALUE為標準化監(jiān)控屬性的值，一般為double類型。

DATA SOURCE為數(shù)據(jù)來源，系統(tǒng)中數(shù)據(jù)一般來自發(fā)動機原始報文或廠家數(shù)據(jù)，使用數(shù)據(jù)來源ID表示，一般為固定32位長度。

FLIGHT PHASE為飛行階段，系統(tǒng)中的飛行階段有起飛、爬升、巡航等階段，使用飛行階段ID表示，一般為固定32位長度。

因為系統(tǒng)中狀態(tài)監(jiān)控數(shù)據(jù)的新增、修改操作都設置為在后臺定時運行，并且該運行時間一般選擇在非工作時間，不會影響用戶對該系統(tǒng)的使用。因此以下主要針對海量數(shù)據(jù)的查詢效率進行測試。為更好地判斷新系統(tǒng)存儲海量數(shù)據(jù)時的查詢效率，采用對比試驗方法對HBase和Oracle的查詢性能進行測試。根據(jù)實際需求，增加特殊檢索方式，例如根據(jù)時間段檢索。前文已給出HBase的數(shù)據(jù)模型，對比用的Oracle數(shù)據(jù)模型如表2所示。

表2 Oracle數(shù)據(jù)模型

鑒于測試環(huán)境要求，Oracle中暫時存有一千萬條左右的數(shù)據(jù)，HBase中數(shù)據(jù)數(shù)量級在億以上。Oracle為一臺單獨的數(shù)據(jù)庫服務器，HBase為三臺配置完全一樣的PC機組成的一個服務器集群。各PC機配置如表3所示。

表3 測試中各PC機的配置

選取2015年1月1日至1月10日的數(shù)據(jù)對兩種存儲系統(tǒng)進行測試，HBase和Oracle的檢索效率對比如表4所示。

表4 HBase和Oracle檢索效率對比

通過表4結果可知，在HBase存儲系統(tǒng)硬件條件較弱且存儲數(shù)據(jù)更多的情況下，HBase的檢索時間始終保持在10秒以內，而Oracle的檢索時間隨著檢索結果集的增加而迅速增加。工程實際中，監(jiān)控數(shù)據(jù)檢索的結果集經(jīng)常十分巨大，此時Oracle的檢索速度明顯不能滿足需求，而HBase的檢索速度基本不受結果集大小的限制，能夠滿足系統(tǒng)檢索速度需求。

4 結束語

發(fā)動機健康管理系統(tǒng)需要以海量的發(fā)動機狀態(tài)監(jiān)控數(shù)據(jù)為基礎。鑒于傳統(tǒng)的關系型數(shù)據(jù)庫無法滿足航空公司存儲和管理海量數(shù)據(jù)過程中的某些需求，本研究提出采用NoSQL方式存儲管理海量發(fā)動機監(jiān)控數(shù)據(jù)。通過分析航空公司的實際需求，給出了針對民用航空發(fā)動機的大數(shù)據(jù)管理系統(tǒng)的架構與模塊設計。選取當前使用較為廣泛的HBase分布式數(shù)據(jù)庫存儲數(shù)據(jù)，根據(jù)發(fā)動機監(jiān)控數(shù)據(jù)的特點設計數(shù)據(jù)模型。為測試新系統(tǒng)的查詢性能，設計試驗與Oracle數(shù)據(jù)庫進行對比。實驗結果表明，檢索數(shù)據(jù)集較大時基于HBase的存儲系統(tǒng)搜索效率要高于基于Oracle的存儲系統(tǒng)，并且搜索時間始終控制在10秒以內。本研究提出的基于HBase的民用航空發(fā)動機大數(shù)據(jù)管理系統(tǒng)可以彌補傳統(tǒng)關系型數(shù)據(jù)庫部分性能上的不足，為航空發(fā)動機后續(xù)健康管理提供更加堅實的基礎。

［1］楊俊生.大數(shù)據(jù)時代數(shù)據(jù)存儲技術的發(fā)展［J］.電子世界，2014，（05）：11-12.

［2］周新穎，譚朝陽，劉倩.挖掘“大數(shù)據(jù)”時代QAR如何改變飛機運營［N］.中國民航報，2013，10（21）：004.

［3］鐘雨，黃向東，劉丹等.大規(guī)模裝備監(jiān)測數(shù)據(jù)的NoSQL存儲方案［J］.計算機集成制造系統(tǒng)，2013，19（12）：3008-3016.

［4］陳崇成，林劍鋒，吳小竹等.基于NoSQL的海量空間數(shù)據(jù)云存儲與服務方法［J］.地球信息科學學報，2013，15（02）：166-174.

［5］葛微，羅圣美，周文輝等.HiBase：一種基于分層式索引的高效HBase查詢技術與系統(tǒng)［J］.計算機學報，2016，39（01）：140-153.

［6］曾大聃，周傲英譯.Tom White.Hadoop權威指南（中文版）［M］.北京：清華大學出版社，2010.

10.16640/j.cnki.37-1222/t.2016.20.126

民航局科技計劃項目（面向航空運輸集團公司的航空發(fā)動機健康管理云服務平臺開發(fā)與應用）；山東省自主創(chuàng)新及成果轉化專項資助項目（2014CGZH1101）

田亞鵬（1991-），男，河北邯鄲人，碩士研究生。