基于公交运营异常事件快速定位存储平台设计

迟 剑，刘艳飞

（河北民族师范学院数学与计算机科学学院，承德 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数据库，实现异常数据的存储和实时数据发布。实验中可见在查找成功前提下，改进后的平台在查询定位速度以及出错率上有了很大的改进。为后一步的精准调度奠定了数据基础。