李 璇,吳 雷,2,姜 夢,潘 曉*
(1.石家莊鐵道大學,河北 石家莊 050043;2.燕山大學 信息科學與工程學院,河北 秦皇島 066004)
隨著移動定位設備、大數據技術的不斷發展,人類活動每時每刻都會產生大量帶有位置坐標和時間標簽的軌跡大數據。軌跡大數據中蘊含著豐富的路網特性與交通特性,來源廣泛,數據格式多樣。軌跡大數據中的時空維度動態關聯特性被離散化表示,語義特征被弱化,使得從軌跡大數據中挖掘有價值的信息變得困難[1-3]。基于異構圖結構的知識圖譜為海量、異構、動態的數據表達、組織、管理提供了一種有效的方式,更接近于人類的認知思維[3]。目前,知識圖譜的構建方式主要包括自底向上和自頂向下兩種[4],兩種方式均沒有標準且統一的構建流程,其中自頂向下的方式多用于借助百科類網站、專家知識等數據源,從高質量數據中提取本體和模式信息,再加入到知識庫中,采用志愿者眾包編輯數據頁面或咨詢專家的方式來構建,費時費力費財[5]。另外,數字化時代中每個企業或組織在其業務系統中都積累了大量數據,原有系統已不能滿足人們迅速、準確、智能獲取信息的需求;更多的用戶希望數據得到更好的組織,進而為數據擁有者提供快速準確的知識抽取、加工,幫助智能決策。領域知識圖譜可采用自底向上的方式構建,從大量的業務數據中提取置信度高的資源模式,方便查詢、發現和挖掘知識[6-7]。因此,本文基于已有的網約車軌跡大數據,采用知識圖譜表達交通實體和關系的多樣性。基于存儲在MySQL中的網約車軌跡和訂單信息等業務數據,自底向上構建司機出行交通知識圖譜,提取司機出行特點與規律,發現和挖掘隱藏知識,為交通預測和決策提供更多的依據。
綜上所述,本文貢獻在于,基于新的知識需求探索出了從關系型數據庫到知識圖譜自動轉換與構建的路徑;在真實數據集上構建了司機出行知識圖譜,可通過Neo4j的Cypher語言進行交通知識查詢,在目標領域的分析上具有實用價值。
本文采用滴滴出行蓋亞數據開放計劃提供的2020年8月深圳市網約車的真實業務訂單數據,具體包括路網拓撲數據和訂單行程信息,路網拓撲數據存儲在CSV文件中,結構為。經統計,一個月的訂單數量為8 562 059條,涵蓋了80 399位網約車司機。將數據源中的訂單行程數據存儲在MySQL中,結構如表1~3所示。

表1 訂單信息表

表2 訂單下軌跡的道路小段信息表

表3 訂單下軌跡的路口信息表
對該月內每位司機的接單數量進行統計分析發現,該月只接單一次的司機人數最多,活躍度最低;活躍度最高的司機在該月接單603次,如圖1所示,司機接單數量呈長尾右偏分布。

圖1 司機活躍度分布直方圖
網約車司機的訂單數量一定程度上反映了司機在某交通區域內的通行頻率。本文選取活躍度位于Top5%的司機,從每天上午8:00開始,以每5 min為一個時間戳、24 h為一循環,時間戳的范圍為0~288,查看所選司機在不同時間段的訂單流量分布情況,如圖2所示,可以看出,司機接單呈現出早高峰和晚高峰的特點,大量訂單產生在7:00—23:00時間段內,符合通勤規律。

圖2 訂單流量分布直方圖
自底向上構建知識圖譜,即從數據層出發首先歸納實體,再抽取實體、屬性和實體間的關系,然后歸納知識并對知識進行存儲,最終實現知識圖譜的構建。其中,知識歸納的核心是知識抽取、知識融合、知識補全。存儲在MySQL數據庫中的出租車訂單行程數據包含大量的交通實體、屬性和實體間的關系,信息散落在不同的數據表中被割裂,對于數據查詢不利,較難從中獲取交通知識。本文采用五步法,通過知識抽取、知識存儲、知識引入、知識融合和知識補全,實現了從MySQL存儲的網約車業務數據到司機出行知識圖譜的構建。總體構建流程如圖3所示。

圖3 總體構建流程圖
2.2.1 知識抽取
首先,梳理存儲在MySQL訂單行程數據中數據的含義和關系,明確交通事件的實體、實體屬性以及實體間的關系,根據數據間的關聯和特征,初步分析交通軌跡的簡要特征;然后,根據所描述對象的不同,分為司機、訂單、路段和路口4大類。由表1~3可知,司機與訂單具有一對多的關系,訂單與軌跡具有一對一和一對多的關系,如視訂單為一個實體,訂單編號、訂單行程總時間、訂單路線距離是屬性。
本文采用D2R技術從網約車業務數據中抽取知識。D2R技術,即Database to RDF,是一種能從關系型數據庫中抽取知識的技術,主要包括D2R Server、D2RQ Engine和D2RQ Mapping語言。D2RQ根據可定制的D2RQ Mapping文件將關系數據庫中的數據轉化為RDF格式。RDF,即資源描述框架,是一種用于描述事物的方法,其本質是一種數據模型。RDF形式上表示為SPO三元組,即<主體,謂詞,賓語>,既可稱為一條語句,也可表示知識圖譜中的一條知識[8]。在Mapping文件中定義了整個映射的主要模式:數據庫中的表映射為一個類,表中的每一行是一個資源或實例,每一列是資源的屬性,表與表的外鍵則映射為關系[9]。本文基于D2RQ工具對MySQL中的訂單行程數據進行知識抽取,以一條訂單信息為例,說明從二維表數據到RDF數據的轉化過程。
MySQL中在2020年8月1日記錄了一條訂單編號為1612040的訂單。通過D2RQ工具得到的RDF數據為:

這條RDF數據表示為訂單1612040和日期20200801之間的關系是tbl_order_date,即在2020年8月1日產生了一條訂單編號為1612040的訂單。
2.2.2 知識存儲
通過上述操作,將存儲在MySQL中的訂單行程數據轉化為大量的RDF數據。知識圖譜主要包括RDF和圖數據庫兩種存儲方式,目前普遍認為,RDF的重點在于數據發布和資源共享,圖數據庫的重點在于對圖數據的高效查詢和搜索[10]。因此,本文選擇主流圖數據庫Neo4j來存儲知識圖譜。
利用Neo4j的Neosemantics插件將生成的大量RDF數據導入到Neo4j中進行存儲。在Neo4j中,知識便以圖的形式組織在一起,進而形成了基于屬性圖的知識圖譜。利用Neo4j的Cypher語言進行交通實體、關系和相關實體屬性的查詢,獲得與司機出行相關的知識,如某時段路網交通狀態、司機歷史軌跡和各時段網約車流量等。此外,利用Neo4j的可視化交互前端可以圖的形式展示交通實體、關系和屬性以及規模。
由MySQL中的訂單行程數據構建的圖譜如圖4所示,以司機節點為核心,關聯到與該司機相關的訂單節點,再由訂單節點關聯到該訂單行程軌跡,具體包括路段和路口。然而,這些路段和路口在圖譜中并沒有以軌跡的形式展現,沒有還原出原有訂單行程的軌跡信息,軌跡序列仍是離散的形式。對于不同的業務訂單,其訂單行程軌跡可能存在路段交集。一方面,圖4中的圖譜不能直接顯示存在路段交集的軌跡;另一方面,這些路段交集具有相同的link id和拓撲關系,在圖譜中會出現多次。

圖4 訂單行程數據形成的圖譜
2.2.3 知識引入
網約車軌跡記錄了司機出行過程中車輛移動過程和車輛狀態變化,包含網約車司機出行的知識。為了連續表達訂單行程中重要的軌跡信息,完整還原司機出行的全過程,本文將動態的訂單業務數據與靜態的交通路網相結合,使訂單行程軌跡關聯到靜態路網上。本文利用Neo4j的load CSV功能和Cypher語言批量建立路段節點與路段間的拓撲關系,再將靜態的路網知識引入,最終在Neo4j中建立路網拓撲圖。具體構建流程如圖5所示。

圖5 路網圖譜構建流程圖
2.2.4 知識融合
如圖4所示,僅由訂單軌跡形成的圖譜不足以表示司機從接單、行駛再到目的地的全過程,且難以體現軌跡特點。因此,本文將訂單行程數據形成的圖譜與路網拓撲形成的圖譜進行知識融合,使訂單行程軌跡關聯到靜態路網上。本文將具有相同link id的訂單行程軌跡路段與路網中的路段建立關系,表達為路網中的路段在不同訂單軌跡下的狀態。狀態信息包括在此訂單下路段的通行時間、通行比例和路況狀態。經過上述處理后,離散的訂單行程軌跡通過路網拓撲被連續表示;同時,靜態的路網拓撲具有在不同訂單下的路段狀態信息。訂單下的路段與靜態路網的連接關系如圖6所示。

圖6 知識融合后的圖譜
2.2.5 知識補全
僅交通路網不足以體現軌跡中蘊含的交通知識,還需將路口等信息補充到交通路網中。訂單行程下的路口節點包含其所屬訂單編號、路口編號、路口通行時間和路口上下游路段的link id。基于路網拓撲關系,利用Python計算每個link節點的出入信息,綜合訂單行程下產生的路口信息,再通過Cypher語言將路口知識補充到知識圖譜中。
2.2.6 交通知識查詢
在構建的司機出行知識圖譜上,可利用Neo4j的Cypher語言進行交通知識查詢,可查詢司機歷史軌跡并通過Neo4j可視化界面對網約車軌跡進行展示。對于某訂單的軌跡,可進一步查詢軌跡中各路段在司機行駛時的狀態,顯示相關狀態信息,如軌跡中各路段的通行時間、通行比例、路況和路口通行時間等。
本文構建的司機出行知識圖譜將路網結構與司機出行知識相結合,支持交通出行知識的查詢。本文采用自底向上的方式從結構化數據中構建司機出行知識圖譜,還原了軌跡大數據中的時空關系和語義關聯,探索出了從關系型數據庫到知識圖譜自動轉換與構建的路徑,可被擴展應用于其他領域的結構化數據,對推廣知識圖譜應用起到了推進作用。
未來考慮從司機的視角出發,結合構建的司機出行知識圖譜,還原司機從接單到行駛、再到達目的地的全過程,從中挖掘出有關于司機的交通知識。在司機接單推薦過程中,提供交通知識進行決策;可查詢目標起終點歷史軌跡,利用知識圖譜的異構圖結構并結合圖算法進行軌跡推薦和時間預估等交通出行預測,使出行更加智慧、更加個性化。