基于图数据库的公交出行行为分析

屈新明 郭 鹏 丘建栋 谭章智 董绍轩

（1. 深圳市城市交通规划设计研究中心有限公司，广东 深圳 518021；2. 中交第二公路勘察设计研究院有限公司，湖北 武汉 430056）

关键字：图数据库；Neo4j；IC卡数据；公交出行行为

近年来随着大数据挖掘分析技术的快速发展，在各领域处理复杂网状关系的挖掘分析需求逐渐增加[1]。在面向复杂场景下数据关联挖掘分析中，主流的关系型数据库并不是都适用于场景分析，尤其是在多维关联查询分析时，关系型数据库效率较低[2]。随着图数据库的快速发展[3-5]，为数据挖掘分析提供了新的解决方案。郝培豪[6]研究分析了图数据库的警务安保知识图谱可视化分析；康杰华[7]研究分析了图形数据库Neo4j的RDF数据存储；柴博[8]等人研究分析了基于图数据库的电力通信网络运行方式建模；张芸芸[9]等人研究了基于Neo4j图谱的信用卡欺诈检测。

目前图数据库在交通中的应用较少，在公交出行行为分析方面，游婷[10]等人研究了基于公交IC卡信息的公交客流推算；孙世超[11]研究基于宏微观数据嵌套的公交用户细分方法；秦政[12]研究基于公交IC卡和GPS数据的乘客上下车站点提取；马晓磊[13]研究了基于公交IC卡数据的上车站点推算。

本文将探索图数据库在公交出行行为分析中的应用，利用Neo4j图数据库对深圳市某一工作日的公交刷卡数据，公交线路数据进行建模分析，挖掘识别公交出行行为，并对比分析了相同分析场景下ORACLE数据库与Neo4j图数据库的查询效率。

1 图数据库简介

1.1 图数据库介绍

图数据库是基于图形理论实现的一种非关系型数据库，它的底层数据存储和与查询方式都是以图论为基础，其中图论中的基础元素为节点和节点之间的边，在图数据库中对应的就是节点和关系。图形数据库作为一种非关系型数据库，将结构化数据存储在网络 （图） 上而不是关系型数据库中的表，常见的有Neo4j、FlockDB、AllegroGraph、GraphDB、InfiniteGraph、TigerGraph、腾讯星图等。Neo4j是由Java实现的开源图数据库，实现了专业数据库界别的图数据模型存储，并提供完整的数据库特性，是目前生产环境中主流的图数据库引擎，由于开源特性及其丰富的文档，本文将使用Neo4j构建公交出行图数据库场景。

1.2 图数据库与关系型数据库的区别

关系型数据库与Neo4j建库示意如图1所示。

图1 关系型数据库与Neo4j建库示意

关系型数据库通过外键记录两个表或者多个表之间的引用关系，在进行关联查询时通过外键在主表中寻找对应的主键记录进行数据搜索与匹配计算操作，关联查询时将会耗费大量系统计算资源，尤其是在多表关联查询场景下查询效率极低。关系型数据库中多对多关系需要使用中间表，查询效率进一步下降。图数据库使用图论存储节点和节点之间的关系，而每个节点都包含对应的关系列表，用于存放该节点与其他节点的关系，节点之间的关联挖掘分析直接基于图论进行搜索分析，在复杂数据挖掘分析效率上远高于关系型数据库。

2 公交出行行为场景建模

2.1 基础数据

基础数据为公交线路Busline表和公交刷卡记录IC_card_record表，其中，Busline表包含了深圳市约1 000条公交线路对应站点数据，IC_card_record表为深圳市某个工作日约300万条刷卡记录，刷卡记录已经匹配下车站点信息。公交线路如表1所示，公交刷卡记录如表2所示。

表1 公交线路表

表2 公交刷卡记录表

2.2 建模框架

将公交出行行为关联数据抽象成如图2所示的建模框架。

图2 公交出行行为场景建模框架

其中实体包含：公交车辆、 公交站点、公交线路、IC卡（公交出行者）、刷卡记录；关系包含：公交车辆—公交线路（属于）、公交线路-公交站点（经过）、IC卡-刷卡出行（出行）、公交站点-刷卡出行（上车）、公交站点-公交站点（相邻）、刷卡出行-公交站点（下车），场景建模规模达到5 00万节点，1 000万条边。

2.3 节点建模

将原始数据两张表转为图数据库对应的节点，其中数据表中的一条记录对应图数据库中的一个节点，整个数据表对应图数据库中某一节点集合（标签）。

公交车辆实体：从IC_card_record表中提取vehicle标签（去重），单个节点仅包含vehicle_id属性。

公交线路实体：从busline表中提取line标签，单个节点包含line_id、line_name、dir、line_dir_name等属性。

公交站点实体：从busline表中提取station标签，单个节点包含：station_id、station_name、lng、lat等属性。

刷卡记录实体： 从ride表中提取ride标签， 单个节点包含：ride_id、card_id两个属性。

IC卡标签实体：从IC_card_record表中提取card标签（去重），单个节点仅包含card_id属性。

2.4 关系建模

根据基础数据中的两张表处理节点之间的对应关系。

公交车辆—＞公交线路（属于关系）：从IC_card_record表中提取公交车辆与公交线路的属于关系（去重），关系匹配字段为vehicle_id—＞line_id。

公交线路—＞公交站点（经过关系）：从busline表中描述了每条公交线路经过公交站点的关系，关系匹配字段为line_id—＞station_id，关系属性包含station_index。

公交站点—＞刷卡记录（上车关系）：从IC_card_record表中提取公交站点与刷卡记录的上车关系，匹配字段为station_id—＞ride_id， 关 系 属 性 包 含line_id，up_station_index，up_day，up_min。

刷卡记录—＞公交站点（下车关系）：从IC_card_record表中提取刷卡记录与公交站点的下车关系，匹配字段为ride_id—＞ station_id，关系属性包含line_id、down_station_index、down_day、down_min。

IC卡—＞刷卡记录（出行关系）：从IC_card_record表中提取IC卡与刷卡记录出行关系，匹配字段为card_id—＞card_id。

公交站点-公交站点（相邻）：从busline表中根据经纬度坐标记录公交站点之间的相邻关系，匹配字段为station_id—station_id。

3 公交出行行为分析

3.1 同乘人员识别

识别提取早高峰远距离同乘人员，根据图数据库挖掘分析早高峰（7：30～9：00）、长距离（大于10个站）的同乘人员（同一站点上车、同一站点下车）情况。同乘人员识别分析结果如表3所示。

表3 同乘人员识别分析结果

分析结果表明，早高峰乘坐公交长距离出行到科技园站的人较多，可以进一步优化预约巴士地到发班次。

3.2 站点最大公交客流提取识别

提取识别全天点对点最大公交客流情况，支撑公交站点线路优化，其中采用ORACLE查询时间为3.214 s，Neo4j查询时间为25.637 s，单表之间的查询中Neo4j性能低于ORACLE数据库。站点最大客流提取识别如表4所示。

表4 站点最大客流提取识别

3.3 关联查询识别

在Neo4j中进行多表关联查询，查询科技园公交站周边邻近站点经过的各条公交线路拥有的车辆数，用于提取各公交线路运行车辆数。关联查询识别如表5所示，关联识别框架如图3所示。

表5 关联查询识别

图3 关联识别框架

其中，采用ORACLE查询时间为2.403 s，Neo4j查询时间为0.142 s，多维关联查询中Neo4j性能远高于ORACLE数据库。

3.4 站点群之间的公交出行量识别

根据站点之间的邻近关系，识别提取公交站点群之间的公交出行量，支撑预约巴士开通与线路优化。直接通过ORACLE数据库无法单独完成查询检索，基于Neo4j可直接查询，得到分析结果。公交站点群之间的出行量识别结论如图4所示。

图4 公交站点群之间的出行量识别结论

4 结语

本文基于图数据库Neo4j构建了公交出行行为分析场景建模，对深圳市1 000条公交线路，一天工作日的公交刷卡数据进行建模分析，建模规模达到500万节点，1 000万条边。在不同的公交出行行为场景分析中对比分析了ORACLE数据库与Neo4j的查询性能，多维关联查询中Neo4j性能远高于ORACLE数据库，基于图数据库可以方便高效实现复杂数据的关联挖掘分析。

本文仅对深圳市一天工作日的公交刷卡数据进行建模分析，后续将构建更为复杂建模场景，构建交通知识图谱。