基于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应用方面,有待进一步研究。