基于HBase的民用航空發動機大數據管理系統為克服傳統關系型數據庫存儲管理海量航空發動機狀態監控數據的不足，本研究提出了基于HBase的民用航空發動機大數據管理系統。首先分析了該系統的功能需求，給出了系統整體架構與模塊設計，并對關鍵技術進行了闡述。最后設計試驗對比HBase與Oracle的搜索效率。試驗結果表明檢索結果集較大時HBase的搜索效率明顯高于Oracle。本研究中提出的航空發動機大數據管理系統為發動機海量數據的存儲管理提供了一種解決方案。標簽：民用航空發動機；大數據；NoSQL；HBase；搜索效率0引言作為飛機的核心組成部分，航空發動機的健康管理是航空公司日常工作的重中之重。航空發動機是一個十分復雜的系統，其日常運營中會產生大量的狀態監控數據。這些監控數據能夠幫助工程師了解發動機當前狀態，判斷發動機有無發生故障，并根據當前狀態制定相應的維修計劃。因此實現對航空發動機數據的有效監控與管理成為各航空公司的迫切需求。以往航空發動機的狀態監控數據都存儲在關系型數據庫中。工程上應用較廣泛的關系型數據庫包括Oracle、SQLServer、DB2、Sybase、Access等[1]。在存儲數據量較小時，采用傳統的關系型數據庫進行檢索，其檢索速度是可以滿足日常需求的。然而隨著發動機狀態監控技術的進步以及航空公司機隊飛機數量的快速增加，航空公司收集到的狀態監控數據量逐漸變的非常龐大，并且還有不斷增長的趨勢。以國內某航空公司為例，2013年時其飛機保有量大約為300架，每天大約有1300多個航班。在這種情況下，僅僅是快速存取記錄器（QAR）記錄的數據量就達到每年2TB的規模[2]。這僅僅是QAR的數據量，其他數據來源如飛機通信尋址報告系統（ACRAS）、原始設備制造商（OEM）等都會產生大量的監控數據。隨著航空公司機隊規模的擴大以及技術的進步，其獲得的發動機狀態監控數據量將變得更加巨大。雖然關系型數據庫性能非常好，但它畢竟是通用型的數據庫，并不能完全適應所有用途。傳統的關系型數據庫需要固定的模式來描述數據，因此難以適應工況數據模式多變的特點；傳統的數據庫很難進行橫向擴展。對于容量擴充的需求只能通過停機維護和數據遷移來實現，時間和財力成本較高。此外，傳統的關系型數據庫難以滿足高并發讀寫的需求，簡單查詢時返回結果不夠快并且對硬件性能要求較高[3]。由于存在這些缺陷，僅依靠關系型數據庫本身的索引或者分區分表等方法來存儲規模日趨增長的發動機監控數據，其存儲和使用效率會變的非常低下，嚴重時甚至會導致數據庫服務器崩潰。針對航空公司有效存儲管理發動機海量監控數據的迫切需求，本研究提出一種面向民用航空發動機海量監控數據的存儲管理方法，并設計了相應的大數據存儲管理系統。使用關系型數據庫和分布式文件系統構成兩級存儲模式。上層利用Oracle實現航空發動機管理機制和基礎數據的組織；底層利用HBase分布式文件系統實現對海量數據的高性能存儲管理。這種結構可以實現航空發動機基礎數據與監控數據的動態耦合，一定程度上實現了航空公司有效存儲管理海量監控數據的需求。1系統需求分析飛機從起飛到降落，發動機各個參數由飛機狀態監控系統（ACMS）的傳感器實時測得并被編入發動機報，通過飛機通訊尋址與報告系統（ACARS）發往地面站。航空發動機的生產廠家（OEM）也會采用自己研制的發動機狀態監控軟件對ACARS數據進行處理，并將處理后的數據（OEM數據）發送給航空公司。目前這兩類數據在航空公司的應用是比較廣泛和成熟的，因此本研究專門針對民用航空發動機這兩類數據設計一套海量數據存儲和管理系統。該系統應具有如下功能：a）定制解析協議解析發動機監控數據。如上所述，目前航空公司經常使用ACARS報文數據和OEM數據對發動機進行管理。但這兩類數據原始形式并不能直接為工程師所用，必須采用專門的解析協議對其解析后方能使用。ACARS報文一般為txt格式文件，OEM數據一般為excel文檔。b）監控發動機參數中出現的不合理狀況并給出報警信息。需要針對不同發位、不同班次的發動機進行監控并綜合各方面的信息判斷發動機當前狀態。在報警功能中報警規則應能夠根據工程師需求人工修改，并且報警歷史應該被保存以供工程師日后查看。c）為用戶提供數據的圖形化展示。該部分應該為用戶提供包括數據圖形展示、圖形導出以及數據導出等功能。d）保證工程師能及時檢索到所需數據。系統中將對海量數據（億級別以上）的檢索速度應該控制在15秒以內。2系統設計針對航空公司有效存儲管理發動機海量監控數據的迫切需求，本研究設計了一個基于HBase的民用航空發動機大數據管理系統。該系統可以分為四層，從下而上依次為數據層、業務邏輯層、表現層和客戶層。數據層使用關系型數據庫和分布式文件系統構成兩級存儲模式。業務邏輯層主要功能是解析航空發動機監控數據。表現層主要功能是報警管理和趨勢分析。客戶層是web瀏覽器，用戶在客戶端無需額外安裝任何軟件，只要有可運行的網絡并且計算機安裝了web瀏覽器即可訪問該系統。該系統的整體架構如圖1所示。下面對系統的業務邏輯層和表現層進行詳細闡述。2.1業務邏輯層業務邏輯層的主要功能是定制解析協議，將原始ACARS報文和OEM數據解析成標準化、規范化并且可直接操作的有效數據。該層可進一步分解為SMI標簽管理、子標簽管理、標準化參數管理、參數監控類型管理、ACARS模板管理和OEM模板管理六個模塊。2.1.1SMI標簽管理SMI是區分報文的首層標志。報文的形式主要有參數監視報（DFD）、故障報（CFD）、運控報（M10）、廠家報文（OEM）。前三種報文分別來自機載系統的三個不同模塊，其中DFD來自發動機參數監視系統ACMS，CFD來自故障監視系統CMC，M10來自運控系統ACARS，這三種類型的報文都通過ACARS統一向地面發送，地面站未對其進行區分。因此需要設置首層標志SMI來區分不同類型的報文。2.1.2子標簽管理子標簽是區分報文的下一層標志。比如ACARS報文又可以進一步分成起飛狀態報（TKO），巡航狀態報（CRZ）等。采用子標簽可以對報文進行更加具體的分類。2.1.3標準化參數管理各個發動機廠家對各項參數的命名并沒有統一規范。為方便管理數據，需要制定一套統一的發動機參數命名規范。根據該規范將各個廠家提供的數據標準化，這樣做有利于日后對發動機數據的管理和利用。2.1.4參數監控類型管理方便用戶根據自身需求選擇不同的參數監控類型，比如氣路監控、振動監控等。2.1.5ACARS模板管理該部分的主要功能是配置參數在報文中的位置，將每種報文中各個參數所在行列記錄在xml模板中。因為xml可以明確表示各個參數的屬性信息和所處位置，采用dom4j可以對xml文件進行解析和生成。xml模板的格式如圖2所示。2.1.6OEM模板管理該部分主要確定OEM文件中各行各列的意義及其對應關系。在解析OEM文件時需要獲取標題所在行、數據開始行、發動機序列號（ESN）所在列、時間所在列、時間格式、各列參數與標準化參數的對應關系、參數是否需要導入數據庫、飛行階段設定規則等信息。這個模塊可以根據用戶需求自定義格式，增加操作靈活性。2.2表現層表現層主要包括報警管理和趨勢分析兩個模塊。報警管理的主要功能是設定報警規則和查詢報警歷史信息。趨勢分析的主要功能是繪制數據基本圖和復合圖。2.2.1報警管理一條報警規則的基本信息包括報警類型、報警條件和是否自動報警。報警類型包括超限報警和突變報警。報警條件設置支持簡單的閾值設置（上下限）、邏輯運算（與、或、非、異或等）、簡單的數學運算（加、減、乘、除等）和復雜的數學運算（絕對值、平方、立方、平方根、立方根、指數、對數、最大值、最小值等）。報警條件中的參數來自標準化處理以后的參數，可支持多時間點和多發位運算。參數的發位由后綴“_1”（左發）、“_2”（右發）區分，如果只有一個發位，不加后綴。采樣點的位置由后綴$n表示，其中n為一整數，$n表示當前值的前第n點。如果沒有此后綴，則表示當前值。參數的來源由后綴@ACARS、@OEM區分。ACARS報文中發位可以根據參數后綴直接區分。OEM中發位需要根據發動機裝機信息確定。2.2.2報警歷史信息查詢該部分中工程師可以查看所有報警記錄，并且能夠查看報警時對應的具體數據。在報警位置可根據自身經驗添加處理意見。2.2.3基本圖繪制用戶可以根據需求將一段時間內的數據以圖形的方式展現出來，從而讓用戶通過觀察圖形更好地判斷發動機當前和未來的狀態。該部分的主要功能有圖形展示、圖形文件導出以及數據文件導出。圖形展示功能中提供如下五種展示方式：單參數VS時間：X軸為時間，Y軸為一種參數值；單參數VS采樣點：X軸為采樣點，Y軸為一種參數值；單參數VS單參數：X軸和Y軸均為單參數值，用戶可根據需求自己設置X軸和Y軸的參數；多參數VS時間：X軸為時間，Y軸至少為一種參數值；多參數VS采樣點：X軸為采樣點，Y軸至少為一種參數值；上述5種方式中均可以繪制至少一臺發動機的數據圖形。其中多參數VS時間和多參數VS采樣點圖形可以選擇如下兩種繪圖方式：參數集中顯示（所有數據均在同一個界面中展示）；參數獨立顯示（每個界面僅顯示單個參數數據，N個界面對應N個參數）。2.2.4復合圖繪制在基本圖的基礎上，可選擇在同一個界面上繪制多個基本圖形成復合圖。3關鍵技術本系統采用NoSQL方式存儲航空發動機運行過程中產生的海量數據。NoSQL是一個云計算背景下蓬勃發展的分布式、非關系型數據庫系統，支持半結構化、結構化數據的高并發讀寫，存儲鍵值、列族、文檔、圖等多種數據類型。NoSQL具有良好的可伸縮性和可擴展性，能夠有效利用云計算所提供的海量數據存儲管理、分布式并行計算能力[4]。目前出現了一些NoSQL非關系數據存儲系統，例如，Apache社區的HBase，Facebook的Cassandra，Amazon的Dynamo以及支持高效數據查詢的內存數據存儲系統Redis等等。這些數據存儲都采用了key-value數據模型.在key-value數據存儲系統中，HBase的使用最為廣泛[5]。本系統使用HBase分布式數據庫存儲數據。HBase（HadoopDatabase）是一個結構化數據的分布式存儲系統，是Hadoop項目的子項目，采用基于列而不是基于行的模式來存儲數據[6]。本系統在存儲與管理發動機監控數據時需要區分不同的發動機，因此HDFS（Hadoop實現的一個分布式文件系統）中以發動機序列號（ESN）作為文件相應目錄的唯一標識。Hadoop海量數據文件存儲結構如圖3所示。系統中對發動機監控數據的查詢主要依據時間和標準化監控屬性ID，因此將標準化監控屬性ID和時間的組合作為行健。系統對數據操作時還需要區分監控數據產生的飛行階段和數據來源，因此除了保存監控屬性值外，還需要保存飛行階段和數據來源信息。HBase數據模型如表1所示。RowKey是標準化監控屬性ID和時間的組合。標準監控屬性ID為固定32位長度。時間精確到秒，并統一使用yyyymmddhhmmss的格式，因此長度固定為14位。兩者組合起來，RowKey為固定長度的46位。ColumnFamily為一個列族，因為所有列都表示一個時間段內的發動機信息，本研究中只設一個列族，命名為MONITORDATA，意為監控數據。VALUE為標準化監控屬性的值，一般為double類型。DATASOURCE為數據來源，系統中數據一般來自發動機原始報文或廠家數據，使用數據來源ID表示，一般為固定32位長度。FLIGHTPHASE為飛行階段，系統中的飛行階段有起飛、爬升、巡航等階段，使用飛行階段ID表示，一般為固定32位長度。因為系統中狀態監控數據的新增、修改操作都設置為在后臺定時運行，并且該運行時間一般選擇在非工作時間，不會影響用戶對該系統的使用。因此以下主要針對海量數據的查詢效率進行測試。為更好地判斷新系統存儲海量數據時的查詢效率，采用對比試驗方法對HBase和Oracle的查詢性能進行測試。根據實際需求，增加特殊檢索方式，例如根據時間段檢索。前文已給出HBase的數據模型，對比用的Oracle數據模型如表2所示。鑒于測試環境要求，Oracle中暫時存有一千萬條左右的數據，HBase中數據數量級在億以上。Oracle為一臺單獨的數據庫服務器，HBase為三臺配置完全一樣的PC機組成的一個服務器集群。各PC機配置如表3所示。選取2015年1月1日至1月10日的數據對兩種存儲系統進行測試，HBase和Oracle的檢索效率對比如表4所示。通過表4結果可知，在HBase存儲系統硬件條件較弱且存儲數據更多的情況下，HBase的檢索時間始終保持在10秒以內，而Oracle的檢索時間隨著檢索結果集的增加而迅速增加。工程實際中，監控數據檢索的結果集經常十分巨大，此時Oracle的檢索速度明顯不能滿足需求，而HBase的檢索速度基本不受結果集大小的限制，能夠滿足系統檢索速度需求。4結束語發動機健康管理系統需要以海量的發動機狀態監控數據為基礎。鑒于傳統的關系型數據庫無法滿足航空公司存儲和管理海量數據過程中的某些需求，本研究提出采用NoSQL方式存儲管理海量發動機監控數據。通過分析航空公司的實際需求，給出了針對民用航空發動機的大數據管理系統的架構與模塊設計。選取當前使用較為廣泛的HB