馮心欣, 胡淑英, 鄒其昊, 徐藝文

(福州大學(xué)物理與信息工程學(xué)院, 福建 福州　350116)

0　引言

車聯(lián)網(wǎng)(internet of vehicles, IoV)是物聯(lián)網(wǎng)(internet of things, IoT)在交通運(yùn)輸領(lǐng)域的典型應(yīng)用, 它是一種基于人、 車、 環(huán)境協(xié)同的開放融合網(wǎng)絡(luò)系統(tǒng), 通過先進(jìn)的信息通信與處理技術(shù)對網(wǎng)內(nèi)各環(huán)節(jié)產(chǎn)生的大規(guī)模復(fù)雜靜態(tài)、 動態(tài)信息進(jìn)行感知、 認(rèn)知和計(jì)算, 解決泛在異構(gòu)移動融合網(wǎng)絡(luò)環(huán)境中智能管理和信息服務(wù)的可計(jì)算性、 可擴(kuò)展性和可持續(xù)性問題, 最終實(shí)現(xiàn)人、 車、 路、 環(huán)境的深度融合[1-3].

在人、 車、 路、 環(huán)境的交互過程中產(chǎn)生了海量數(shù)據(jù), 一些實(shí)際項(xiàng)目的統(tǒng)計(jì)發(fā)現(xiàn), 這一數(shù)據(jù)的規(guī)模將會突破10 TB級[4], 因此, 如何在龐大的數(shù)據(jù)中快速查詢到用戶需要的信息, 以進(jìn)行車聯(lián)網(wǎng)交通信息的綜合分析, 成為車聯(lián)網(wǎng)研究的熱點(diǎn).然而, 這些數(shù)據(jù)的海量特性、 異構(gòu)性和眾多并發(fā)訪問, 給傳統(tǒng)基于單機(jī)數(shù)據(jù)庫的系統(tǒng)帶來了很大的挑戰(zhàn).雖然有研究者提出了一些關(guān)系型數(shù)據(jù)庫集群的解決方案, 例如在MySQL集群[5]和Oracle集群[6]中采用分表分庫的方法來進(jìn)行擴(kuò)容, 但此擴(kuò)容操作比較復(fù)雜, 需要聯(lián)合多個分表數(shù)據(jù), 查詢繁瑣, 并增添了分表維護(hù)問題.近年來, 基于云計(jì)算的分布式存儲系統(tǒng)和新興的非關(guān)系型(NoSQL)數(shù)據(jù)庫技術(shù)為解決上述問題帶來契機(jī).目前, 具備高容錯、 高可靠、 經(jīng)濟(jì)等優(yōu)勢的開源分布式大數(shù)據(jù)處理平臺的Hadoop和有高擴(kuò)展性、 快速存儲等優(yōu)勢的NoSQL數(shù)據(jù)庫代表HBase, 廣受各界青睞.已有實(shí)際案例利用Hadoop和HBase構(gòu)建存儲倉庫以存儲來自地質(zhì)氣象研究[7-8]、 環(huán)境檢測[9]、 太陽能光伏效應(yīng)研究[10]、 醫(yī)療衛(wèi)生大數(shù)據(jù)分析[11]和智慧交通[12-13]等各領(lǐng)域產(chǎn)生的大數(shù)據(jù).

基于以上背景, 為解決海量交通數(shù)據(jù)中快速查詢用戶所需信息的問題, 本研究提出一種基于HBase的車聯(lián)網(wǎng)海量數(shù)據(jù)存儲查詢方案.考慮車聯(lián)網(wǎng)數(shù)據(jù)的時空相關(guān)性, 在HBase表設(shè)計(jì)中通過合理的列族設(shè)置和行鍵設(shè)計(jì), 使海量數(shù)據(jù)分布有序, 提高查詢算法的效率, 滿足車聯(lián)網(wǎng)信息實(shí)時查詢的需求.最后通過實(shí)際數(shù)據(jù)的實(shí)驗(yàn)測試, 驗(yàn)證方案的可行性與合理性.

1　數(shù)據(jù)預(yù)處理

研究采用的實(shí)測車聯(lián)網(wǎng)數(shù)據(jù)是福州市出租車軌跡數(shù)據(jù), 原始數(shù)據(jù)包對每輛車采集包含設(shè)備標(biāo)識(mdtid)、 車輛地理位置經(jīng)度(longitude)、 緯度(latitude)、 車輛定位時間(msgdatetime)等11項(xiàng)數(shù)據(jù).對原始數(shù)據(jù)進(jìn)行初步分析發(fā)現(xiàn), 數(shù)據(jù)包內(nèi)數(shù)據(jù)龐雜, 質(zhì)量參差不齊.為了提高數(shù)據(jù)的合理利用率以及保證后期數(shù)據(jù)查詢分析的正確性, 在把數(shù)據(jù)導(dǎo)入HBase之前, 先進(jìn)行數(shù)據(jù)預(yù)處理工作, 主要包含以下4個方面內(nèi)容.

1) 剔除重復(fù)數(shù)據(jù).由于設(shè)備重復(fù)發(fā)送數(shù)據(jù), 導(dǎo)致在原始數(shù)據(jù)中出現(xiàn)連續(xù)多條相同記錄, 為保證數(shù)據(jù)的唯一性, 剔除整行重復(fù)數(shù)據(jù).

2) 剔除異常狀態(tài)數(shù)據(jù).原始數(shù)據(jù)中的異常數(shù)據(jù)主要指經(jīng)緯度數(shù)值位數(shù)不滿足要求、 車速不合理以及方向信息數(shù)值錯誤的數(shù)據(jù), 這類數(shù)據(jù)干擾后期的數(shù)據(jù)分析.在研究的先期工作中, 已討論了基于Epanechnikov核的修正邊界核建立, 及相應(yīng)的數(shù)據(jù)集概率密度函數(shù)建立[14].本研究采用其中的核密度估計(jì)方法, 對經(jīng)緯度、 車速和方向信息數(shù)據(jù)中出現(xiàn)概率較小的數(shù)據(jù)(即信任度不足的數(shù)據(jù))予以剔除.

3) 剔除缺失數(shù)據(jù).缺失數(shù)據(jù)是指在某些字段中存在空缺值的數(shù)據(jù), 這樣的數(shù)據(jù)在后期數(shù)據(jù)分析時會因缺項(xiàng)而不起作用.缺失數(shù)據(jù)的數(shù)量較少, 預(yù)處理中也予以整行數(shù)據(jù)刪除.

4) 地理位置的路段匹配.雖然原始數(shù)據(jù)中已收集有車輛經(jīng)緯度的定位信息, 但由于數(shù)據(jù)來源和地圖更新等問題, 將這一信息投射在地圖上時, 發(fā)現(xiàn)并不是所有數(shù)據(jù)點(diǎn)都能落在城市道路上, 這對后期道路車流量分析、 車輛路徑軌跡分析都存在影響.因此預(yù)處理工作對原始數(shù)據(jù)增加一步地圖匹配工作, 將車輛的經(jīng)緯度定位信息與地圖上的道路位置進(jìn)行匹配, 修正原始經(jīng)緯度數(shù)據(jù), 使得校正后的車輛經(jīng)緯度位置可以較為精確地落在地圖道路上, 并得到一列新的數(shù)據(jù)“road”, 該字段表示該定位信息具體落在哪一段道路位置上, 信息格式為“0000-00”, 前4位為道路路段編號, 后兩位為該路段的路徑編號.然而實(shí)際工作發(fā)現(xiàn), 并非所有的定位信息都能得到準(zhǔn)確的道路匹配, 這是由于有些現(xiàn)實(shí)中新建設(shè)的道路沒有及時在地圖上更新.但這些數(shù)據(jù)不屬于上述提及的3種需要剔除的數(shù)據(jù)類型, 因此對這些少量的暫時無法得到精確道路匹配的數(shù)據(jù)采取在“road”字段保留“xxxx-xx”的形式.這樣, 既能保證最后的數(shù)據(jù)行不含缺項(xiàng), 也能在地圖更新后修改對應(yīng)的道路信息.

2　HBase表設(shè)計(jì)與查詢模式設(shè)計(jì)

HBase的物理模型是以列族為單位存儲數(shù)據(jù), 磁盤上同一個列族下所有的單元格都存儲在一個存儲文件(StoreFile)中.因此, 相關(guān)的數(shù)據(jù)項(xiàng)應(yīng)放置在同一個列族, 保證數(shù)據(jù)物理存儲的靠近以提高查詢效率[15-16].另一方面, 行鍵作為 HBase 表索引的主鍵, 決定了表數(shù)據(jù)處理的性能.因此, 為了使海量車聯(lián)網(wǎng)數(shù)據(jù)在云服務(wù)器集群能夠合理存儲并便于后期用戶訪問, 需要針對數(shù)據(jù)特點(diǎn)并結(jié)合實(shí)際應(yīng)用對數(shù)據(jù)存儲表做表結(jié)構(gòu)設(shè)計(jì), 設(shè)計(jì)主要包含列族設(shè)置與行鍵設(shè)計(jì).

2.1　列族設(shè)置

將經(jīng)過預(yù)處理后的數(shù)據(jù)視作合理、 可用的車聯(lián)網(wǎng)數(shù)據(jù), 對現(xiàn)有的12項(xiàng)信息進(jìn)行分析發(fā)現(xiàn)： 車輛定位的經(jīng)緯度信息、 道路位置信息、 車輛定位時間、 車速、 方向等信息都是車聯(lián)網(wǎng)綜合分析服務(wù)中常用到的查詢項(xiàng)目, 對分析交通運(yùn)行情況、 司機(jī)駕駛習(xí)慣等實(shí)際應(yīng)用場景都十分必要.考慮查詢的高效率, 在設(shè)計(jì)表時將上述提及的幾項(xiàng)常用信息放置在同一列族中； 而數(shù)據(jù)項(xiàng)中的“islocate-是否定位”、 “sourceflag-信息源”、 “indate-數(shù)據(jù)入庫日期”這3項(xiàng)信息較為不常用, 歸為同一列族.最終的列族設(shè)計(jì)如表1所示.

表1　車聯(lián)網(wǎng)數(shù)據(jù)的列族設(shè)置

2.2　行鍵設(shè)計(jì)

由于數(shù)據(jù)在HBase中以鍵值(key value)形式存儲, 行鍵(row key)是主鍵, 行鍵的設(shè)計(jì)對數(shù)據(jù)的存儲查詢性能起關(guān)鍵作用, 因此在設(shè)計(jì)時需充分考慮車聯(lián)網(wǎng)信息查詢的應(yīng)用場景, 做綜合分析.在車聯(lián)網(wǎng)信息查詢應(yīng)用中, 車牌號、 車輛定位信息、 定位時間是最關(guān)鍵的信息項(xiàng).如, 對某一路段車流量的查詢, 希望根據(jù)車輛定位時間(msgdatetime)查詢到某路段上的所有車輛設(shè)備標(biāo)識(mdtid)并統(tǒng)計(jì)其數(shù)量； 對某車運(yùn)動軌跡的查詢, 希望根據(jù)車輛設(shè)備標(biāo)識(mdtid)和定位時間(msgdatetime)查詢到車輛定位的經(jīng)緯度(longitude & latitude).

因此將實(shí)測數(shù)據(jù)中采集的對應(yīng)信息項(xiàng) “mdtid-設(shè)備標(biāo)識”、 “msgdatetime-車輛定位時間”和“road-道路信息”放入行鍵的位置并進(jìn)行組合, 分析對比各復(fù)合行鍵設(shè)計(jì)方案后, 采用如表2所示的最終方案.

表2　行鍵最終方案

此行鍵設(shè)計(jì)方案的優(yōu)點(diǎn)是：

1) 用此3個字段信息組合的復(fù)合行鍵保證了行鍵的唯一性和長度一致.

2) 規(guī)避數(shù)據(jù)以時間順序存放時, 因時間數(shù)據(jù)呈現(xiàn)單調(diào)遞增趨勢而引起集群內(nèi)單一region過載, 而其他機(jī)器閑置的風(fēng)險.

3) 根據(jù)HBase存儲特性, 以車輛設(shè)備標(biāo)識為順序排列的存儲方案使同一輛車的數(shù)據(jù)能在物理存儲上同樣靠近, 在以車輛為檢索條件的查詢應(yīng)用上體現(xiàn)出高效性.

2.3　查詢模式設(shè)計(jì)

圖1　車輛軌跡查詢程序流程　Fig.1　Flowchart of vehicle trajectory query program

在上述行鍵設(shè)計(jì)的基礎(chǔ)上設(shè)計(jì)兩類車聯(lián)網(wǎng)信息查詢的模式.

模式一： 車輛駕駛情況查詢.該模式包含車輛在某個時間點(diǎn)的定位情況查詢和車輛在某個時間段內(nèi)行駛軌跡查詢.根據(jù)用戶輸入車輛設(shè)備標(biāo)識和查詢時間, 可定位車輛坐標(biāo)位置并顯示車速、 方向等相關(guān)信息以分析特定車輛的行駛狀況.

模式二： 路段車流量查詢.該模式根據(jù)用戶輸入的路段信息和時間范圍, 顯示該時間段內(nèi)經(jīng)過該路段的所有車輛的設(shè)備標(biāo)示并統(tǒng)計(jì)車輛總數(shù).

下面分析各查詢模式的程序?qū)崿F(xiàn)流程.

1) 模式一: 車輛軌跡查詢程序的流程, 如圖1所示, 具體步驟說明如下.

① 設(shè)置自定義過濾器集合(Filterlist), 集合包含一個前綴過濾器用來確定車輛, 兩個行過濾器(RowFilter)確定檢索的起始時間和結(jié)束時間, 3個過濾器全通可以鎖定Scan()的起始行和結(jié)束行, 過濾器參數(shù)為用戶輸入的車輛設(shè)備標(biāo)識(mdtid), 查詢起始時間(start_time)、 查詢結(jié)束時間(end_time).

② 創(chuàng)建Scan實(shí)例, 用s.addColumn()方法限制返回?cái)?shù)據(jù)列只有車輛定位經(jīng)度(longitude)、 緯度(latitude)、 對應(yīng)的路段-路徑編號(road)、 數(shù)據(jù)發(fā)送時間(msgdatetime).

③ 將返回至掃描器(scanner)的信息逐行輸出至名為“設(shè)備標(biāo)識-時間時間-結(jié)束時間.txt”的文本中, 通過文本將車輛軌跡數(shù)據(jù)導(dǎo)入地圖模塊, 最終可在ArcGIS軟件中已經(jīng)事先導(dǎo)入的城市地圖上顯示該車輛該時段的軌跡圖.

圖2　路段車流量查詢程序流程Fig.2　Flowchart of roadtraffic flow querying program

2)模式二: 路段車流量查詢的程序流程如圖2所示, 具體步驟說明如下.

① 設(shè)置自定義過濾器集合(Filterlist), 集合包含一個行過濾器用來確定路段, 兩個列值過濾器(SingleColumnValueFilter)確定檢索的起始時間和結(jié)束時間, 一個列限定符過濾器, 限定返回列項(xiàng)僅為“設(shè)備標(biāo)識-mdtid”, 4個過濾器全通使Scan()操作結(jié)果滿足查詢要求.

② 創(chuàng)建Set集合, 通過addAll()循環(huán)將Scan()結(jié)果添加進(jìn)集合, 此方法可以去掉重復(fù)值, 保證車輛數(shù)量統(tǒng)計(jì)的正確性.

③ 最后通過iterator()對象獲取Iterator()實(shí)例, 再通過遍歷迭代器來獲取集合對象, 即該時段經(jīng)過該路段的車輛設(shè)備標(biāo)識, 并統(tǒng)計(jì)車輛總數(shù).

3　實(shí)驗(yàn)與結(jié)果分析

為了驗(yàn)證上述HBase表設(shè)計(jì)與查詢模式的性能, 通過實(shí)驗(yàn)對其進(jìn)行評測.實(shí)驗(yàn)平臺采用3臺機(jī)器搭建HBase集群, 操作系統(tǒng)均為Ubuntu 14.04 LTS, 每臺機(jī)器的主機(jī)名、 IP地址、 角色分配如表3所示.

表3　集群配置

3.1　查詢模式的性能驗(yàn)證

在所搭建的平臺上對上述查詢模式進(jìn)行測試, 實(shí)驗(yàn)數(shù)據(jù)使用福州市出租車2015年12月2日的GPS數(shù)據(jù), 數(shù)據(jù)量10 506 479 條.

模式一： 車輛駕駛情況查詢.

1) 查詢車輛11823在2015年12月2日12:20:00的定位記錄, 結(jié)果如圖3(a)所示.查詢結(jié)果顯示該車在該時間點(diǎn), 所在的經(jīng)緯度位置為119.327 298 583°E, 26.068 719 103 4°N, 所在路段編號為0554-08, 車輛行駛方向?yàn)?(正西), 車速16 km·h-1.此查詢功能可以有效地對特定車輛的行駛情況進(jìn)行分析, 如檢測車輛是否超速、 追蹤車輛的位置等.

2) 查詢車輛13702在2015年12月2日12:00—12:30的車輛軌跡信息, 得到結(jié)果如圖3(b)所示, 圖中分別用藍(lán)點(diǎn)和紅點(diǎn)標(biāo)出該車輛在此時段行駛軌跡的起點(diǎn)和終點(diǎn), 車輛的行駛方向則用箭頭標(biāo)識.

模式二： 路段車流量查詢.

查詢2015年12月2日17:00—17:10經(jīng)過道路0616-01的車流量, 部分結(jié)果如圖4所示.圖4(a)顯示了查詢的部分結(jié)果, 分別為該時間段經(jīng)過該路段的各車輛設(shè)備標(biāo)識和車輛總數(shù)； 圖4(b)顯示了該路段的地圖； 圖4(c)則是從查詢結(jié)果中任意選取的兩輛車在該時間段的軌跡圖, 從軌跡圖中可以看出這兩輛車在2015年12月2日17:00—17:10時段內(nèi)確實(shí)經(jīng)過路段0616-01, 從而驗(yàn)證了查詢結(jié)果的正確性.

圖3　車輛駕駛情況查詢結(jié)果Fig.3　Querying the driving conditions of a certain vehicle

圖4　路段車流量查詢結(jié)果Fig.4　Result of traffic flow querying for a road

3.2　行鍵設(shè)計(jì)方案的性能驗(yàn)證

圖5　查詢耗時對比　　　　　　　　Fig.5　Time consumption comparison

為了驗(yàn)證HBase行鍵設(shè)計(jì)方案確實(shí)能有效提高數(shù)據(jù)查詢性能, 設(shè)計(jì)實(shí)驗(yàn)通過查詢相同的數(shù)據(jù)以對比有無行鍵設(shè)計(jì)對實(shí)際查詢耗時的影響.具體方法為：

1) 設(shè)置每組實(shí)驗(yàn)的數(shù)據(jù)總量從100萬條逐次遞增至1 000萬條, 每次增加100萬條數(shù)據(jù), 總共做10組對比實(shí)驗(yàn)；

2) 每組實(shí)驗(yàn)隨機(jī)選取20輛車, 查詢指定1 h的軌跡數(shù)據(jù)；

3) 每組實(shí)驗(yàn)重復(fù)3次, 取最終的查詢時間平均值.

按以上策略分別測試行鍵設(shè)計(jì)方案和無行鍵設(shè)計(jì), 僅以列值做檢索這兩種方法的數(shù)據(jù)查詢用時, 通過對比兩者的差異來比較兩種方法的查詢性能優(yōu)劣.實(shí)驗(yàn)結(jié)果如圖5所示, 圖中橫軸為數(shù)據(jù)總量, 縱軸為平均查詢時間.

由圖5可知, 隨著數(shù)據(jù)總量的增大, 兩種方案的平均查詢時間都逐漸增長, 但是當(dāng)數(shù)據(jù)總量達(dá)到400萬條時, 以行鍵為查詢索引的方案平均查詢時間的增速開始放緩, 而沒有行鍵設(shè)計(jì)的查詢方案直至數(shù)據(jù)總量達(dá)到900萬條時, 平均查詢時間的增速才開始下降.雖然曲線的轉(zhuǎn)折點(diǎn)不同, 但兩種查詢方案都呈現(xiàn)出在數(shù)據(jù)總量增至一定程度時, 查詢時間的增速將下降的趨勢, 這顯示了HBase對于海量數(shù)據(jù)查詢的適用性.同時, 圖5顯示出在不同的數(shù)據(jù)總量中查詢時, 有行鍵設(shè)計(jì)的方案平均查詢時間都明顯小于沒有行鍵設(shè)計(jì)的查詢方案.實(shí)驗(yàn)說明, HBase表設(shè)計(jì)中, 是否針對查詢應(yīng)用做合理的行鍵設(shè)計(jì), 對數(shù)據(jù)查詢耗時影響較大.本研究采用的方案在數(shù)據(jù)特性分析的基礎(chǔ)上針對數(shù)據(jù)查詢應(yīng)用功能做了對應(yīng)的行鍵設(shè)計(jì), 使查詢指定車輛某段時間軌跡數(shù)據(jù)的耗時降低, 從而顯著地提升了查詢性能, 對比實(shí)驗(yàn)驗(yàn)證了行鍵設(shè)計(jì)方案的高效性.

4　結(jié)語

車聯(lián)網(wǎng)對實(shí)現(xiàn)智能交通系統(tǒng)(intelligent transportation system, ITS)具有重要意義.研究針對車聯(lián)網(wǎng)采集到的海量數(shù)據(jù), 提出一種基于HBase的存儲查詢方案.HBase是建立在Hadoop上的列式開源數(shù)據(jù)庫, 相比于傳統(tǒng)關(guān)系型數(shù)據(jù)庫在存儲海量數(shù)據(jù)時有突出優(yōu)勢.研究提出一種合理的表結(jié)構(gòu)設(shè)計(jì), 實(shí)現(xiàn)在HBase中存儲龐大的車聯(lián)網(wǎng)數(shù)據(jù), 并在數(shù)據(jù)導(dǎo)入HBase之前, 對數(shù)據(jù)進(jìn)行了預(yù)處理工作, 特別是通過地圖匹配校正了原始數(shù)據(jù)中錯誤的車輛經(jīng)緯度定位信息, 并增加了精確的道路信息以豐富交通情況的查詢分析功能.通過實(shí)驗(yàn)測試了幾種查詢模式的合理性, 并通過對比實(shí)驗(yàn)顯示了行鍵設(shè)計(jì)方案在查詢耗時上的優(yōu)越性.