基于HBase和Hive 的航班延誤平臺的存儲方法

吳仁彪，劉 超，屈景怡

(中國民航大學天津市智能信號與圖像處理重點實驗室，天津300300)

(*通信作者電子郵箱qujingyicauc@163．com)

0 引言

根據(jù)中國民航航空局發(fā)布的2016年民航行業(yè)發(fā)展統(tǒng)計公報，2014年，全國民航運輸機場起降架次793．3萬架次，比上一年增長8．4%;2015年，全國民航運輸機場起降架次856．6萬架次，比上一年增長8．0%;2016年，全國民航運輸機場起降架次923．8萬架次，較上一年增長7．9%［1］。航班架次如此高速的增長，對民航信息技術(shù)部門來說不僅是數(shù)據(jù)流的增加、業(yè)務的拓寬以及工作量的加重，而且這些新的挑戰(zhàn)對民航海量數(shù)據(jù)的存儲以及處理速度提出了新的要求。由此可見，民航界逐步向數(shù)據(jù)量大、文件類型多、價值密度低與速度時效高的“4V”特性的大數(shù)據(jù)行業(yè)發(fā)展［2］。為了應對航班持續(xù)穩(wěn)定高速增長的挑戰(zhàn)，亟需探索新的海量航班延誤平臺的設計方法和機制。目前我國民航使用的是由國家空管局與航空公司合作的航空類企業(yè)開發(fā)的航班延誤平臺，主要面向旅客提供機票購買、酒店預訂、航班路線查看、行程記錄等服務，同時幫助旅客實時查看航班準點信息，獲得航班起飛時間與到達時間，國內(nèi)比較常用的應用有航班管家、航旅縱橫、飛常準等APP，國外有PlaneFinder、FlightTrack等。目前這些國內(nèi)APP大多數(shù)是基于傳統(tǒng)基礎架構(gòu)的，航班數(shù)據(jù)一般存儲于價格昂貴的大型服務器上，數(shù)據(jù)庫管理軟件采用關系型數(shù)據(jù)庫系統(tǒng)，比如Oracle、SQL Server等，而報表系統(tǒng)也正是建立在這些關系型數(shù)據(jù)庫上，業(yè)務耦合度緊密，系統(tǒng)擴展性較差、成本較高。

作為高效的數(shù)據(jù)存儲和處理能力的HBase數(shù)據(jù)庫可以輕松滿足海量航班數(shù)據(jù)擴展的要求［3］，文獻［4－7］將HBase數(shù)據(jù)庫分別應用于城市智能交通系統(tǒng)、船舶自動識別系統(tǒng)、云智能室內(nèi)環(huán)境監(jiān)測系統(tǒng)、生物DNA與蛋白質(zhì)對存儲等領域，都驗證了HBase作為大規(guī)模數(shù)據(jù)存儲的可靠性。文獻［8］基于協(xié)處理器在HBase區(qū)域直接創(chuàng)建二級索引，需要將不同索引字段組合一同存進HBase索引表，造成了額外存儲空間的浪費。文獻［9］基于Solr實現(xiàn)了HBase數(shù)據(jù)庫中數(shù)據(jù)的檢索，然而只是簡單地實現(xiàn)了HBase二級索引，并未將索引的建立與查詢一體化，僅在Solr管理頁面進行了檢索，沒有考慮實際頁面加載大量數(shù)據(jù)所帶來的延遲問題。Hive作為Hadoop生態(tài)圈的數(shù)據(jù)倉庫工具，利用存儲于Hadoop底端的海量分布式文件進行 MapReduce離線并行計算［10－11］，并提供類 SQL語句的開發(fā)語言，其優(yōu)勢在于快速實現(xiàn)數(shù)據(jù)的統(tǒng)計分析，而不必特定編寫MapReduce任務。文獻［12－13］在Hive基礎上構(gòu)建了一種并行數(shù)據(jù)倉庫，驗證了千萬條數(shù)據(jù)復雜查詢和多維分析的性能，確保了聯(lián)機查詢和分析的可操作性。

因此，本文在上述技術(shù)基礎上，設計了基于大數(shù)據(jù)架構(gòu)的航班延誤平臺，其主要特色在于結(jié)合了HBase數(shù)據(jù)庫和SolrCloud搜索引擎，利用HBase可擴展性和SolrCloud支持的SQL功能接口的特點，并合理設計行鍵，從而實現(xiàn)了海量航班數(shù)據(jù)存儲以及基于Web界面的航班實時跟蹤，然后給出兩種航班數(shù)據(jù)查詢算法，通過實驗驗證了該查詢算法的高效性。最后，設計了基于Hive的航班數(shù)據(jù)倉庫，為航班延誤的治理提供了決策層面的技術(shù)支持。

1 本文整體架構(gòu)設計

J2EE是一種利用Java2平臺來簡化企業(yè)解決方案的開發(fā)、部署和管理相關復雜問題的體系架構(gòu)，它使用了多層分布式的應用模型，包括客戶層、Web層、業(yè)務層、企業(yè)信息系統(tǒng)層［14］。本文在J2EE的體系結(jié)構(gòu)基礎上，引入大數(shù)據(jù)計算組件、大數(shù)據(jù)分布式數(shù)據(jù)庫、大數(shù)據(jù)可視化等組件，重新設計了海量航班監(jiān)控平臺的系統(tǒng)架構(gòu)模型。

如圖1所示，航班延誤大數(shù)據(jù)平臺由航班監(jiān)控模塊、航班查詢模塊和航班分析模塊組成。航班監(jiān)控模塊負責航班的監(jiān)控顯示，定時請求航班數(shù)據(jù)存儲層以獲取臨時緩沖表的最新航班數(shù)據(jù)，并依據(jù)成功執(zhí)行回調(diào)數(shù)據(jù)里的航班號這一字段在LeafLet地圖添加新的移動圖標或為原有移動圖標添加新的航路點;航班數(shù)據(jù)查詢模塊負責海量歷史航班數(shù)據(jù)的搜索查詢，結(jié)合Solr搜索引擎，為HBase海量航班數(shù)據(jù)提供多條件過濾查詢的功能;航班數(shù)據(jù)分析模塊負責將HBase表中的每日航班數(shù)據(jù)抽取、轉(zhuǎn)換、加載進Hive數(shù)據(jù)倉庫，并調(diào)用Spark引擎將Hive中的數(shù)據(jù)轉(zhuǎn)換成圖表，以供決策支持。

基于HBase海量航班數(shù)據(jù)存儲、基于SolrCloud海量航班二級索引以及基于Hive海量航班數(shù)據(jù)倉庫的構(gòu)建是航班延誤平臺存儲的核心組成部分，下面分別對這三部分所涉及的功能模塊進行介紹。

圖1 航班延誤大數(shù)據(jù)平臺系統(tǒng)架構(gòu)模型Fig．1 System architecture model of flight delay big data platform

HBase是一種構(gòu)建在分布式文件系統(tǒng)(Hadoop Distributed File System，HDFS)之上的分布式、面向列的、可伸縮的動態(tài)模式數(shù)據(jù)庫，用于實時讀寫、隨機訪問超多規(guī)模數(shù)據(jù)集，包括主服務器HMaster、管理和服務區(qū)域塊HRegionServer，以及作為協(xié)調(diào)服務中心的ZooKeeper。本文搭建的HBase集群體系框架圖2所示。

圖2 HBase集群的體系框架Fig．2 Framework of HBase cluster

Solr是一個基于Lucene而實現(xiàn)的開源搜索服務器，除了提供強大的全文搜索外，還包括如圖3所示的高亮顯示、動態(tài)聚類、數(shù)據(jù)集合、切面檢索等功能［15］。SolrCloud實現(xiàn)了基于Solr的分布式檢索，作為集群的配置信息中心——ZooKeeper實現(xiàn)了自動容錯功能，保證了航班延誤大數(shù)據(jù)平臺穩(wěn)定性。

圖3 Solr組成模塊Fig．3 Solr component module

Hive是一個利用類似傳統(tǒng)SQL語句HiveQL實現(xiàn)海量數(shù)據(jù)的查詢、轉(zhuǎn)換、提取等操作的數(shù)據(jù)倉庫，Hive的組成模塊如圖4所示，它提供了三種用戶接口:命令行模式、瀏覽器模式以及基于Thrift服務器的客戶端模式［16］。Hadoop集群支持處理TB或PB級以上數(shù)據(jù)，以Hadoop MapReduce為框架的Hive因此也能滿足有延遲的海量數(shù)據(jù)交互查詢和分析要求。

圖4 Hive組成模塊Fig．4 Modules of Hive

2 基于HBase海量航班數(shù)據(jù)存儲方案設計

海量航班數(shù)據(jù)的集中存儲目前是各大航空公司亟待解決的問題，逐步由傳統(tǒng)的關系型數(shù)據(jù)庫轉(zhuǎn)到可擴展的NoSQL型分布式數(shù)據(jù)庫將是民航業(yè)未來數(shù)據(jù)存儲方向。HBase數(shù)據(jù)庫作為一種構(gòu)建在HDFS之上的分布式、面向列的、可伸縮的動態(tài)模式數(shù)據(jù)庫，通常用于實時讀寫、隨機訪問超大規(guī)模數(shù)據(jù)集，可以作為海量航班數(shù)據(jù)存儲很好的選擇。

2．1 HBase數(shù)據(jù)庫部署與設計

HBase遵從主從服務器架構(gòu)，它由 HRegion服務器(RegionServer)群和 HBase Master服務器(HMaster)構(gòu)成。HBase服務器的所有協(xié)調(diào)服務由ZooKeeper進行協(xié)調(diào)，除此之外，ZooKeeper還負責Hbase命名空間里的meta表信息的存儲，感知RegionServer的健康狀態(tài)，通過ZooKeeper的Master Election機制保證HMaster單個機制，避免HMaster的單節(jié)點故障［17］。

HBase自帶ZooKeeper，本文在HBase集群所在三臺機器上獨立部署ZooKeeper，避免HBase和ZooKeeper的強耦合，方便后期對HBase集群的升級、管理以及對航班延誤大數(shù)據(jù)平臺的擴展，因此本文禁用HBase自帶的ZooKeeper。同時，考慮到ZooKeeper作為SolrCloud的集中式配置中心，而它的作用是分布式協(xié)調(diào)者，一旦組件信息、索引信息等配置變動，所有的機器都可以通過它感知到，同時ZooKeeper可以為突然崩潰的程序提供自動容錯的機會，通過重新選出候選者，從而執(zhí)行上次未完成的任務。獨立部署的ZooKeeper也可以為HBase二級索引提供支持，實現(xiàn)自動負載均衡。

2．2 海量航班數(shù)據(jù)rowkey的設計

由于航班數(shù)據(jù)的索引不直接采用Coprocessor協(xié)處理器方案，而是引入了HBase與Solr結(jié)合的方案，所以HBase中行鍵無需依據(jù)索引字段來設計，行鍵的設計需要盡量避免“熱點”問題［18］。“熱點”問題是由于將遞增的航班飛行時間當作行鍵，向HBase寫入操作總是集中在一個數(shù)據(jù)管理基本單元區(qū)域塊region上。解決的思路是隨機散列化飛行時間，并提前為航班數(shù)據(jù)表建立預分區(qū)，隨機散列化飛行時間采用信息摘要算法(Message-Digest Algorithm，MD5)［19］。飛行時間time由不含分隔符的飛行日期與實際飛行時間兩部分組成，時間格式不夠的填充位用零補足。由于航班查詢模塊會根據(jù)每個飛機圖標的航班號直接索引，所以行鍵末位還需要拼接上航班號，最后需要將飛行時間轉(zhuǎn)換為哈希值再轉(zhuǎn)換化Bytes類型，加上自身和航班號轉(zhuǎn)為Bytes類型的值，即可組成最終行鍵。最后生成rowkey的函數(shù)如(1)所示:

2．3 海量航班數(shù)據(jù)列簇的設計

航班數(shù)據(jù)主要字段包括:航空公司、航班號、尾流號、起飛機場、降落機場、起飛日期、預計起飛時間、實際起飛時間、預計降落時間、實際降落時間、延誤時長等109個字段。起飛時間與降落時間采用4位時間占位符進行存儲，精確到分鐘級別。飛行日期采用8位占位符，其他字段統(tǒng)一解析成字符串類型存儲。因為列簇越少時region刷新 I/O開銷越少，且航班數(shù)據(jù)各字段應用較統(tǒng)一，所以所有字段共同構(gòu)成航班數(shù)據(jù)唯一列簇FProperties。海量航班數(shù)據(jù)列簇設計如表1所示。

表1 海量航班數(shù)據(jù)表結(jié)構(gòu)Tab．1 Structure of massive flight data table

2．4 海量航班數(shù)據(jù)索引字段的存儲

為了實現(xiàn)多條件查詢的業(yè)務需求，本文設計了基于Solr+HBase的存儲組合方案。HBase作為航班數(shù)據(jù)主表的存儲機制，Solr作為主表rowkey以及涉及條件過濾字段的存儲機制。過濾查詢6個字段包括:飛行日期、航空公司號、尾流號、航班號、起飛機場、降落機場。Solr模式配置中7個參數(shù)類型都是字符串:indexed屬性必須全部設置為true，最終返回值為符合條件的rowkey字段，固只需要將rowkey的stored屬性設置為true，其他無關過濾字段設置為false，以便節(jié)省存儲空間，uniqueKey對應的字段為rowkey，條件過濾字段設置信息如表2所示。

表2 條件過濾字段信息表Tab．2 Information table of conditional filter fields

實現(xiàn)基于Solr索引數(shù)據(jù)存儲的基本思路是在往HBase主表插入航班數(shù)據(jù)之前，調(diào)用HBase的Server端的協(xié)處理器Obervers，Observers是散布在 RegionServer端的 hook鉤子，這些hook函數(shù)是實現(xiàn)二級索引條件存儲的基礎，RegionServer會調(diào)用 Observers的鉤子函數(shù) prePut，讀取 Put類包含的rowkey以及查詢字段，將rowkey設置為模式配置中的唯一鍵，同其他字段一同封裝在Document中并保存到緩存里，達到上限之后則將緩存內(nèi)所有的數(shù)據(jù)提交到SolrCloud中，從而在SolrCloud中為所有的涉及條件過濾的字段建立索引。鉤子函數(shù)完成索引數(shù)據(jù)提交之后，Region Server才會真正去執(zhí)行插入操作，將航班號、起飛機場、降落機場、尾流號、起飛時間等信息插入HBase主表中。

實際情況下，飛機在空中飛行時持續(xù)報告它的飛行信息，接收端必須一直處于接收狀態(tài)，比如實際情況下飛機上的廣播式自動相關監(jiān)視(Automatic Dependent Surveillance-Broadcast，ADS-B)發(fā)射機與地面的ADS-B接收機之間的航班信息傳輸。類似發(fā)射機采用UDP(User Datagram Protocol)的客戶端來代替，類似接收機以部署的服務器端來代替，客戶端是一個由C++編寫的可執(zhí)行程序，啟動后創(chuàng)建客戶端數(shù)據(jù)報套接字并開啟線程，間隔將每行數(shù)據(jù)拼接成字符串并放進緩存，利用抓取到的應用程序數(shù)據(jù)直接拋到網(wǎng)絡中，從而向應用層提供無連接的服務。

3 基于SolrCloud的海量航班數(shù)據(jù)關聯(lián)查詢

在建立上述海量航班飛行數(shù)據(jù)存儲及二級索引的基礎上，本文利用存儲于SolrCloud中的索引文件及返回的行鍵對航班飛行數(shù)據(jù)進行多級關聯(lián)查詢。多條件查詢請求參數(shù)標記為 Q(QD，QA，QT，QF，QO，QD)，其中:QD 表示飛行日期，QA表示航空公司號，QT表示尾流號，QF表示航班號，QO表示起飛機場，QD表示降落機場。根據(jù)航班查詢模塊所選的參數(shù)，找出符合查詢條件(QD，QA，QT，QF，QO，QD)的所有飛行數(shù)據(jù)，并在Web界面分頁顯示。除了采用基于SolrCloud索引策略，還給出基于Filter過濾器的查詢策略，并針對每種查詢策略提出一種查詢算法。

算法1 基于Filter過濾器的多條件索引查詢。

輸入 封裝 QD，QA，QT，QF，QO，QD 查詢條件的conditionModel。

輸出 航班數(shù)據(jù)結(jié)果集列表flightsList。

先判斷每個查詢條件是否為空，然后將非空查詢條件封裝在它所對應的SingleColumnValueFilter過濾器中，并依次將新生成的過濾器放在集合列表中。如果集合列表不為空，根據(jù)集合列表生成過濾器集合，并設置過濾組合條件為“與”，得到符合QD＆QA＆QT＆QF＆QO＆QD查詢要求的組合過濾器集合，根據(jù)過濾器集合設置掃描對象scan，最后通過scan掃描HBase原表，得到集合列表flightsList返回給客戶端。

該算法在查詢條件較少且返回的數(shù)據(jù)量不大的情況下效果比較好，但是在過濾條件較少時往往導致返回數(shù)據(jù)量很大，比如只限制QD與再增加一個QA查詢條件時查詢范圍也許會增加一個數(shù)量級。其次該算法使用了全表掃描，這是一種代價昂貴的查詢辦法，直接導致查詢性能低下，HBase查詢代價最小的辦法就是通過行鍵查詢，因此本文設計了基于SolrCloud二級索引查詢方法，將行鍵的索引提前存儲于SolrCloud中，獲取行鍵后再在主表中依據(jù)行鍵查詢。

算法2 基于SolrCloud的多條件二級索引查詢。

HBase二級索引目前業(yè)界采用的解決方案主要有MapReduce方案、ITHBase方案、IHBase方案、華為的HIndex方案［20］，檢索性能正穩(wěn)步提升。本文在華為協(xié)處理器創(chuàng)建二級索引表的基礎上，將HBase協(xié)處理器所持有的類似觸發(fā)器應用于SolrCloud索引字段的創(chuàng)建上，把HBase毫秒級實時搜索的優(yōu)勢與Solr多條件組合查詢的優(yōu)勢結(jié)合起來，實現(xiàn)了基于SolrCloud的HBase海量數(shù)據(jù)多條件快速檢索。具體查詢步驟如算法2所示:

輸入 封裝 QD，QA，QT，QF，QO，QD 查詢條件的conditionModel。

輸出 航班數(shù)據(jù)結(jié)果集列表flightsList。

實際查詢過程如圖5所示:1)建立完索引;2)客戶端直接發(fā)送包含(QD，QA，QT，QF，QO，QD)查詢請求 SQL命令，Solr Client通過內(nèi)部處理邏輯接收并解析SQL語句后依據(jù)分片數(shù)目啟動分布式查詢，查詢結(jié)果返回給最初的Replica，Replica基于一定的規(guī)則合并子查詢結(jié)果;3)Replica將最終結(jié)果返回給用戶，這些符合查詢條件的結(jié)果是以集合形式返回，而這些結(jié)果正是HBase中符合過濾條件數(shù)據(jù)的行鍵，這樣用戶就可以快速獲得符合過濾條件的rowkey值，拿到這些rowkey之后放進緩存列表中;4)根據(jù)這些行鍵在HBase中執(zhí)行批量查詢，依據(jù)行鍵找到對應的region位置，獲取region所對應的列的值;5)HBase最終返回符合過濾條件的所有結(jié)果。

采用Solr作為HBase的二級索引替代方案，除了因為Solr擁有獨立、高并發(fā)的企業(yè)級搜索優(yōu)勢外，還因為它是采用純Java并基于文本搜索引擎庫Lucene而開發(fā)的子項目，與目前大數(shù)據(jù)HBase、Hive、Hadoop等組件能很好地兼容，并能支持多種輸出格式，包括可擴展標記語言(Extensible Markup Language，XML)、JavaScript對象標記語言(JavaScript Object Notation，JSON)、擴展樣式表轉(zhuǎn)換語言(Extensible Stylesheet Language Transformation，XSLT)，支持的分頁索引功能彌補了HBase數(shù)據(jù)庫分頁索引的不足，也方便了后期對航班延誤大數(shù)據(jù)平臺的功能擴展［21］。

圖5 基于Solr的二級索引執(zhí)行流程Fig．5 Secondary index execution flow chart based on Solr

4 基于Hive海量航班數(shù)據(jù)倉庫的構(gòu)建

在實現(xiàn)了基于HBase、SolrCloud的航班存儲與航班查詢框架后，航班查詢和航班跟蹤兩個在線事務模塊基本完成。通過利用HBase數(shù)據(jù)庫歷史航班數(shù)據(jù)，構(gòu)建基于Hive海量航班飛行信息數(shù)據(jù)倉庫來尋找與航班延誤最具有相關性的指標參數(shù)，統(tǒng)計分析出各大機場日均延誤、時均延誤等與航班延誤相關的統(tǒng)計分析情況，作為航班延誤大數(shù)據(jù)平臺航班數(shù)據(jù)報表層。

4．1 基于Hive海量航班數(shù)據(jù)倉庫多維分析

對于航班飛行信息數(shù)據(jù)來說，典型的主題域包括航班、機場等主題。其中航班主題記錄了與單個航班延誤相關的歷史飛行數(shù)據(jù)，如計劃起飛時間、計劃降落時間、實際起飛時間、實際降落時間等;而機場主題記錄了機場全部的歷史航班數(shù)據(jù)，包括航班號、尾流號等。本文利用HBase提供的航班飛行數(shù)據(jù)，在已提前制定的飛行計劃靜態(tài)狀態(tài)量中加入每日航班飛行監(jiān)控狀態(tài)屬性，依據(jù)機場和飛機的每日、每月、每季度、每年航班延誤等新規(guī)則，將這些規(guī)則作為數(shù)據(jù)維，定時將HBase存儲的前一階段航班數(shù)據(jù)映射到Hive中，結(jié)合這些航班數(shù)據(jù)維，生成符合業(yè)務主題的航班延誤決策信息，并將決策信息存入Hive事實表中，從而實現(xiàn)航班數(shù)據(jù)的入庫操作。

基于Hive的航班數(shù)據(jù)倉庫系統(tǒng)旨在高效地存儲和分析持續(xù)不斷產(chǎn)生的海量航班飛行數(shù)據(jù)，以高度整合的形式集成與展現(xiàn)歷史航班延誤數(shù)據(jù)，能夠為航空公司運營者、機場管理者、空域調(diào)度者和旅客提供每月與每季度的延誤原因占比、各大機場與航空公司每季度與每年延誤排名情況、機場某月每日平均延誤分鐘數(shù)、各大機場當日時間區(qū)間的延誤航班數(shù)量與某飛機的歷史延誤統(tǒng)計。

4．2 基于Hive的海量航班數(shù)據(jù)倉庫系統(tǒng)結(jié)構(gòu)設計

針對航班延誤海量數(shù)據(jù)和數(shù)據(jù)倉庫統(tǒng)一管理與分析的應用需求，本文設計了基于Hive的海量航班數(shù)據(jù)倉庫，系統(tǒng)結(jié)構(gòu)主要由4層組成:負責底部數(shù)據(jù)存儲的存儲層、負責執(zhí)行SQL語句的計算層、負責查詢處理的控制層和負責具體業(yè)務需求的應用層。存儲層是基于HDFS，數(shù)據(jù)來源包含HBase存儲的每日飛行數(shù)據(jù)和提前制定好的飛行計劃報文;計算層由Hadoop底層MapReduce與Spark底層基于彈性分布數(shù)據(jù)集的有向無環(huán)圖組成，選擇的方式由實際業(yè)務的需求與繁瑣程度決定;控制層包括HiveQL和SparkSQL兩種查詢語言組成的數(shù)據(jù)庫引擎，處理來自應用層的不同請求，引擎的選擇決定了計算層的選擇方式;應用層主要集成了各大機場延誤報表、航班延誤輔助決策等組件，可以實現(xiàn)每日報表的生成。

4．3 基于Hive海量航班數(shù)據(jù)倉庫工作流程

航班分析模塊為用戶提供了良好的Web界面，利用JSP標簽庫來提供執(zhí)行OLAP(Online Analytical Processing)操作的相關按鈕以及數(shù)據(jù)顯示，主要標簽包括地區(qū)、機場、飛行日期、飛行時間段等。為了實現(xiàn)對時間維度的上卷、下鉆等操作，需要創(chuàng)建表的時候?qū)⒛J靜態(tài)分區(qū)屬性設置為動態(tài)分區(qū)屬性，后臺根據(jù)用戶的選擇實現(xiàn)查詢分析處理并將結(jié)果保存至MySQL數(shù)據(jù)庫中，即可實現(xiàn)針對機場、航班等不同主題的即席查詢，最終以基于FusionCharts的圖表形式呈現(xiàn)。

航班數(shù)據(jù)倉庫的數(shù)據(jù)加載方式有兩種:存儲處理程序模塊StorageHandlers用于映射HBase已有歷史航班數(shù)據(jù)，在Hive中創(chuàng)建與HBase表與列簇相互對應的歷史航班數(shù)據(jù)外部映射表;批量裝載Load方式用于飛行計劃靜態(tài)數(shù)據(jù)。所有與主題相關的航班數(shù)據(jù)裝載進Hive之后，客戶端發(fā)起航班延誤數(shù)據(jù)分析請求，進而啟動一個 Spark應用程序，通過SparkSQL解析請求命令，由于已經(jīng)完成Spark與Hive的整合配置，SparkSQL可以直接對數(shù)據(jù)位于HDFS中Hive表執(zhí)行關系型操作，也可以將涉及延誤主題的表直接轉(zhuǎn)換成彈性分布式數(shù)據(jù)集，進行復雜運算后再保存到延誤主題表中。返回符合查詢請求命令的數(shù)據(jù)之后，根據(jù)這些數(shù)據(jù)完成涉及的查詢與分析、匯總、報表生成等操作，并將最終延誤分析結(jié)果返回給客戶端。海量航班數(shù)據(jù)倉庫工作過程如圖6所示。

圖6 海量航班數(shù)據(jù)倉庫工程過程Fig．6 Engineering process of mass flight data warehouse

5 實驗及結(jié)果分析

本實驗主要針對多條件查詢速度、航班延誤大數(shù)據(jù)平臺的海量航班的可擴展性以及多維展示進行測試。實驗環(huán)境采用4個節(jié)點的集群，外加一個客戶端。其中服務器hadoop01與 hadoop03內(nèi)存26 GB、硬盤 1 TB、2．40 GHz的 Xeon E5620 CPU，hadoop02與 hadoop04 的內(nèi)存 8 GB、硬盤 500 GB、2．66 GHz的Quad Q8400 CPU，4臺應用服務器節(jié)點用于分發(fā)航班數(shù)據(jù)以及應用邏輯處理;客戶端的配置為內(nèi)存12 GB、硬盤1 TB、3．4 GHz的i7-6700 CPU，用于模擬海量航班的并發(fā)請求。

航班延誤大數(shù)據(jù)平臺的主界面如圖7所示，地圖庫采用的是目前最流行的可視化工具之一LeafLet［22］，大體分成兩部分:側(cè)邊航班信息收縮菜單欄和右側(cè)航班實時跟蹤界面。收縮菜單欄包括航班信息、航班數(shù)據(jù)、天氣、延誤警示、延誤分析、聯(lián)系我們這6個大模塊，并且每個模塊都有一級右拉懸浮頁面，可以輕松地關閉懸浮頁面并來回自由切換任何一個菜單。當右側(cè)地圖界面任何一架航班被首次點擊時，航班信息欄都會主動彈出包含該趟航班的飛行信息，包括:起飛機場、降落機場、航班號、計劃起飛時間、計劃降落時間等。

圖7 航班延誤大數(shù)據(jù)平臺可視化界面Fig．7 Visualization interface of flight delay big data platform

5．1 基于HBase海量航班數(shù)據(jù)多條件查詢速度測試

設定查詢條件為6個:飛行日期、航空公司號、尾流號、航班號、起飛機場、降落機場。測試數(shù)據(jù)分3組:A組為44．3萬條，B組為91．1萬條，C組為139．8萬條。通過監(jiān)控層的航班數(shù)據(jù)查詢模塊進行實驗驗證，參考標準是查詢條件輸入時刻到頁面獲得實時響應這段時間間隔，分別比較HBase在算法1和算法2查詢條件下頁面響應時間。過濾條件設置如下:

條件一 起飛機場為SAN;

條件二 起飛機場為SAN，飛行日期為2015-01-17;

條件三 起飛機場為SAN，飛行日期為2015-01-17，降落機場為SMF;

條件四 起飛機場為SAN，飛行日期為2015-01-17，降落機場為SMF，航班號為2800。

從圖8的3張圖對比可以發(fā)現(xiàn)，無論是在算法2的條件下還是算法1的條件下，當索引字段越多的時候，實時查詢效率越高，因為過濾條件越多，返回結(jié)果越少，無論是數(shù)據(jù)庫查找還是SolrCloud搜索時間都相應減少了;無論過濾條件有多少，算法2相比算法1的查詢速度都有所提高，尤其當過濾條件超過兩個時，算法1在三種數(shù)據(jù)量的情況下頁面響應時間保持在7 s、25 s、50 s左右，可以推知隨著數(shù)據(jù)量的增長，這種響應時間也會隨之延長，而算法2的集群響應時間維持在毫秒級別，即使在C組百萬條數(shù)據(jù)量下，也可以達到實時刷新頁面的效果。

通過圖9可以發(fā)現(xiàn)，當過濾條件為4個，添加二級索引的集群索引速度在A組數(shù)據(jù)下提高了53．6倍，在B組數(shù)據(jù)下索引速度提高了195．3倍，在C組數(shù)據(jù)下索引速度提高了265．0倍，可見當數(shù)據(jù)量越大時，查詢速度差距越明顯，可以推測添加二級索引的集群將表現(xiàn)出更加高效的航班查詢性能。

圖8 多條件組合下頁面響應時間Fig．8 Page response time under different multi-condition combination

圖9 多條件組合下頁面響應提高倍數(shù)Fig．9 Speedup of page response under different multi-conditional combination

分析其中主要原因是因為SolrCloud能夠很好地支持多條件查詢，通過索引字段分布式過濾查詢，可以直接獲取符合過濾條件的行鍵，從而間接支持HBase的行鍵索引;而HBase支持行鍵毫秒級的實時查詢，所以查詢效率成數(shù)量級地提高;而沒有添加索引的集群由于過濾條件太多，多次使用過濾器，需要大量的磁盤IO，再加上數(shù)據(jù)量的劇增，自然速度降低。其中在條件一下，查詢速度提高倍數(shù)并沒有隨著數(shù)據(jù)量的增加而穩(wěn)步提高，主要是因為返回數(shù)據(jù)量太大，頁面加載延遲造成的。

可以看到HBase高效的查詢性能是在建立合適rowkey的基礎上，過多使用filter將明顯降低查詢性能。HBase主要優(yōu)勢體現(xiàn)在海量數(shù)據(jù)查詢上，一旦數(shù)據(jù)量達到上億條，它的速度優(yōu)勢將會更加明顯。綜上分析可以得出，HBase數(shù)據(jù)庫基本符合海量航班跟蹤平臺的設計需求。

5．2 航班延誤大數(shù)據(jù)平臺的可擴展性測試

航班延誤大數(shù)據(jù)平臺承受負載最大的部分是HBase數(shù)據(jù)庫，客戶端的高速讀入以及Web界面持續(xù)的post請求都意味著大量的IO消耗，所以航班延誤大數(shù)據(jù)平臺的可擴展性、讀寫速度以及處理能力與HBase數(shù)據(jù)庫直接相關。作為列式存儲的數(shù)據(jù)庫，HBase的優(yōu)點之一是可以自動切分數(shù)據(jù)，使它在水平方向具有較好的擴展性。實驗發(fā)現(xiàn)，增加一個HRegionServer的節(jié)點僅僅需要在配置文件夾下的regionservers文件中增加一個IP或者主機名就可以。

5．3 基于Hive海量航班延誤數(shù)據(jù)展示測試

在完成航班數(shù)據(jù)倉庫的分析與設計之后，針對航班延誤數(shù)據(jù)多種主題，本文采取多種類型圖表來測試分析結(jié)果。對于某架航班，關注的是它每趟航程具體延誤時長，因此采用二維折線圖直接顯示延誤時長;對于交通管制、惡劣天氣、航空公司影響、航班到達晚點、安全因素等延誤原因，我們更關注延誤原因占比以及最易導致延誤因素，因此采用3D動態(tài)餅圖;對于延誤機場，采用2D倒序條形圖依照延誤率從大到小依次排列;對于每個機場每天平均延誤時長，可以采用3D Pareto圖立體化顯示延誤走勢。我們以機場每天平均延誤時長為例，通過提取 A機場1月份所有延誤數(shù)據(jù)，然后經(jīng)SparkSQL轉(zhuǎn)換得到的該月每天平均延誤時長，最終測試結(jié)果如圖10所示。

圖10 A機場2015年1月份每日平均延誤時長測試效果Fig．10 Test result of average delay per day at airport A in January 2015

6 結(jié)語

本文設計了面向大數(shù)據(jù)的航班延誤平臺，實現(xiàn)了海量航班在LeafLet上的實時監(jiān)控，將實際飛行情況下航班數(shù)據(jù)與飛行計劃數(shù)據(jù)作為數(shù)據(jù)源，依據(jù)其特征關聯(lián)與查詢需求，設計了行鍵與航班索引字段分層存儲于SolrCloud的存儲技術(shù)。此外，針對 HBase的非行鍵數(shù)據(jù)檢索的問題，提出了基于SolrCloud的查詢方案，使用層次索引快速獲取要檢索的數(shù)據(jù)，并通過與基于過濾器的查詢方案對比，驗證了該存儲方案的高效性。在此數(shù)據(jù)基礎上，依據(jù)航班延誤查詢所關心的主題，進一步建立了基于Hive的集中統(tǒng)一的航班數(shù)據(jù)倉庫，后期通過與SparkSQL交互查詢實驗驗證了搭建的數(shù)據(jù)倉庫的可行性。以后的工作將會放在預測航班延誤上，將預測到的信息嵌入到航班延誤大數(shù)據(jù)平臺預留接口中，從而完善航班延誤平臺。