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

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

基于HBase+ ElasticSearch的海量交通數(shù)據(jù)實(shí)時(shí)存取方案設(shè)計(jì)

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

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

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

Hadoop/HBase；ElasticSearch；Linux虛擬服務(wù)器；海量數(shù)據(jù)；實(shí)時(shí)

1 引言

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

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

2 技術(shù)介紹

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

2.1 Linux虛擬服務(wù)器技術(shù)

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

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

2.2 HBase存儲(chǔ)技術(shù)

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

2.3 HBase檢索

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

圖1 海量交通流數(shù)據(jù)分布式存取架構(gòu)

3 海量交通數(shù)據(jù)的存取架構(gòu)設(shè)計(jì)

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

3.1 系統(tǒng)架構(gòu)

整體架構(gòu)主要從采集、存儲(chǔ)和檢索3個(gè)方面進(jìn)行設(shè)計(jì)改進(jìn)并實(shí)現(xiàn)。整體架構(gòu)如圖1所示。

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

3.2 關(guān)鍵設(shè)計(jì)

3.2.1 LVS負(fù)載均衡

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

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

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

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

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

圖2 系統(tǒng)LVS負(fù)載均衡架構(gòu)

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

3.2.2 多源存儲(chǔ)設(shè)計(jì)

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

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

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

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

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

● 取消自動(dòng)寫入，根據(jù)實(shí)驗(yàn)設(shè)置寫入緩沖區(qū)大小為20 MB，能提高千萬級(jí)數(shù)據(jù)同時(shí)插入的效率。

● 預(yù)分配region，建表時(shí)直接使用預(yù)分配region，避免單個(gè)region灌入數(shù)據(jù)。

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

圖3 數(shù)據(jù)結(jié)構(gòu)

3.2.3 索引方案改進(jìn)

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

（1）基于HBase表的二級(jí)索引方案設(shè)計(jì)

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

如圖4所示，實(shí)線代表數(shù)據(jù)指向，虛線代表數(shù)據(jù)塊指向，索引表數(shù)據(jù)對數(shù)據(jù)表數(shù)據(jù)的行鍵進(jìn)行進(jìn)一步改造，增加索引名稱和索引數(shù)據(jù)。當(dāng)數(shù)據(jù)進(jìn)行分裂時(shí)，其對應(yīng)的索引同步進(jìn)行分裂，并且使用保持?jǐn)?shù)據(jù)的StartKey起始一致。

（2）ElasticSearch構(gòu)建

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

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

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

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

圖5 數(shù)據(jù)寫入過程

圖6 數(shù)據(jù)讀取過程

4 系統(tǒng)測試

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

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

為了充分驗(yàn)證本架構(gòu)的可行性，分別測試1萬到1 000萬條數(shù)據(jù)的插入速度，并且從單機(jī)服務(wù)、不添加索引和添加索引3方面進(jìn)行對比測試。圖7為測試結(jié)果。

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

4.2 軌跡回放查詢速度測試

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

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

圖7 單機(jī)、添加索引集群、不添加索引集群數(shù)據(jù)

圖8 不同結(jié)果集數(shù)據(jù)查詢效率

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

5 結(jié)束語

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

[1] 王頤帥. 基于LVS 的服務(wù)器負(fù)載均衡技術(shù)[J].計(jì)算機(jī)系統(tǒng)應(yī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的高可用負(fù)載均衡研究與應(yīng)用[J]. 自動(dòng)化技術(shù)與應(yīng)用, 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 的交通流數(shù)據(jù)實(shí)時(shí)存儲(chǔ)系統(tǒng)[J]. 計(jì)算機(jī)應(yīng)用, 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 查詢技術(shù)與系統(tǒng)[J].計(jì)算機(jī)學(xué)報(bào), 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的大日志實(shí)時(shí)搜索的軟件集成方案研究[J]. 吉林師范大學(xué)學(xué)報(bào)（自然科學(xué)版）, 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)測數(shù)據(jù)的NoSQL 存儲(chǔ)方案[J]. 計(jì)算機(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 集群負(fù)載調(diào)度算法研究[J]. 長沙大學(xué)學(xué)報(bào), 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-），男，北京卡達(dá)克數(shù)據(jù)技術(shù)中心軟件業(yè)務(wù)本部高級(jí)工程師，主要研究方向?yàn)榇髷?shù)據(jù)、車聯(lián)網(wǎng)。

任女爾（1990-)，女，北京卡達(dá)克數(shù)據(jù)技術(shù)中心軟件業(yè)務(wù)本部助理工程師，主要研究方向?yàn)榇髷?shù)據(jù)、云計(jì)算。

張慶余（1991-)，男，北京卡達(dá)克數(shù)據(jù)技術(shù)中心軟件業(yè)務(wù)本部助理工程師，主要研究方向?yàn)檐浖軜?gòu)、云計(jì)算。

田玉靖（1987-)，女，北京卡達(dá)克數(shù)據(jù)技術(shù)中心軟件業(yè)務(wù)本部中級(jí)工程師，主要研究方向?yàn)檐浖軜?gòu)、編程模式。

2016-09-20