基于Hive的海量公交客流起訖點挖掘方法

許智宏， 王怡崢， 王利琴*， 董永峰

(1. 河北工業大學人工智能與數據科學學院,天津 300401；2. 河北省大數據計算重點實驗室,天津 300401)

城市公交系統的發展和優化,需要全面而又準確的客流分析。在實際的客流分析工作中經常使用公交客流起訖點(origin-destination，OD)。OD是對乘坐公交車的乘客一次出行的描述,其中O代表起點,即乘客的上車站點；D代表終點,即乘客的下車站點。按照客流OD統計一個時間段內各站點上、下車人數并繪制成矩陣,即可得出OD矩陣(origin-destination matrix)。OD矩陣可視化后,可直觀地看出站點的客流量大小,以分析公交運營的現狀。OD可作為靜態交通規劃的基礎數據[1],對于智慧交通的建設[2]具有重要的現實意義。然而,在實際的交通規劃任務中,以合理的時間和資源開銷,挖掘、獲取大量的OD數據,是一項具有挑戰性的任務。

1 相關研究

不同于早期OD獲取所采用的人工跟車調查方法,現今OD的挖掘主要依靠車聯網設備在公交運營過程中產生的數據,包括IC刷卡記錄、全球定位系統(global positioning system，GPS)定位記錄、調度記錄等。OD挖掘需要解決兩個問題:上車站點的匹配和下車站點的預測。由于刷卡機、調度機、位置記錄儀這些不同的設備分別有各自的數據模型,上車站點匹配實質上是對同一個公交的不同設備所產生的數據做關聯操作。常見的方法是:若有調度表,則刷卡信息表匹配調度表直接得到站點記錄；若無調度表則按照GPS定位記錄推算出每次刷卡得到的站點；兩者均無的情況較少,一般使用API或其他手段補全站點信息。Cui[3]以調度表每條時間記錄為中心,以5 min的閾值匹配刷卡記錄。Wang[4]提出線路-天-出行-點位的層級匹配方法,匹配調度表中同分鐘的記錄,若匹配失敗,則增加30 s再進行匹配,若刷卡時間落在前一站出站時間與后一站進站時間之間,找時間差最近的記錄。鄔群勇等[5]以刷卡時間為中心,向前3 min向后7 min作為閾值匹配多條調度記錄,之后逐一相減取最小的時間差。豐海寬[6]利用IC卡數據介于當前站點和下一站進站時間的不等關系,直接匹配當前站點作為上車站點。李佳怡等[7]先將時間排序,對多個GPS記錄中的時間相減,取最短時間距離,利用DBSCAN聚類方法由經緯度識別站點。鄧一凌等[8]將每條刷卡數據匹配兩條時間較近的GPS記錄并計算坐標和置信度,匹配完成后應用DPSCAN空間聚類反推站點位置。

下車站點的匹配有兩種常見的方法:基于優化算法的下車站點推算、單獨使用出行鏈算法(trip-chaining method)或結合基于概率的推算方法預測下車站點。極大熵模型[9]、雙層模型[10]等基于優化算法的OD推算方法,優勢在于精確反推OD矩陣或OD數值,但很難在大量數據中按照每條刷卡記錄精確至每個乘客的下車站點位置。出行鏈算法可追溯至早期國外學者對地鐵客流OD的挖掘[11],也有很多在公交客流OD挖掘流程的應用和改進。Wang[4]應用地理信息系統中的空間連接功能,得到最近站點集并預測下車站點,實現出行鏈算法。Gordon等[12]在預測下車站點后預測下車時間,并通過測試來確保下車站點預測的正確性。Alsger等[13]基于出行鏈算法進行了大量實驗,探索換乘時間閾值和步行距離閾值,根據匹配率與準確度得出合適的閾值,提出“當日對稱”思想的不完善之處并改進。基于站點下車概率的推算與出行鏈算法相結合[14-16],可彌補出行鏈算法預測不完整的問題,提升下車站點預測率。豐海寬[6]考慮多種情況的出現,例如當日最后一次上車與當日最早上車線路的關系、本次上車與下次上車站點的距離關系等,分別制定多個規則挖掘OD和換乘信息。李佳怡等[7]基于出行鏈定義出行節,區分4種出行節鏈接方式,并結合站點下車吸引權來挖掘OD,提出站點位置評分方法來衡量精確程度。鄧一凌等[8]利用個體出行鏈推斷下車站點,應用個人出行規律和分線路的概率矩陣提升預測率。基于大數據框架應用出行鏈算法將帶來效率的提升,鄔群勇等[5]將上車站點數據分塊,提出連續型和非連續型出行鏈算法,并將算法前置到Map階段來挖掘OD。孫慈嘉等[15]應用MapReduce分線路統計站點熱度形成下車熱度矩陣后求解乘客轉移人數。OD挖掘所用的原始數據不一定是完整的,宋竹等[17]不關聯調度表或GPS信息,提出自適應的調整算法標注站點序號,利用貪心生長算法對全局公交車行駛方向進行標注,補全站點信息。此外還有OD矩陣可視化的最佳實踐[18]和對公交-地鐵多元數據的OD挖掘的具體應用[3,19]。

以上研究中,上車站點使用一個固定的時間閾值進行匹配,無法應對多種公交車停車時間的變化；有些方法利用時間不等關系來進行匹配,這樣會降低效率；有些還需要預先排序,也會降低效率。部分下車站點預測方法沒有并行的思想,只能處理一條或幾條線路；部分方法沒有結合大數據處理框架實現資源高效利用,且會受到換乘時間閾值的干擾。已有基于大數據框架的方法存在下車站點預測率較低的問題。在數據量較大的情況下,傳統數據庫也存在性能較弱的問題[20-23]。

上車站點匹配方法中,時間閾值可以根據集群能力任意擴大,提升魯棒性；將時間不等關系轉化為相等關系進行關聯,無需預先排序,提升效率；結合站點上客數的概率思想,達到較高的匹配率。下車站點預測方法中,無需設定換乘時間閾值,排除人為確定因素的干擾,不考慮過多邊界和換乘次數。可并行處理多條線路,以出行鏈算法結合基于概率的預測方法達到較高的預測率。方法全部以Hive的查詢方式進行,無需另行將數據讀出再進行操作,方便實際的生產環境部署。依靠Hive相對于傳統數據庫查詢性能上的優勢,再利用調優技術,在較短的離線耗時下,實現海量數據中基于表連接操作和概率思想的OD挖掘方法。

2 數據源

數據來自石家莊市運營的公交車配套的車聯網設備,包含如圖1所示的3張表。IC刷卡記錄表、調度表時間跨度為2018年1月1日—2018年3月27日,共包含164條公交線路的調度數據；基礎信息表覆蓋了石家莊市所有公交站點。各表均包含多個字段,而在OD挖掘的過程中僅使用圖1所示的少量關鍵字段。

圖1 數據源及關聯關系Fig.1 Data sources and their relationship

由于車聯網設備在同一時刻僅能允許一名乘客刷卡,應用IC刷卡記錄表時,經常以卡號和刷卡時間來唯一定位一條刷卡記錄。該表并不記錄刷卡的站點信息,而是記錄線路號和車輛號。因此針對一條刷卡記錄,需要根據刷卡時間、線路號、車輛號進行上車站點的匹配。成功完成上車站點匹配的IC卡記錄的刷卡時間被看作上車時間。

調度表中的字段相互組合后,有不同的業務含義:線路號、子線路號確定一條線路；線路號、子線路號、上下行確定公交運行方向；線路號、子線路號、上下行、站點序號確定具體公交站點；進出站類型辨別公交進站還是出站。

基礎信息表中,站點經度與站點緯度基于WGS84坐標系,其他字段業務含義與調度表相同。

3 上車站點匹配

上車站點匹配主要為兩部分:基于時間閾值的上車站點匹配,基于站點上客數的上車站點匹配。前者關聯IC刷卡記錄表和調度表進行匹配,失配的記錄將由后者再次進行匹配。

3.1 基于時間閾值的上車站點匹配

得到IC刷卡記錄表和調度表后,常規的上車站點匹配方式是使用一個時間段直接進行兩表關聯。這樣的連接有很大不確定性，可能會出現一條IC刷卡記錄連接多條調度記錄,或者因為超出時間段一點而失配。為解決以上問題,提出基于時間閾值的連接方法。

設IC刷卡記錄表為表A,調度表為表B,表A刷卡時間字段為Ta,表B進出站時間字段為Tb,Txy為刷卡時間和進出站時間差的絕對值,如式(1)所示。

Txy=|Ax·Ta-By·Tb|≤F

(1)

式(1)中：Ax表示表A的第x條記錄；By表示表B的第y條記錄；點運算Ax·Ta表示取表A第x條記錄對應字段Ta的值；F為時間閾值。

以表A中第x條記錄為中心,對表B中所有滿足式(1)的記錄,計算Txy后執行連接。獲得記錄集合:

S={(Ax,By,Txy)|Txy≤F}

(2)

取Txy最小值對應的調度記錄b,如式(3)所示,b中的站點信息即為記錄Ax對應的上車站點信息,b的進出站時間,與Ax的刷卡時間最接近。

(3)

本方法中S的求解與MapReduce中的Map類似,是對表數據的抽取與連接；對S的處理與Reduce類似,是對連接后的數據進行排序和篩選。

時間閾值F的提出,實質是控制連接條件的寬松或嚴格,避免查詢中出現笛卡爾積,減小集群負擔。F根據實際的公交停車時間統計得到。首先統計所有站點歷史上下客時間數據的75%四分位數作為站點參考停車時間,在全部站點中,1路公交上行至省民航站的參考停車時間為中位數34 s。320路公交下行至實驗小學站的參考停車時間為平均值40.75 s。參考停車時間介于2～280.6 s的站點占總站點數的99.7%。取F=280.6 s。每條刷卡記錄在此非常寬松的閾值F內,選擇最合理的、時間最近的調度記錄。

上述F取法僅為一建議,由式(1)～式(3)可得,F可以根據集群的運算能力自由擴大,F的擴大會增加集群負擔,提升匹配魯棒性,但不改變最終匹配結果。若F取無窮大,查詢對于時間字段做笛卡爾積。

基于時間閾值的上車站點匹配可以總結為以下流程:首先根據IC刷卡記錄中的刷卡時間和調度表中的出站時間應用基于時間閾值的連接,匹配出上車站點。剩下的失配記錄在調度表中以進站時間再次進行匹配。仍無法匹配到上車站點的IC刷卡記錄,即認為調度表缺少數據,合并該記錄進入失配記錄集，如圖2所示。

圖2 基于時間閾值的上車站點匹配流程Fig.2 The flow of the boarding station matching method based on the time threshold

3.2 基于站點上客數的上車站點匹配

若某時刻,IC刷卡記錄存在,而調度信息未被設備記錄,則上述方法失效。一般情況下,公交車的IC刷卡機比公交調度記錄設備要更加穩定,這種情況大部分由調度記錄設備在短時間內的故障導致。因此,應用基于站點上客數的上車站點匹配方法求得上車站點。

基于站點上客數的上車站點匹配的詳細步驟如下。

輸入3.2節上車站點匹配結果、失配記錄集,IC刷卡記錄表,基礎信息表。

步驟1 根據已有的上車站點匹配記錄,求得所有站點的歷史上客數。

步驟2 求每條失配的IC刷卡記錄候選站點集M。

步驟3 根據站點歷史上客數,求出每條記錄的M中每一站點上車概率Px。

步驟4 自每條記錄的M中依據每一Px選出一個上車站點,與對應的IC刷卡記錄匹配。

在每條失配的IC刷卡記錄中取出線路號和車輛號,在調度表中查詢對應車輛號的車輛在對應線路號的線路中同方向駛過的所有站點作為候選上車站點加入候選站點集M。乘客在M中每一站點的上車概率為

(4)

式(4)中：bx為M中第x個站點的歷史上客數；m為M中的元素個數。

每條記錄對應的M中每一站點被選中的概率已知,按此概率選擇M中一個站點進行連接,成功匹配上車站點。

4 下車站點預測

得出上車站點匹配表之后,需要根據已知的上車站點信息預測下車站點,總體流程如圖3所示。首先構造出行規律表和距離關系表,再以兩表為輸入,基于表連接執行出行鏈算法,進行下車站點預測。出行鏈算法預測失敗的記錄將由后續的基于下車概率的預測流程再次進行預測。

圖3 下車站點預測Fig.3 Alighting station prediction

4.1 出行鏈算法

出行鏈算法實質上是已被驗證[3]的兩個假設。

出行(trip)指自乘客上車刷卡起至下車的過程。首先,公交車乘客上車刷卡一次,下車不刷卡,則訖點無從得知。則有假設:乘客此次出行的訖點與下次出行的起點很接近,即站點最近(the closet stop)。由此,可通過下一次上車刷卡的信息獲知下次出行的起點,根據距離預測出此次出行的訖點。其次,若記錄為當日最后一次出行,并無對應的“下一次出行”,則有假設:乘客當日最后一次出行完畢,將回到當日首次出行較近的位置,即當日對稱(daily symmetry)。由此,可將當日首次出行當作乘客當日最后一次出行的“下一次出行”,根據站點最近假設,預測出下車站點。

4.2 基于表連接的出行鏈算法

大多數出行鏈算法的實現是以命令式編程(imperative programming)即利用順序、分支、循環等語句組合,循環處理每一條出行記錄,考慮很多邊界條件進行下車站點預測,執行效率較低。為提高算法執行速度,基于Hive在海量數據上的查詢性能優勢,提出一種新的出行鏈算法實現方式:批量處理上車站點記錄,計算得到出行規律表和距離關系表,然后應用以上兩表對所有的上車站點記錄批量進行下車站點的預測。算法無需考慮過多的邊界條件。

4.2.1 構造出行規律

根據出行鏈算法的已知條件——已知此次上車站點和下次上車站點,將乘客單日的上車記錄按時間先后進行兩兩連接。根據出行鏈算法的“當日對稱”假設,將乘客當日最后一次上車記錄連接當日首次上車記錄,連接后的結果即為此乘客的出行規律，如圖4所示。

圖4 構造出行規律Fig.4 Construct the trip regulation

乘客201813***3216在2018年3月3日共乘坐5次公交車,首先在56路上行方向的聯邦空中花園站刷卡上車,在未知地點下車后,在73路上行方向的世紀花園東站再次刷卡上車。將這兩條記錄按時間先后兩兩相連作為(上車站點,下次上車站點)二元組,其他的記錄以此類推。當天最后在56路下行翟營塔南路口站上車的記錄,與當天第一條上車記錄連接。將原刷卡記錄的線路、上下行、站點,替換為上車站點、下次上車站點。

4.2.2 計算距離關系表

運用出行鏈算法的“站點最近”假設,需要得到乘客的下次上車站點、候選下車站點以及兩者之間的距離。將出行規律表中所有乘客的(此次上車站點,下次上車站點)二元組提取出,則乘客此次上車站點同線路的下游站點,為乘客的候選下車站點。將上述二元組加工成(候選下車站點,下次上車站點)二元組,并求出距離(候選下車站點,下次上車站點,兩者距離)三元組。距離關系表的實質即為上述距離三元組。站點間距離公式使用相比Haversine公式更簡單的球面余弦公式[24],如式(5)所示。

(5)

式(5)中：n為緯度；e為經度；x為某一候選下車站點；y為下次上車站點。

4.2.3 下車站點預測

以上兩表為出行鏈算法的執行做準備,而此步是出行鏈算法以表連接方式的實際執行。首先根據構造好的兩表進行初步預測,再探測出代刷卡記錄進行預測結果的復制,最后將兩步的結果進行合并即完成了下車站點預測。前者使用到了距離關系表中的距離,后者復用了基于時間閾值的連接方法。

將批量讀入的出行規律記錄,按刷卡是否在同一線路進行分組:兩次刷卡在同一線路的,下次上車站點即上次下車站點；不同線路的,根據“站點最近”假設,查詢距離關系表得到結果。具體地:以上次上車刷卡記錄的公交線路的對應公交行駛方向為已知條件,在距離關系表中查找多個在上次上車站點之后的站點,作為候選下車站點。其中,與下次上車站點最近的候選下車站點即為上次出行對應的下車站點。此預測結果作為初步預測結果表。

考慮某人早上在公司附近站點下車工作,晚上下班之后在同一站點上車的場景,這中間的時間間隔差可能超過8 h,因此,若設立1 h的換乘時間閾值來限制換乘,超過1 h的前后出行記錄不被連接,則OD記錄將無法被挖掘到。為避免此影響,不設立換乘閾值。

IC刷卡記錄中,有很多代刷卡記錄,在出行規律表中表現為下次上車站點與上次下車站點相等,且經過上述流程無法被預測出下車站點。代刷卡乘客的下車站點看作與原持卡乘客相同的下車站點。得到初步預測結果后,在出行規律表中單獨篩選出代刷卡記錄形成表,并以此表和初步預測結果表分別作為A、B表,按照3.1節基于時間閾值的連接方法,以每條代刷卡記錄為中心,識別時間最近的非代刷卡記錄預測結果,即原持卡乘客的下車站點預測結果,并復制,即完成了代刷卡記錄的下車站點預測。

4.3 基于概率的下車站點預測

若乘客的出行鏈斷裂,即下次上車站點未知,則無法順利預測下車站點。此時需要進行兩步基于概率的下車站點預測,即圖3中基于個體下車概率的下車站點預測和基于站點上客數的下車站點預測。

乘客乘車后,其候選下車站點為同線路乘車站點的所有下游站點,求出這些站點作為候選下車站點集T。T中每一站點是乘客下車站點的概率為

(6)

式(6)中：ux為該乘客前后30 d內,在T中第x個站點上車的次數；t為T中的站點個數。

若:

?x∈T,Px=0

(7)

則:

(8)

式(8)中：hx為T中第x個站點的歷史上客數。

按照式(6)在T中選擇一個下車站點,即基于個體下車概率的下車站點預測,若該乘客在30 d內均無乘車記錄,則式(7)條件成立,則上述預測失敗。須基于式(8)在T中選擇一個下車站點,即基于站點上客數的下車站點預測。

5 實驗及結果分析

5.1 數據清洗

車聯網設備可能有數據缺失,需要將車聯網設備的數據進行關聯并清洗,按如下步驟去除因為設備功能而導致問題的記錄。

步驟1 若某條調度記錄的站點信息在基礎信息表中不存在,則在調度表中刪除該記錄。

步驟2 若某條刷卡記錄的線路號和車輛號在調度表中不存在,則在IC刷卡記錄表中刪除該記錄。

步驟3 將調度表中全部線路號和車輛號按日分組形成分組記錄,若某條刷卡記錄的線路號和車輛號在同一天分組記錄中查不到,則在IC刷卡記錄表中刪除該記錄。

步驟1～步驟3分別考慮車輛調度設備的配置有誤或發生故障、刷卡機與車輛調度設備的某些設置不一致、在某一天調度設備故障的問題進行針對性清洗。不排除例如網絡問題等其他極少數情況出現以上數據問題。

數據清洗結束后將輸出清洗后的IC刷卡記錄表和調度表。清洗前數據大小約15.6 G,清洗后由于IC刷卡記錄表、調度表以gzip格式壓縮并以序列文件存放,大小約3 G。

5.2 基于Hive的OD挖掘

5.2.1 代理鍵

代理鍵(surrogate key)在實際的HiveQL實現中經常被使用。即在內層或者先執行的查詢根據條件分組新增一列標識,一般是行號,用于外層或后執行的查詢來識別順序、大小和其他記錄間關系,具體的使用方法如下。

(1)距離度量。在3.1節感知時間遠近,4.2.1節構造出行規律表時需要連接時間最近的下次上車記錄,4.2.2節衡量一個下次上車站點中多個候選下車站點的遠近,均以代理鍵實現。先執行的查詢做批量連接,計算所得時間差或兩站點幾何距離作為度量值。3.1節按卡號、刷卡時間分組,4.2.2節按下次上車站點分組,按度量值升序排序生成一列行號。外層的查詢僅讀行號即可知道兩條連接結果的時間、距離的遠近,最小的行號所在行即最近時間或最近幾何距離的連接結果。

(2)臨時主鍵。3.2、4.3節在實現時,需要根據概率在一張表中選擇站點。然而,4個字段才能確定1個公交站點。可以先對記錄站點信息的子表去重,生成一列不重復的行號作為代理鍵作為臨時主鍵,并構成(臨時主鍵,概率)二元組。根據概率選擇一代理鍵的值,之后通過代理鍵連接具體的站點信息。

5.2.2 輪盤賭策略

若一張表每行存儲如下二元組:(s,ws)，其中s為候選站點,ws為該候選站點的權值。

需要按照權值求概率,再以概率選擇某一s。然而,在表查詢的過程中,表的每一行,可能分布在不同的從節點上。需要先應用to_map()策略,將所有站點及其概率歸并至一個map結構中,即{(s1,w1),(s2,w2)，…，(sn,wn)}。

設策略r()可處理上述map結構,分析站點、權值的類型,并根據具體的式(4)、式(6)、式(8)求sx概率Px,根據多個Px對將[0,1]分割成多個域,隨后生成該范圍一隨機數,隨機數落在某一域,取出該域對應的s。上述策略即為輪盤賭策略。

在Hive中,to_map() 可實現為用戶自定義聚合函數(user defined aggregate function, UDAF),將多行二元組聚合為一個map結構。策略r()已被實現為用戶自定義函數(user defined function, UDF),并貢獻[25]至開源項目Apache Hivemall。

5.2.3 時間不等關系轉換為相等關系

Hive中on條件不能表達不等關系,所以不等關系需要用數學方法轉換為相等關系。3.1節執行表連接時通過式(9)來等價替換式(1):

Ax·TaF=By·TbF

(9)

式(9)中：運算符“”即取模運算,其他同式(1)。

4.3節求個體下車概率需要查詢30 d之內的上車次數、4.2.3節求最近的非代刷卡預測結果,同樣使用了此連接方式。式(9)的意義是:兩時間字段可以有差值,但不能相差超過一個F的量,否則式(9)的相等關系不成立。式(9)可直接代入HiveQL的on表達式作為連接條件,相比使用where直接表示式(1)的不等關系,時間消耗更少,中間數據量更小。

5.2.4 Hive調優

已有的日志挖掘的實踐表明[26],針對具體的查詢任務,對Hive做針對性地調優,有利于任務順利執行并提高效率。

Hive提交任務后,轉化為Hadoop MapReduce來執行,MapReduce中間結果將保留在硬盤上。若所有從節點磁盤空間都不夠,則任務將無法執行。需要開啟中間結果和產出結果的壓縮,節省IO數據量。開啟壓縮后,表文件全部存儲為序列文件,防止單一壓縮文件過大且不能分割,下次只能分配一個Map讀取全表的問題。

并行調優的開啟可保證Hive充分利用集群的所有資源,并行執行多個無關聯的查詢,節省時間。

執行5.2.2節的to_map()函數時,載入內存的是一張表多個行的數據量,遠超出默認堆內存容量。需要將所在查詢獨立成CREATE TABLE流程,并進行Map端聚合關閉、Reduce數增加等針對性調優。否則將帶來堆內存溢出的風險。

關閉Map端聚合防止不合理的Map端聚合造成Job失敗。

5.3 OD挖掘及結果分析

基于Hive及站點上客數的下車站點預測過程如下。

算法1基于站點上客數的下車站點預測

輸入:部分下車站點預測表, 代理站點表

輸出:下車站點預測表

a) WITH 歷史上客數權值表 AS(

b) SELECT 站點, 代理鍵

c) count(*) AS 權值

d) FROM 部分下車站點預測表 p

e) JOIN代理站點表 d

f) ON p.上車站點 = d. 站點

g) GROUP BY 站點, 代理鍵

h) ), 下游站點權值表 AS(

i) SELECT 刷卡信息, 代理鍵, 權值

j) FROM 部分下車站點預測表 d

k) JOIN 歷史上客數權值表 h

l) WHERE d.站點序號 < h.站點序號

m) AND d基于個體下車概率預測失敗

n) ), 預測簡表 AS(

o) SELECT 刷卡信息,

p) r(to_map(代理鍵, 權值)) 預測站點鍵

q) FROM 下游站點權值表

r) GROUP BY刷卡信息

s) )

t) CREATE TABLE下車站點預測表

u) AS SELECT 預測簡表

v) UNION部分下車站點預測表;

實驗使用一臺服務器搭載兩個8核處理器,32 G內存,1 TB存儲空間，在其上虛擬出5個虛擬機,分別為1個主節點與4個從節點，配置均分且不超額分配，主節點僅負責調度,從節點承擔所有運算任務。整套算法在此平臺處理全部數據的實際耗時為17 613.8 s,這一時間開銷能滿足生產環境中離線數據挖掘業務的需求。實驗結果如表1所示。上車站點匹配率為清洗后IC刷卡數據的100%,下車站點預測率達到清洗后IC刷卡數據的99.6%。剩余的0.6%是由于上車站點匹配時,將某刷卡記錄匹配到了公交的末站,這類記錄無法進行下車站點預測。

表1 數據清洗與OD挖掘結果Table 1 The result of data cleaning and OD mining

將石家莊市2018年2月1日15路的OD結果處理成OD矩陣,繪制成熱力圖，如圖5所示，其中OD矩陣的行坐標為上車站點,列坐標為下車站點。熱力圖顏色越深說明在行坐標所指站點上車,在列坐標所指站點下車的客流越多,其上數值為具體的人數。由圖5可知,站點當日上客量:八一站10人,最少；南郭站148人,最多。站點當日下客量:八一站28人,最少；南郭站122人,最多。當天南郭站上車至南郭小區下車的乘客最多,38人。西王小區站上車至南郭站下車,長興街南口站上車至南郭站下車的乘客較多。由此可推斷,南郭站是非常重要的站點。若南郭站因施工或其他原因無法使用,則其周邊站點的客流將會被大幅影響,對于大多數乘客,必定會出行不便。

圖5 OD矩陣Fig.5 OD matrix

5.4 與其他方法的比較

在已挖掘的OD數據中,選取2018年1月1日—2018年3月27日536路單條線路所有站點的OD記錄,按站點分別累加上車人數、下車人數,分別作為x、y,對得到的所有站點x、y做線性回歸,即進行出行與吸引校驗[16]。如圖6所示,每一公交站的上車人數,下車人數為圖中一點。回歸方程的斜率接近1,證明出行量與吸引量基本相等,挖掘出的OD記錄有較高的質量,可用于實際業務中。

圖6 536路累計OD量線性回歸Fig.6 Linear regression of OD aggregation of 536 bus lines

將本文模型與廣東省智能交通系統重點實驗室的兩次研究成果[16,19]進行比較,結果如表2所示,文獻[16]在單條線路的小數據集上有較好的性能,但文獻[19]在大數據集上的O匹配率,D預測率均遜色于文獻[16]在小數據集上的表現。本文方法：O匹配率、D預測率在大數據集上均優于文獻[19]。

表2 實驗結果對比Table 2 Comparison of experimental results

6 結論

在海量數據中離線挖掘乘客OD是目前城市公共交通行業最迫切的需求之一。可視化的OD矩陣可向上層決策提供支持。能否全面、準確、快速地挖掘OD,對于后續的站點變動影響分析、靜態交通規劃等工作有重要的現實意義。

基于Hive實現了客流OD的挖掘,其具有如下優勢。

(1)算法基于Hive實現,實際應用場景下相比于傳統數據庫有更強的性能優勢。

(2)上車站點匹配的時間閾值可靈活調整,基于相等關系的表關聯手法效率高,下車站點預測無需考慮過多的邊界條件,無需設立換乘時間閾值,無需逐一掃描單條記錄進行循環而是并行處理多條線路挖掘OD。

(3)純HiveQL代碼部署簡單,對生產環境友好。

(4)應用Hive調優提高了資源利用率,縮短了任務執行時間,提高了離線任務的效率和穩定性。

(5)算法上車站點匹配率達到100%,下車站點預測率達到99.6%。實驗結果表明,出行量與吸引量基本相等,結果合理。在換乘分析等OD應用方面,有待進一步研究。