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

吳仁彪，劉 超，屈景怡

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

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

0 引言

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

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

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

1 本文整體架構設計

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

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

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

圖1 航班延誤大數據平臺系統架構模型Fig．1 System architecture model of flight delay big data platform

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

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

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

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

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

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

2 基于HBase海量航班數據存儲方案設計

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

2．1 HBase數據庫部署與設計

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

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

2．2 海量航班數據rowkey的設計

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

2．3 海量航班數據列簇的設計

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

表1 海量航班數據表結構Tab．1 Structure of massive flight data table

2．4 海量航班數據索引字段的存儲

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

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

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

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

3 基于SolrCloud的海量航班數據關聯查詢

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

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

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

輸出 航班數據結果集列表flightsList。

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

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

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

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

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

輸出 航班數據結果集列表flightsList。

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

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

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

4 基于Hive海量航班數據倉庫的構建

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

4．1 基于Hive海量航班數據倉庫多維分析

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

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

4．2 基于Hive的海量航班數據倉庫系統結構設計

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

4．3 基于Hive海量航班數據倉庫工作流程

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

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

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

5 實驗及結果分析

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

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

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

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

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

條件一 起飛機場為SAN;

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

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

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

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

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

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

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

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

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

5．2 航班延誤大數據平臺的可擴展性測試

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

5．3 基于Hive海量航班延誤數據展示測試

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

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

6 結語

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