吳仁彪，劉 超，屈景怡

(中國民航大學(xué)天津市智能信號與圖像處理重點(diǎn)實(shí)驗(yàn)室，天津300300)

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

0 引言

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

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

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

1 本文整體架構(gòu)設(shè)計(jì)

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

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

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

圖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ù)庫，用于實(shí)時讀寫、隨機(jī)訪問超多規(guī)模數(shù)據(jù)集，包括主服務(wù)器HMaster、管理和服務(wù)區(qū)域塊HRegionServer，以及作為協(xié)調(diào)服務(wù)中心的ZooKeeper。本文搭建的HBase集群體系框架圖2所示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在建立上述海量航班飛行數(shù)據(jù)存儲及二級索引的基礎(chǔ)上，本文利用存儲于SolrCloud中的索引文件及返回的行鍵對航班飛行數(shù)據(jù)進(jìn)行多級關(guān)聯(lián)查詢。多條件查詢請求參數(shù)標(biāo)記為 Q(QD，QA，QT，QF，QO，QD)，其中:QD 表示飛行日期，QA表示航空公司號，QT表示尾流號，QF表示航班號，QO表示起飛機(jī)場，QD表示降落機(jī)場。根據(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。

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

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

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

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

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

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

實(shí)際查詢過程如圖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之后放進(jìn)緩存列表中;4)根據(jù)這些行鍵在HBase中執(zhí)行批量查詢，依據(jù)行鍵找到對應(yīng)的region位置，獲取region所對應(yīng)的列的值;5)HBase最終返回符合過濾條件的所有結(jié)果。

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

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

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

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

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

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

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

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

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

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

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

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

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

5 實(shí)驗(yàn)及結(jié)果分析

本實(shí)驗(yàn)主要針對多條件查詢速度、航班延誤大數(shù)據(jù)平臺的海量航班的可擴(kuò)展性以及多維展示進(jìn)行測試。實(shí)驗(yàn)環(huán)境采用4個節(jié)點(diǎn)的集群，外加一個客戶端。其中服務(wù)器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臺應(yīng)用服務(wù)器節(jié)點(diǎn)用于分發(fā)航班數(shù)據(jù)以及應(yīng)用邏輯處理;客戶端的配置為內(nèi)存12 GB、硬盤1 TB、3．4 GHz的i7-6700 CPU，用于模擬海量航班的并發(fā)請求。

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

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

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

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

條件一 起飛機(jī)場為SAN;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)語

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