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

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

0　引言

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

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

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

1　數(shù)據預處理

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

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

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

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

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

2　HBase表設計與查詢模式設計

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

2.1　列族設置

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

表1　車聯(lián)網數(shù)據的列族設置

2.2　行鍵設計

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

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

表2　行鍵最終方案

此行鍵設計方案的優(yōu)點是：

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

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

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

2.3　查詢模式設計

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

在上述行鍵設計的基礎上設計兩類車聯(lián)網信息查詢的模式.

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

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

下面分析各查詢模式的程序實現(xiàn)流程.

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

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

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

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

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

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

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

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

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

3　實驗與結果分析

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

表3　集群配置

3.1　查詢模式的性能驗證

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

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

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

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

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

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

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

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

3.2　行鍵設計方案的性能驗證

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

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

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

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

3) 每組實驗重復3次, 取最終的查詢時間平均值.

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

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

4　結語

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