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

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