基于公交運營異常事件快速定位存儲平臺設計

遲 劍，劉艷飛

（河北民族師范學院數學與計算機科學學院，承德 067000）

0 引言

近幾年，中小城市城鎮化擴張速度迅猛，對公交運輸提出了新挑戰。以承德市為例，在2010 年前，承德公交集團年運輸旅客在8000 萬人次左右，到疫情前的2019 年，年運輸人數達到1.58 億人次左右，海量的乘客運輸軌跡和公交運營軌跡隨著公交車輛網絡升級，車載終端借助于GPS 與北斗雙系統復合模塊來定位實現了實時傳輸，公交公司能及時方便地獲取公交車輛的軌跡數據。大量的軌跡數據，促使公交系統管理由預定排班系統轉向實時的計算分析，對運營的公交車輛實現有效的監測。

面向公交運營監測中，實時探測運營異常是最迫切的應用需求。這里的異常主要指同一線路上車輛聚集問題、車輛擁堵問題、車速異常問題、非站點停車問題等，需要在存儲的數據中針對異常數據快速定位分類，進而提升問題解決的效率。在實際的運營過程中，公交企業普遍采用成熟的數據庫產品，比如甲骨文的Oracle Spatial，或者是成熟的云存儲平臺，采用規定的接口和模式訪問相關的數據，既定的條件限制下，在海量數據中快速定位異常數據，是國內外展開研究的熱點問題。

針對云存儲平臺，一般主要對數據索引以及存儲結構兩個方面加以改進加快定位速度。呂江波等［1］提出基于車輛軌跡誤差來源，研究統計分析方法，設計了基于Hadoop 的預處理模型方案，解決數據量大的時候數據分析瓶頸。喬千雄等［2］提出根據歷史數據分析，測定異常行為數據分類，根據分類狀態借助于MapReduce 算力，完成異常數據監測。余列冰等［3］根據軌跡數據基本特征，重設Hbase中分布列的數據結構，采用k近鄰算法，提出了融合時空劃分和軌跡分段的組織方法，提升了稀疏區域數據處理效率。魏學才等［4］根據數據的訪問頻度分為冷熱數據，提出多數據編碼機制，基于HDFS-RAID 設計了相應的框架，部署于Hadoop集群中。李劍斌等［5］在Spark 并行計算框架中實現車輛軌跡數據實時分析區域車輛密度，挖掘道路擁堵狀況，在治理擁堵問題上快速定位擁堵點。另外，為了獲取更高的數據存儲和查詢性能，挖掘數據特性，構建索引也是研究點之一。Meng 等［6］早在2012 年在海量數據分析中構建分區位圖索引，和傳統的索引相比，非常顯著地提升了范圍查詢。Dittrich 等［7］早在數據上傳到Hadoop 前，就構建HALL 索引，提升上傳處理速度，比單獨在Hadoop 上的數據處理速度提升較為顯著。文獻［6］和文獻［7］較早提出了兩種海量數據中數據處理方向和索引算法，這也成為近年來研究的熱點問題。相關研究的改進方向主要根據軌跡信息點特性，軌跡相關區域劃定，軌跡相似度分析來快速定位相應帶查詢區域。例如，針對車輛軌跡數據的連續性，黃火榮等［8］依據連續歷史數據確定分段，依據分段設計索引實現查詢，取得了很好的查詢性能。Shen 等［9］對原始數據預處理階段構建位圖索引結構，實現兩段查詢，分別對持續時間和間隔時間進行優化，這對解決公交問題的連續車輛間隔和擁堵時長定位有一定的啟發。鄭浩泉等［10］也驗證了根據時空軌跡數據特點設計三種存儲方法，數據上傳前完成分類，從而提升特定數據挖掘速度。

在實際快速定位存儲應用中，由于公交企業存儲結構和數據采集結構是固定的，其更新的可能性比較低，另外在中小城市中，站點之間的距離較短，而車輛擁堵的時間一般小于20分鐘，要求更快定位異常點。毛嘉莉等［11］在軌跡異常數據綜述中指出，車輛軌跡異常數據分析基本途徑是融合軌跡異常的時間特性和因果聯系，實現數據過濾，繼而完成大空間內數據異常定位。因此，本文針對海量公交運營數據的位圖索引過濾，而后在模擬的公交存儲框架上完成異常數據定位，建立異常數據臨時存儲區作為數據分析源，旨在解決異常車輛的快速定位問題。

1 公交運用數據存儲平臺及異常數據存儲結構

目前公交集團數據集遷移云平臺已成大勢所趨。本文模擬公交集團試驗線路采用的云存儲平臺構建基本的存儲框架。在Hadoop 生態系統中，以數據存儲和分析為目的的分布式平臺，包括數據采集、數據存儲和數據分析三個部分。數據采集層依據GPS 傳輸，采集車輛運行數據以及路口數據和IC 卡數據；數據存儲層使用HDFS 作為數據存儲，同時依據Impala 完成數據的多維預處理；數據分析層借助HBase 查詢接口，實現實時查詢分析，具體如圖1所示。

圖1 存儲平臺架構

數據采集層采集到的數據包括靜態數據和動態數據。靜態數據通過批處理方式將靜態站點數據傳入存儲層；實時動態數據經過簡單的清洗后，讀取進入HDFS分布式存儲系統，在該存儲系統上，采用Impala 結合位圖索引探查HDFS 數據，普通數據存入歷史數據庫，異常定位數據存入異常數據實時分析數據庫。

本文構建的平臺框架在HDFS 上部署了Impala 實現數據探查、構建區間位圖索引并定位異常數據區域。其中Impala 基于Hadoop 的SQL查詢性能，實時查詢HDFS中的實時點數據。借助于Imapalad 守護進程，在每個DataNode 完成查詢點請求。查詢框架如圖2所示。

用戶發布的SQL 查詢請求任意空閑的Impalad節點，返回查詢id。而后Impalad執行查詢分析，從元數據庫獲取元數據，從HDFS中獲取數據地址，得到該查詢相關的數據節點。Impalad 中的協調器coordinator 將查詢子任務分布到不同Impalad 節點，根據相關子任務請求完成相應的執行結果。查詢結束以后，需要單獨的子任務完成結果匯總，轉換為結果信息，用戶根據相應的接口，讀取查詢結果。

應用過程中，Impala 應對海量數據場景，導致查詢出錯的可能性較大，同時用于多維查詢中出錯率較高。本次實驗中對于探查數據的csv 文件，首先經過區間位圖索引分類，對可能近似數據實現關鍵數據屬性連接，進入異常檢測數據集，再應用Impala完成搜索。

本實驗數據采用真實的承德公交數據車輛GPS 數據和主要路口數據，其中車輛GPS 數據如表1信息，路口數據如表2信息。

表1 車輛GPS數據

表2 路口信息數據

數據采集過程中清洗掉由于客觀因素比如天氣，網絡通信影響，存儲平臺借助Impala 實時查詢框架，在實時上傳的數據中定位異常運營車輛的基本信息。

本存儲平臺除了在存儲階段探查數據異常之外，主要目的是監測運行異常。運行異常大致分為兩類，車輛異常和道路異常。這種異常是衡量運營乘客滿意度和運營成本的主要指標。其中車輛異常主要包含有車速在不同路段之間的速度異常，以及相同線路車輛聚集異常等，道路異常主要為道路擁堵異常，造成車輛無法準點進站。本實驗驗證兩種異常事件：

（1）單點速度異常事件：公交車輛在不同形式路段的運營速度超過平均速度或者同一線路車輛在運營中同一線路、同一方向上車輛間距到達臨界值從而引發的異常。

（2）道路擁堵異常事件：公交車輛即將通過路口車輛密度到達臨界點引發的異常。這里僅僅針對路口進行異常判斷，主要由于目前僅能收集主要路段的路口行車數據。

公交運營過程受到司機主觀影響，因此異常數據是普遍存在的，在固定的時間周期內海量數據中順序掃描異常數據，無疑耗費大量的時間，因此掃描前數據過濾是非常有必要的。高強等［12］在數據處理關鍵技術提出了位圖索引過濾多維表的方案，在提升性能的設計方面具有很強的代表性。本文針對異常數據，建立區域編碼以及定點查詢連接機制，在實驗分析部分展示了在此存儲平臺上查詢結果。

2 基于改進位圖索引，構建Impala查詢平臺

基于海量數據批處理查詢以及實時查詢效率的衡量，采用Impala 作為HDFS 上層數據探查。Impala 直接查詢HDFS 文件，查詢操作通過Impalad 服務，在內存中完成查詢。查詢過程中，每個Impalad 的緩存會存儲最近加載的全部查詢表，可以實現實時任務交互。Espeholt等［13］針對Impala 性能測試分析，查詢最主要的挑戰就是內存的容量。Impala 查詢中，Impalad 結點會緩存所有元數據，這樣方便了對同一個表重復查詢使用，但當超出內存容量時會直接報錯。因此在查詢前，需要針對海量采集到的數據，利用區域位圖編碼，快速實現相關數據區域定位和多表連接。多維結構中應用位圖索引完成多表連接是可行的，賀智明等［14］、張延松等［15］都分別應用了位圖索引解決了海量數據區域查詢設計方案。據此，本次實驗將定時收集到的海量公交軌跡數據以及路口數據集成分類存儲，生成軌跡運行屬性值。按照各個站點處于不同的路段，設置公交運行速度時限，按照路段和速度時限完成位圖編碼，對采集的數據清洗，篩選出超出路段速度閾值的數據，同時根據相應路段定位路口數據，連接篩選數據和路口數據建立新表。Impala 中通過設定SQL 語句，定位異常數據值。建立區域位圖索引的聚集方案為：

（1）根據歷史數據，將不同路段車輛準點到站平均車速以及規定的最小速度作為不同街區各站點之間的閾值，為一個屬性區間C={(v1,v2),(v2,v3),….(vn-1,vn) }，該屬性描述了車輛在不同街區形式的正常速度區間分布，如果相應速度在該區間之外，則為速度異常特征值。

（2）建立路段位置和速度變化區域的位圖索引，根據不同路口所在的街道，檢查車輛的速度是否超過閾值。所以每一個索引數據分成兩個部分，其中后三位為所在街道位置，其余位數為實時掃描速度，不同的街道速度監測閾值不同。因此給定n個基數{b1,b2,…,bn}，一個數據V可以分解為{v1,v2}，因此數據V的索引為

具體設計如表3所示。

表3 基于范圍位圖索引示例

（3）采集并過濾數據。利用上述位圖索引過濾數據集，上傳異常區域數據集。其中位圖索引篩選過程：首先確定路段位置，假定車輛速度在相應標準范圍之外，則標記為1，該數據上傳，否則標記為0，放入等待區，接受批量上傳。

（4）在設定的范圍內搜索異常點，按照key值存入Hbase 數據庫，可以直接定位相應數據?？紤]表的Rowkey 的長短，采用路口標識和車輛編號迭加車輛速度作為行鍵，存儲車輛GPS 數據。

以上的存儲設計，在數據上傳初期，利用位圖索引初步在海量數據中篩選區間異常數據，此時從數據中把可能異常數據篩選出來，縮小了后繼Impala 查詢的掃描區間，進一步提升了掃描效率，同時避免了在Impala 的多表中查詢。在第一步索引中，以路段為關鍵字，聚集路口數據表中相應路段數據，以速度關鍵字聚集軌跡數據中位置、速度、車輛信息關鍵字，直接組織異常文件的存儲結構，在完成多維數據的位圖聚集上，進一步提升Impala 的查詢速度，同時縮小了數據量。加入時間戳間隔控制，避免進入內存數據過大，減少了查詢出錯出現的次數，提升了查詢效率。

3 存儲平臺性能測定

為了驗證位圖索引預處理存儲平臺和Impala的查詢效率，實驗的樣本集來源于承德公交2018 年5 月份一個月的路口數據和GPS 數據，為疫情前的正常實驗數據，同時考慮到5 月份承德進入旅游季，所有備用的公交車輛全部正常運營，共包含872 萬條GPS 數據，以及2032萬條路口數據，實驗測試了一個星期數據以及一個月的數據用于異常查詢中的性能分析，二者主要的區別是位圖索引的建立花費的時間不同，同時比較了使用位圖索引和僅使用無索引Impala 在存儲框架上定位的速度。實驗硬件環境包括3 臺內存2 G 的計算機，軟件環境使用Ubuntu 16.04、Hadoop 2.2.0、JDK 1.6、Impala1.2.0搭建定點查詢模型。

其中定點查詢車輛語句：

范圍速度范圍語句：

加入位圖范圍索引以后，減少了掃描區域，提升查詢性能，以公交一個月數據為例，實際查詢性能如圖3所示。

圖3 查詢性能結果

為了獲得更正確的結果，實驗中的數據為同樣測試執行10 次后查詢時間的平均值。同樣循環查詢測試了Impala 錯誤中斷次數，改進后Impala 在運行1 天時間內，錯誤中斷次數為0，這為后續數據分析平臺穩定運行提供了基礎。

4 結語

在公交運營透明化的趨勢下，精準的運營分析是乘客和公交企業共同的期盼，是智慧公交最終的目的。智慧公交的大腦，來源于海量歷史數據的分析和實時數據的精準定位。本文通過在公交集團云存儲平臺上模擬精準定位實時分析，應用Hadoop 平臺，來源于歷史數據的標準設定，改進了基于范圍區間的位圖索引，預先構建頻繁查詢數據集，進入HDFS 存儲層，供給上部Impala 定位查詢，產生異常數據存儲Hbase數據庫，實現異常數據的存儲和實時數據發布。實驗中可見在查找成功前提下，改進后的平臺在查詢定位速度以及出錯率上有了很大的改進。為后一步的精準調度奠定了數據基礎。