基于HBase+ ElasticSearch的海量交通數據實時存取方案設計

董長青，任女爾，張慶余，田玉靖

北京卡達克數據技術中心軟件業(yè)務本部，天津 300300

基于HBase+ ElasticSearch的海量交通數據實時存取方案設計

董長青，任女爾，張慶余，田玉靖

北京卡達克數據技術中心軟件業(yè)務本部，天津 300300

交通流數據具有數據海量、存儲和交互速率快等特征，因此其數據的采集、存儲及檢索成為了車輛遠程監(jiān)控平臺中的關鍵問題。采用LVS集群技術進行數據采集負載均衡，隊列緩存處理I/O時延，HBase進行分布式數據存儲；針對Hadoop實時在線數據處理不足的問題，整合ElasticSearch并構建了分層索引。通過關鍵技術的設計和實現(xiàn)，車輛監(jiān)控由400輛擴展到上萬輛，PB級數據在線查詢速度提升了10～20倍，驗證了方案的高效性。

Hadoop/HBase；ElasticSearch；Linux虛擬服務器；海量數據；實時

1 引言

在車聯(lián)網飛速發(fā)展的時代，智能交通在發(fā)展中的一些問題也逐步暴露出來。如在數據采集中，常用的通信技術只能同時監(jiān)控幾百輛車；在數據結構單一、海量的數據存取和分析時，傳統(tǒng)關系型數據庫應用能力大幅度降低等。如果車輛每2 s上傳一條約120 byte的全球定位系統(tǒng)（global positioning system，GPS）數據，統(tǒng)計600輛車的數據，則月統(tǒng)計數據為87 GB，一年將約有1 TB的數據需要進行存儲。在統(tǒng)計過程中，高峰期車輛數量遠不止這些。在很多企業(yè)的實際環(huán)境中，基于傳統(tǒng)技術的監(jiān)控平臺進行系統(tǒng)優(yōu)化處理后，其數據處理能力也只能達到幾百輛車的收集功能，一旦進入峰值，系統(tǒng)幾乎無法正常運行。此外，車聯(lián)網數據不僅包括GPS數據，還包括車輛控制器局域網絡（controller area network，CAN）數據、圖像、視頻等數據，在采集和檢索技術上往往與其實際生產需求相差較遠。

大數據技術的快速發(fā)展為這一情況帶來了良好的發(fā)展前景和機遇，尤其是當前被廣泛探索應用的Hadoop、Spark等技術，針對TB甚至PB級的數據，其豐富的組件在數據存儲和挖掘、分析方面提出了完善的處理方案。本文通過分析當前的分布式軟件技術，結合HBase數據庫進行設計改進，設計了一套針對交通數據采集、存儲和檢索的方案。

2 技術介紹

在車聯(lián)網遠程監(jiān)控平臺中，數據的采集、存儲及檢索問題是傳統(tǒng)的關系型數據平臺無法高效處理的。

2.1 Linux虛擬服務器技術

在數據采集方面，交通數據到監(jiān)控平臺之間一般采用3G/4G等技術，通過socket進行TCP/IP數據傳輸。但是每個端口負載能力有限，最高能夠支持400輛車同時上傳數據，高于400輛車同時傳輸時，數據時延甚至丟失的現(xiàn)象較為明顯。本研究使用Linux虛擬服務器（Linux virtual server，LVS）技術進行負載均衡，從而提供給用戶訪問一臺超高性能服務器的效果。LVS技術支持通過配置多個高速局域網服務器來進行任務分配，其對外的接口則為固定的IP地址和端口，從而提供任務分發(fā)轉移的負載調度功能。此外，LVS技術支持熱處理，在正常工作的情況下增加或者刪除節(jié)點。LVS的負載調度器（director）可以設置3種工作模式：一是地址轉換，負載調度器通過算法將內網地址進行映射，外網數據分組通過映射的地址進行分發(fā)；二是通過IP隧道，負載調度器進行調度請求，通過IP隧道客戶端數據分組進行封裝發(fā)給服務器，服務器直接響應客戶端；三是直接路由，適用于集群內的服務器都在一個網段，數據分組直接由負載調度器發(fā)給實際服務器，該種方式速度快，且開銷較少。LVS調度算法主要有等比例輪轉、加權輪循、目標地址散列調度、源地址散列調度等靜態(tài)調度算法以及最少連接、加權最少連接、永不排隊、動態(tài)目標地址散列、帶復制的動態(tài)目標地址散列等動態(tài)調度算法。IP虛擬服務器（IP virtual server，IPVS）技術是一種工作在網絡模型第四層的高效交換機，可以針對不同的網絡選擇不同的調度算法。

在小型的分布式負載中，唯一從軟件技術上能達到硬件F5量級的方案就是采用LVS技術。參考文獻[1]使用LVS技術解決負載網站的負載均衡配置問題，參考文獻[2]描述了LVS技術的高可用負載均衡方案，但其后續(xù)處理案例也主要針對超文本傳輸協(xié)議（hypertext transfer protocol，HTTP）。本文基于LVS的IP虛擬分發(fā)技術進行socket通信集群負載。

2.2 HBase存儲技術

數據采集接收伴隨著海量數據的存儲問題，性能較好的傳統(tǒng)關系型數據庫一般采用Oracle、DB2等。但在實際應用中，交通流數據結構單一，結構內部卻比較靈活，當有些字段在數據存儲中只為部分數據設計時，其存儲空間將造成極大的浪費，再加上數據量巨大，交通流數據顯然不適合傳統(tǒng)的存儲方式。隨著分布式數據庫的發(fā)展，HBase作為列式存儲數據庫，為交通流的數據存儲提供了高效的寫入性能和靈活的存儲方式。在其存儲結構上，HBase按照字典順序進行排序，行鍵（RowKey）直接作為其中的一級索引，為其良好的讀寫性能提供了基礎。

2.3 HBase檢索

HBase內置了兩張存儲表（ROOT和META）進行區(qū)域分布及區(qū)域詳細情況的存儲。在普通的數據檢索過程中，首先從ZooKeeper上定位到META表的位置，然后從中獲取對應的RegionServer，根據行鍵從這兩張內置表中查詢數據的region，然后查找到對應的行鍵，從而進行數據檢索。但是HBase的存儲業(yè)務表之間沒有直接的關聯(lián)，而且單一索引很可能造成數據查詢變成全表掃描，因此當查詢海量數據時，對關聯(lián)數據或復雜條件的支持較差。目前，針對這一問題，已經發(fā)展了ITHBase（帶索引的事務性HBase）、IHBase（indexed HBase，是HBase的擴展，用于支持更快的掃描）等二級索引方式。ElasticSearch是一種基于Lucene的實時大數據搜索引擎，與適用于獨立應用的Solr相比，更適用于云計算環(huán)境。參考文獻[3]中采用對交通流數據進行存儲，但其存儲行鍵設計在實時查詢性能上經實驗檢測存在較大的問題，參考文獻[4]和參考文獻[5]引入了大數據的實時處理辦法進行日志的處理，本文通過進一步研究和改進，引進ElasticSearch進行數據索引，設計其將必要條件與其行鍵關聯(lián)起來，形成二級索引[6]，從而加快數據搜索速度。

圖1 海量交通流數據分布式存取架構

3 海量交通數據的存取架構設計

海量交通數據的存取架構是各個企業(yè)目前亟待解決的問題，并發(fā)采集數據、海量數據存儲及海量數據的檢索等問題，成為企業(yè)車聯(lián)網進程中的阻力。

3.1 系統(tǒng)架構

整體架構主要從采集、存儲和檢索3個方面進行設計改進并實現(xiàn)。整體架構如圖1所示。

當數據從交通流中獲取時，由LVS進行IP轉發(fā)負載均衡，實現(xiàn)車輛高并發(fā)數據的接收工作；接收服務器收到數據以后，對數據進行預處理操作，分別按照業(yè)務類型轉入緩沖區(qū)，通過HBase客戶端進行數據寫入操作，同時將數據索引[7]建立到ElasticSearch中，根據數據的狀況動態(tài)調配處理層進行數據線程數的設置，保證高并發(fā)寫入速度；在Web應用中讀取數據時，根據業(yè)務需求的不同設置不同的線程數量。

3.2 關鍵設計

3.2.1 LVS負載均衡

結合實際生產環(huán)境，研究采用速度快、開銷少的直接路由的工作模式以及IPVS技術進行算法調度[8]，配置4臺服務器分別作為LVS以及3臺數據處理設備，操作系統(tǒng)采用Cento 6。

如圖2所示，配置3臺數據處理服務器，然后配置對應的LVS，在數據由車載終端發(fā)送到路由時，由路由直接轉發(fā)到LVS，LVS通過調度算法計算將數據發(fā)送到合適的數據處理服務器，數據處理服務器接收數據以后，直接通過路由響應終端。主要實現(xiàn)步驟如下。

● 配置數據處理服務器，禁止地址解析協(xié)議（address resolution protocol，ARP）請求。

● 設置LVS子網掩碼與數據處理服務器一致，開啟報文轉發(fā)功能，增加網卡VIP記錄“ipvsadm -A -t 10.8.10.177:20080 -s rr -p 2000”，含義為各個車載訪問地址及其端口號，設定2 s為超時時間，調度為等比例輪詢調度（round robin，RR）算法。

● LVS服務配置數據處理服務器，按照“ipvsadm -a -t 10.8.10.177:20080 -r 10.8.10.162: 20080 -g”指令分別配置3臺數據處理服務器的訪問地址端口及直接路由模式。

圖2 系統(tǒng)LVS負載均衡架構

此時配置完畢，該方案具有較強的可擴展性，一方面可以根據監(jiān)控車輛的負載情況增加或者減少數據處理服務器的數據，另一方面可以根據緩沖和寫入線程的情況保證數據寫入時延在秒級以內。此外，可以參考參考文獻[2]進行LVS備份方案的設定。

3.2.2 多源存儲設計

交通流數據從LVS分發(fā)到各個數據處理服務器以后，由接收端應用進行預處理，按源分類進行緩沖存儲操作，通過監(jiān)控程序根據各個數據源中的數據大小判定啟動不同數量的寫入線程，默認寫入線程為3個，當數據量過大時將增加寫入線程。寫入線程主要負責寫入HBase數據和構建ElasticSearch索引工作。

該架構設計主要分為GPS數據、CAN數據和多媒體感知數據，然后根據每種數據的結構不同分別存儲到不同的緩沖區(qū)中。按每秒接收10萬條GPS和CAN數據計算，3臺數據處理服務器每臺每秒需接收（100 000×12 kB/3）/（1 024×1 024）≈0.39 MB數據，GPS和CAN數據緩沖區(qū)大小預設為4 MB，多媒體數據緩沖區(qū)大小設置為16 MB，即每臺數據處理服務器根據數據源由20 MB內存作為數據緩沖區(qū)，從而允許將一定數量的數據高效地進行存儲。對于分組數據，采用臨時緩沖區(qū)先行進行緩沖，組合成整個分組后再進入緩沖區(qū)，若數據大小大于緩沖剩余空間大小，則直接啟動額外的寫入線程進行存儲。各個文件結構設計如圖3所示。

以GPS數據為例，其在緩沖結構中存儲，采用時間值進行散列計算后存儲到固定個數的隊列中，如2016年1月13日13:42:57，設置t為20 161 452 663 777 771，進行求余計算，計算式為f(t)=t%n。設置n為3，即GPS數據源采用3組隊列，隊列索引分別為0、1、2，則f(t) = 20 161 452 663 777 771%3求余結果為1，因此將該數據放置在索引為1的隊列。

緩沖數據構建完畢以后，由寫入層以“先進后出”的原則讀取數據進行持久化存儲。在HBase數據存儲中，數據基本上按時間順序存儲，直接存儲會造成寫入熱點問題，即多個線程均指向一個HBase集群節(jié)點寫入的情況，因此采取以下優(yōu)化策略防止熱點和全表掃描。

● 在行鍵前加入散列前綴，利用如下計算方式計算：byte pre=(byte) (Long. hashCode(t) % ＜ regionservers no.＞)，將通過前綴加上時間戳散列值的方式產生的不同的數據分發(fā)到不同的RegionServer上。

● 取消自動寫入，根據實驗設置寫入緩沖區(qū)大小為20 MB，能提高千萬級數據同時插入的效率。

● 預分配region，建表時直接使用預分配region，避免單個region灌入數據。

通過以上措施，達到了良好的實現(xiàn)效果，加入索引提高查詢的性能，一定會降低寫入數據的性能，本文兼容性地考慮兩方面，并進行了綜合實現(xiàn)。

圖3 數據結構

3.2.3 索引方案改進

HBase本身主鍵構建了B+樹進行索引[9]，稱為一級索引，其對基于主鍵數據的查詢效率很高；然而對于非主鍵字段的查詢效率卻很低，對HBase大數據量的訪問，僅僅通過MapReduce和掃描器處理是不能達到令人滿意的效果的。其主要缺陷在于二級索引構建困難，重新構建表結構進行索引往往需要雙重查詢，而且難以維護索引數據與原數據的同步性。隨著ITHBase、IHBase以及華為技術有限公司（以下簡稱“華為”）的hindex項目的誕生，二級索引方案和效果不斷提升，本文基于華為二級索引方案進行改進，結合ElasticSearch通過多層索引和直接索引由業(yè)務引擎共享的方案來實現(xiàn)高性能索引改進方案。

（1）基于HBase表的二級索引方案設計

基于HBase表的二級索引方案設計主要采用索引表和數據表共存共享的方式構建，通過HBase的協(xié)處理器（coprocessor）構建與數據表相同和類似的索引，索引表行鍵設計為“數據表StartKey+IndexName +Value+數據表行鍵”的方式。通過使索引表和數據表擁有相同的StartKey并重寫均衡集群類（balance cluster）控制索引表的分配，使其索引表和數據表構建在相同的RegionServer上，并且在region分裂時也能同步進行分裂，這樣可以使得協(xié)處理器非常快速地在RegionServer上計算出相應的索引數據。IndexName和Value對應的為HBase數據中單列的值，如針對車輛監(jiān)測點進行的數據查詢，Value對應為監(jiān)測點的數值，從而通過索引查詢出某個檢測點所有的行鍵數據，進一步查詢數據。

如圖4所示，實線代表數據指向，虛線代表數據塊指向，索引表數據對數據表數據的行鍵進行進一步改造，增加索引名稱和索引數據。當數據進行分裂時，其對應的索引同步進行分裂，并且使用保持數據的StartKey起始一致。

（2）ElasticSearch構建

圖4 數據分區(qū)分裂表

通過索引表的方式構建二級索引以后，數據的查詢依然停留在依靠HBase數據表本身的能力去優(yōu)化查詢速度。本文在構建索引數據表基礎上同步構建ElasticSearch及緩存索引數據。如圖5所示，當負責寫入的線程進行寫入操作時，通過協(xié)處理器同步處理索引表數據，然后通過觀察者模式同步索引數據到ElasticSearch中，并且根據多源數據特性，將實時查詢的數據添加到內存索引緩沖區(qū)。

首先，開啟協(xié)處理器，通過HBase Shell激活協(xié)處理器的觀察者（observer）；通過繼承基類BaseRegionObserver，重寫postPut和postDelete方法。把生成的JAR包配置到寫處理器中，即可實現(xiàn)數據的同步。在實際數據操作過程中，交通流數據幾乎不會發(fā)生更改，但是會持續(xù)寫入，因此在由觀察者數據同步時采用了ElasticSearch的緩沖池批處理操作，當達到限值時進行同步寫入操作。此外，設置其分片值、緩存類型為軟引用（soft reference），并調整其最大緩存值等進行ElasticSearch調優(yōu)。

數據讀取過程如圖6所示，當發(fā)起數據讀取過程時，首先進行查詢。當數據讀取時，首先訪問ElasticSearch，根據查找到的索引表中的結果，調用協(xié)處理器進行數據實際行鍵查找，訪問數據表，從而得到數據，從協(xié)處理器返回給客戶端。通過該模式進行改進，數據查詢效率大幅度增加。

圖5 數據寫入過程

圖6 數據讀取過程

4 系統(tǒng)測試

本文主要從并發(fā)存儲的吞吐量、軌跡回放查詢速度進行了測試，從而驗證其并發(fā)寫入和實時讀取的性能。

4.1 并發(fā)存儲吞吐量測試

為了充分驗證本架構的可行性，分別測試1萬到1 000萬條數據的插入速度，并且從單機服務、不添加索引和添加索引3方面進行對比測試。圖7為測試結果。

其中，添加索引的情況比不添加索引的情況速度明顯降低，但插入數據完畢時間總體維持在秒級以內。此外，對數據進行了持續(xù)性測試，連續(xù)10 h以每秒13萬條數據的速度插入（相當于監(jiān)控了10萬輛車每秒上傳一次數據），其插入數據緩沖區(qū)平穩(wěn)保持在某個較低臨界值后不再變動。在數據進行索引插入時，能夠支持每秒7.84萬條數據平穩(wěn)運行，較不加索引時有一定降低，但整體插入速度能夠在秒級以內實現(xiàn)10萬級速度的插入。

4.2 軌跡回放查詢速度測試

軌跡回放主要從整體統(tǒng)計查詢和實時響應兩方面性能進行體現(xiàn)，圖8測試了在PB級數量基數水平上，結果集數量不同時的數據查詢效率。

當小結果集進行查詢時，不添加索引時響應速度在10 s以上，而進行索引時，數據查詢速度在1 s以內，速度提升了20倍左右。大結果集（萬級）進行查詢時，速度提升了9～10倍，實時查詢效率及速度大幅度提升。在實際應用中，20 min的軌跡回放約為600條數據，能夠實現(xiàn)5 s之內查詢，因為數據響應可分段，所以如果以5 min為時間段進行4次查詢，能夠達到頁面較為流暢的效果。

圖7 單機、添加索引集群、不添加索引集群數據

圖8 不同結果集數據查詢效率

此外，在研究傳統(tǒng)數據庫（如Oracle）在數據存取過程中的表現(xiàn)時，采用了按照月進行分區(qū)、創(chuàng)建復雜查詢條件索引、添加存儲過程、避免全表掃描操作（如執(zhí)行“l(fā)ike”語句）、建立緩存等設計。研究發(fā)現(xiàn)索引過多則寫入性能下降，而且對非結構化數據存儲支持性能不佳，在整體大數據操作上編程和配置的復雜度提高。研究測試了直接對GPS數據表進行插入和讀取操作的速度情況：在進行數據插入操作時（對比每分鐘插入數據量），百萬條以下的數據插入速度Oracle和HBase沒有明顯差異，但超過百萬條以后，Oracle的數據插入速度逐步下降，千萬條以上HBase數據插入速度比Oracle快2～7倍；在進行數據讀取操作時，HBase千萬條以上數據讀取速度是Oracle的5～15倍；在同時進行插入和讀取操作的過程時，HBase讀取速度比Oracle快15～30倍。在相同的硬件和網絡環(huán)境中分析對海量交通流數據的處理能力，HBase列式數據庫無論從插入性能還是讀取性能都可以調優(yōu)到更高水平。

5 結束語

LVS解決高并發(fā)接收數據的問題，通過多源緩存策略解決數據存儲不及時的問題，避免數據分組丟失；同時設計表級二級索引、引入ElasticSearch增加數據查詢速度?？傮w上本文通過設計高并發(fā)存儲架構和多層索引查詢架構，實現(xiàn)了交通流數據的高并發(fā)實時監(jiān)控數據存儲和查詢，從軟件架構上解決了基于Hadoop存儲數據對實時計算查詢支持度不夠的問題。下一步，將集中設計基于多層的熱點內存緩存方案，并設計響應的緩存命中策略來實現(xiàn)更高的實時性能。

[1] 王頤帥. 基于LVS 的服務器負載均衡技術[J].計算機系統(tǒng)應用, 2014, 23(7): 252-255. WANG Y S. Server load balancing architecture based on LVS[J]. Computer Systems & Applications, 2014, 23(7): 252-255.

[2] 劉敏娜, 張繼濤. 基于LVS+KEEPALIVED的高可用負載均衡研究與應用[J]. 自動化技術與應用, 2014, 33(11): 22-27. LIU M N, ZHANG J T. The study and application of based on the LVS + KEEPALIVED high avaliablility load balance[J]. Techniques of Automation and Applications, 2014, 33(11): 22-27.

[3] 陸婷, 房俊, 喬彥克. 基于HBase 的交通流數據實時存儲系統(tǒng)[J]. 計算機應用, 2015, 35(1): 103-107, 135. LU T, FANG J, QIAO Y K. HBase-based real-time storage system for traffic stream data[J]. Journal of Computer Applications, 2015, 35(1): 103-107, 135.

[4] 葛微, 羅圣美, 周文輝. HiBase：一種基于分層式索引的高效HBase 查詢技術與系統(tǒng)[J].計算機學報, 2015, 38(35): 1-15. GE W, LUO S M, ZHOU W H. HiBase:a hierarchical indexing mechanism and system for efficient HBase query[J]. Chinese Journal of Computers, 2015, 38(35): 1-15.

[5] 白俊, 郭賀彬. 基于ElasticSearch的大日志實時搜索的軟件集成方案研究[J]. 吉林師范大學學報（自然科學版）, 2014(1): 85-87. BAI J, GUO H B. The design of software integration for big log data real time search based on ElasticSearch[J]. Jilin Normal University Journal(Natural Science Edition), 2014(1): 85-87.

[6] 鐘雨, 黃向東, 劉丹, 等．大規(guī)模裝備監(jiān)測數據的NoSQL 存儲方案[J]. 計算機集成制造系統(tǒng), 2013, 19(12): 3008-3016. ZHONG Y, HUANG X D, LIU D, et al. NoSQL storage solution for massive equipment monitoring data management[J]. Computer Integrated Manufacturing Systems, 2013, 19(12): 3008-3016.

[7] SFAKIANAKIS G, PATLAKAS I, NTARMOS N, et al. Interval indexing and querying on key-value cloud stores[C]// The 29th IEEE International Conference on Data Engineering (ICDE), April 8-12, 2013, Brisbane, Australia. New Jersey: IEEE Press, 2013: 805-816.

[8] 蘇命峰, 陳文芳, 李仁發(fā). LVS 集群負載調度算法研究[J]. 長沙大學學報, 2012(5): 72-74. SU M F, CHEN W F, LI R F. Research on LVS cluster load scheduling algorithm[J]. Journal of Changsha University, 2012(5): 72-74.

[9] BAI J. Feasibility analysis of big log data real time search based on HBase and ElasticSearch[C]// 2013 Ninth International Conference on Natural Computation (ICNC), January 28-31, 2013, San Diego, USA. New Jersey: IEEE Press, 2013: 1166-1170.

Design scheme of massive traffic data real-time access based on HBase and ElasticSearch

DONG Changqing, REN Nver, ZHANG Qingyu, TIAN Yujing
Software Business Department, Beijing CATARC Data & Technology Center, Tianjin 300300, China

Traffic data has the characteristics of massive and real-time, and its massive data acquisition, storage and retrieval has become a key issue in the vehicle remote monitoring platform. According to the study of these problems, the cluster technology of LVS was used to solve the data acquisition load balance, the queue cache model was used to solve I/O delay, and HBase distributed data storage scheme was used to solve the massive data storage. HBase integration ElasticSearch, which was aimed to solve the real-time online data processing problems of Hadoop, was designed to build a hierarchical index. Through the design and implementation of the key technologies, the number of vehicle monitoring had been promoted from 400 to 1 million, online query speed increased about 10 to 20 times based on PB level data. The results verified the efficiency of the scheme.

Hadoop/HBase, ElasticSearch, Linux virtual server, massive data, real-time

TP311

A

10.11959/j.issn.2096-0271.2017010

董長青（1980-），男，北京卡達克數據技術中心軟件業(yè)務本部高級工程師，主要研究方向為大數據、車聯(lián)網。

任女爾（1990-)，女，北京卡達克數據技術中心軟件業(yè)務本部助理工程師，主要研究方向為大數據、云計算。

張慶余（1991-)，男，北京卡達克數據技術中心軟件業(yè)務本部助理工程師，主要研究方向為軟件架構、云計算。

田玉靖（1987-)，女，北京卡達克數據技術中心軟件業(yè)務本部中級工程師，主要研究方向為軟件架構、編程模式。

2016-09-20