CN108959596A - 一种公交阶梯票价预测方法 - Google Patents

Abstract

本发明公开了一种公交阶梯票价预测方法，建立数据库Sqlserver；采集传回数据；对传回数据进行清洗，生成站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表；定期将数据库Sqlserver中的数据迁移至分布式系统存储数据库HBase中；根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算出车辆的预测营收数据。本发明可实时掌握和预测公交车营收情况，方便进行票价及收益管理，成本低，实现经常性、系统性和全面性的管理。

Description

一种公交阶梯票价预测方法

技术领域

本发明涉及数据预测技术领域，具体涉及一种公交阶梯票价预测方法。

背景技术

随着智能交通技术(ITS)的发展，全球定位系统GPS和自动乘客计数等车载设备应用日益广泛，可以实时地自动完成乘客上下车人数、时间、地点的记录，真实反映各时段、各区段上下车的客流情况。其获得的大量数据资源，为全面定量分析公交客流分布规律创造了条件。

但是，传统的公车系统虽然采用了全球定位系统GPS和自动乘客计数等车载设备，可获取海量数据，但并不能从这些海量数据中及时发现行业异常动向，从而导致管理部门不能及时作出准确的管理行为，影响行业发展。

而城市公共客运交通是城市的动脉，在保证社会效益的前提下，公交企业也期望获得一定的经济效益，对城市公交规划效益评估时，估价的重要分析参数是客运收入；但是，传统的具有阶梯票价的公交车的营收的管理难度比较大，乘客投钱情况难以了解，乘客投钱少投了，少投了多少一概不知，每月的营收只能上交多少是多少，没有准确的把握每趟车每次的营收，每天的营收；其缺陷和不足包括：

1)没有掌握和预测每天每趟车的每次的营收情况；

2)主要依靠人工调查，难以做到经常性、系统性和全面性，且成本高。

发明内容

基于此，针对上述问题，有必要提出一种可实时掌握和预测公交车营收情况，方便进行票价及收益管理，成本低，实现经常性、系统性和全面性管理的公交阶梯票价预测方法。

本发明的技术方案是：

一种公交阶梯票价预测方法，包括以下步骤：

a、建立数据库Sqlserver；

b、采集传回数据，并将该传回数据传输至数据库Sqlserver中；传回数据包括车辆ID、关门时间、闭门时间、上车人数、下车人数以及开门地点GPS数据；

c、对传回数据进行清洗，生成站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表；

d、定期将数据库Sqlserver中的数据迁移至分布式系统存储数据库HBase中；

e、根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算出某一辆车一天的预测营收数据。

在本技术方案中，通过客流统计车载设备传送客流数据，主要有车辆ID、上下车人数、开门地点的GPS数据、上下车站点，然后，通过数据清洗建立运营数据仓库，生成多个数据表；基于分布式系统存储数据库HBase的数据迁移系统，采用大数据迁移工具Sqoop定时进行数据迁移，定时时间可调，对于公交车运输来说，一般以天为单位定时导入数据，根据获取的数据，利用公交阶梯票价预测营收算法模型，预测出线路的营收金额；采用本技术方案，可以掌握和预测每天每趟车的营收情况，方便进行管理和收益控制，成本低，实现经常性、系统性和全面性的调查管理。

优选的，还包括以下步骤：

将真实营收数据与预测营收数据进行比对评估，若比值在0.95-1.05之间，则该预测营收数据有效；否则，无效，重新进行预测营收数据计算。

采用本技术方案进行票价预测营收计算，将一条线路的预测营收值算出后，与真实的营收数据对比，经测试，算法准确率达95％以上；可作为收益依据，掌握和预测公交车营收情况，便于对车辆进行票价、运输线路以及车次等情况的管理安排。

优选的，所述步骤a包括以下步骤：

优化数据库Sqlserver，若数据库Sqlserver中储存的数据量超过2G，则进行分区，创建分区索引。当数据库Sqlserver中储存的数据量超过2G时，对表进行分区，创建分区索引，优化查询，提高查询速度，可达到数十万条/秒的查询速度，数据库吞吐量达到100MB/s。

优选的，所述步骤d包括以下步骤：

d101、在Tomcat上设定定时代码，并于定时期间执行数据迁移导入；

d102、在数据导入过程中，判断上次导入是否成功，如果是，则进入步骤d104；如果否，则并进入步骤d103；

d103、加载上次导入所需数据，并执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则插入成功日志，清空数据库Sqlserver中的数据，并进入步骤d104；如果两次导入均失败，则插入错误日志，发出错误类型的通知，并进入步骤d104；

d104、执行本次导入，调用Sqoop将数据库Sqlserver中的数据导入分布式系统存储数据库HBase中。

数据迁移指的是因数据量庞大，将数据库Sqlserver数据中收集的公交客流信息、刷卡数据，按照月份定时导入Hbase中，用到数据导入工具是Sqoop，定时机制和数据导入是否成功由Java代码控制；为了提高Hbase的写能力，提高导入的速率，导入前可对HBase表进行预分区，避免写热点的问题，并将车辆ID和时间字段拼接成RowKey，有利用后期的查询；后期根据业务可以适当的对Hbase表中的其他字段建二级索引，提高相关列的查询速度；另外，如果项目中大概300辆车辆，每10分钟产生一条数据，一天运行12小时，一天产生的数据量大概是20000条数据，一年大概是700万条数据，占用数据库空间大概3G左右，现有Hadoop集群3台机器(1个master，2个DataNode)，hdfs的空间大小大概是两个T，理论上可以存储600多年的数据，大大满足了项目数据存储的需要；

因此，在本技术方案中，通常每个月都需要进行数据迁移，且必须保证数据迁移时不能出现重复数据，不能出现错误格式的数据，不能丢失数据；所以先将定时代码放至Tomcat上，开机后代码自动检测，例如，可在每月2号的凌晨2点开始导入；导入时，代码先判断上次是否导入成功，根据日志表中字段，如果是0表示上次成功，开始本次导入；其他情况表示失败，如果上次导入失败，先导入上次数据，成功后再开始本次导入，这样可以防止如因断电产生的数据导入错误等情况，同时，在导入过程中，对每个可能有异常的模块进行捕获处理，将相应的数据信息捕获处理，将错误信息以简单易懂的语句打印出，方便管理员进行相应错误的解决。

优选的，所述步骤d还包括以下步骤：

d105、判断本次导入是否成功，如果是，则进入步骤d107；如果否，则进入步骤d106；

d106、继续执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则进入步骤d107；如果两次导入均失败，则插入错误日志，发出错误类型的通知；

d107、插入成功日志，并清空数据库Sqlserver中的数据。

在上次数据导入判断成功后，开始本次数据导入，将数据库sqlserver表中的数据count求总行数，再在phoenix中模糊查询本月的数据行数，相等说明导入成功，插入导入成功日志，确认数据导入成功后，将数据库Sqlserver中的数据清空，以释放数据库Sqlserver空间；不相等说明导入失败，插入导入失败日志；失败后继续执行两次，如果最后还是导入失败，将本次导入的结果，通知管理员处理；充分保证了数据导入的可靠性，避免出现重复数据、错误格式的数据以及丢失数据等情况。

优选的，所述步骤d和步骤e之间包括以下步骤：

如果接收到对分布式系统存储数据库HBase的数据查询指令，则调用Phoenix进行二级索引查询。利用分布式数据库HBase和Phoenix组合的形式进行查询数据，实现了二级索引来提升非主键字段查询的性能，优化主键均匀分布写的压力；Phoenix是一个HBase的开源SQL引擎(用于存储、处理和保护数据的服务)，可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据，具有完整ACID事务功能的标准SQL和JDBC API的强大功能；不会降低HBase的效率，自身效率也不低。

优选的，所述步骤e包括以下步骤：

根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算某一辆车在第i个站点的营收金额M_i：

其中，M_i为第i个站点的营收金额，P为票价，i为站点个数，P_i为第i个站点的票价，S为站点，S_i为第i个站点，S_up为某个站点的上车人数，S_(i-1)up为在第(i-1)个站点的上车人数，S_down为某个站点的下车人数，S_(i-1)down为在第(i-1)个站点的下车人数。

优选的，所述步骤e还包括以下步骤：

计算某一辆车在从始发站到终点站的营收金额M_t以及一天的总营收金额R：

M_t＝∑M_i

R＝M_t*T

其中，M_i为第i个站点的营收金额，M_t为始发站到终点站的营收金额，R为一天的总营收金额，T为该辆车一天内从始发站发出的车次。

在上述技术方案中，根据车辆客流收集的数据，将每一趟的营收金额预测出来，具体预测方法是：

根据站点的上下车人数，假设靠前站点的上车人数在以次最靠近的站点下车，这样每个站点的营收相对就最大，但是这样对于整趟来说，最后的营收则最小，从而得到这趟车营收的最小值；

相反，根据站点的上下车人数，假设后一站点的下车人数全部来自于上一站点的上车人数，如果上一站点的人数不够，则从次靠前站点的上车人数中取，这样每个站点的营收相对就最小，但是这样对于整趟来说，最后的营收则最大，从而得到这趟车营收的最大值；

最后得到了一趟车辆的营收最大值和最小值，将其作为预测营收的区间；这样算出每趟车辆的预测营收预测值，将其加起来，得到每辆车每天的营收预测值，从而得到每条线路的每天营收预测值；

实现对公交车每天每趟车乃至每个站点营收情况的掌握和预测，且预测准确率高，便于公交公司以此预测数据进行规划、管理。

本发明的有益效果是：

1、对数据库Sqlserver进行优化，当数据库Sqlserver中储存的数据量超过2G时，对表进行分区，创建分区索引，优化查询，提高查询速度，可达到数十万条/秒的查询速度，数据库吞吐量达到100MB/s。

2、利用分布式数据库HBase和Phoenix组合的形式进行查询数据，实现了二级索引来提升非主键字段查询的性能；优化主键均匀分布写的压力。

3、实现对公交车每天每趟车乃至每个站点营收情况的掌握和预测，便于公交公司以此预测数据进行规划、管理。

4、对比评估预测营收数据和真实营收数据，经测试，算法准确率达95％以上；保证了预测的可靠性和准确性，可作为收益依据，便于对车辆进行票价、运输线路以及车次等情况的管理安排。

5、定期对数据库Sqlserver中的数据进行迁移，避免出现重复数据和格式错误的数据，保证不丢失数据，提高了数据的可靠性，使预测的结果更准确。

6、本发明的成本低，方便进行票价、线路、车次及收益等方面的管理，实现经常性、系统性和全面性公交管理。

附图说明

图1是本发明实施例所述公交阶梯票价预测方法的流程图；

图2是本发明实施例所述数据迁移的流程图。

具体实施方式

下面结合附图对本发明的实施例进行详细说明。

实施例1

如图1所示，一种公交阶梯票价预测方法，包括以下步骤：

a、建立数据库Sqlserver；

b、采集传回数据，并将该传回数据传输至数据库Sqlserver中；传回数据包括车辆ID、关门时间、闭门时间、上车人数、下车人数以及开门地点GPS数据；

c、对传回数据进行清洗，生成站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表；

d、定期将数据库Sqlserver中的数据迁移至分布式系统存储数据库HBase中；

e、根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算出某一辆车一天的预测营收数据。

在本技术方案中，通过客流统计车载设备传送客流数据，主要有车辆ID、上下车人数、开门地点的GPS数据、上下车站点，然后，通过数据清洗建立运营数据仓库，生成多个数据表；基于分布式系统存储数据库HBase的数据迁移系统，采用大数据迁移工具Sqoop定时进行数据迁移，定时时间可调，对于公交车运输来说，一般以天为单位定时导入数据，根据获取的数据，利用公交阶梯票价预测营收算法模型，预测出线路的营收金额；采用本技术方案，可以掌握和预测每天每趟车的营收情况，方便进行管理和收益控制，成本低，实现经常性、系统性和全面性的调查管理。

实施例2

本实施例在实施例1的基础上，还包括以下步骤：

将真实营收数据与预测营收数据进行比对评估，若比值在0.95-1.05之间，则该预测营收数据有效；否则，无效，重新进行预测营收数据计算。

采用本技术方案进行票价预测营收计算，将一条线路的预测营收值算出后，与真实的营收数据对比，经测试，算法准确率达95％以上；可作为收益依据，掌握和预测公交车营收情况，便于对车辆进行票价、运输线路以及车次等情况的管理安排。

实施例3

本实施例在实施例2的基础上，所述步骤a包括以下步骤：

优化数据库Sqlserver，若数据库Sqlserver中储存的数据量超过2G，则进行分区，创建分区索引。当数据库Sqlserver中储存的数据量超过2G时，对表进行分区，创建分区索引，优化查询，提高查询速度，可达到数十万条/秒的查询速度，数据库吞吐量达到100MB/s。

实施例4

本实施例在实施例2的基础上，如图2所示，所述步骤d包括以下步骤：

d101、在Tomcat上设定定时代码，并于定时期间执行数据迁移导入；

d102、在数据导入过程中，判断上次导入是否成功，如果是，则进入步骤d104；如果否，则并进入步骤d103；

d103、加载上次导入所需数据，并执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则插入成功日志，清空数据库Sqlserver中的数据，并进入步骤d104；如果两次导入均失败，则插入错误日志，发出错误类型的通知，并进入步骤d104；

d104、执行本次导入，调用Sqoop将数据库Sqlserver中的数据导入分布式系统存储数据库HBase中。

数据迁移指的是因数据量庞大，将数据库Sqlserver数据中收集的公交客流信息、刷卡数据，按照月份定时导入Hbase中，用到数据导入工具是Sqoop，定时机制和数据导入是否成功由Java代码控制；为了提高Hbase的写能力，提高导入的速率，导入前可对HBase表进行预分区，避免写热点的问题，并将车辆ID和时间字段拼接成RowKey，有利用后期的查询；后期根据业务可以适当的对Hbase表中的其他字段建二级索引，提高相关列的查询速度；另外，如果项目中大概300辆车辆，每10分钟产生一条数据，一天运行12小时，一天产生的数据量大概是20000条数据，一年大概是700万条数据，占用数据库空间大概3G左右，现有Hadoop集群3台机器(1个master，2个DataNode)，hdfs的空间大小大概是两个T，理论上可以存储600多年的数据，大大满足了项目数据存储的需要；

因此，在本技术方案中，通常每个月都需要进行数据迁移，且必须保证数据迁移时不能出现重复数据，不能出现错误格式的数据，不能丢失数据；所以先将定时代码放至Tomcat上，开机后代码自动检测，例如，可在每月2号的凌晨2点开始导入；导入时，代码先判断上次是否导入成功，根据日志表中字段，如果是0表示上次成功，开始本次导入；其他情况表示失败，如果上次导入失败，先导入上次数据，成功后再开始本次导入，这样可以防止如因断电产生的数据导入错误等情况，同时，在导入过程中，对每个可能有异常的模块进行捕获处理，将相应的数据信息捕获处理，将错误信息以简单易懂的语句打印出，方便管理员进行相应错误的解决。

实施例5

本实施例在实施例4的基础上，如图2所示，所述步骤d还包括以下步骤：

d105、判断本次导入是否成功，如果是，则进入步骤d107；如果否，则进入步骤d106；

d106、继续执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则进入步骤d107；如果两次导入均失败，则插入错误日志，发出错误类型的通知；

d107、插入成功日志，并清空数据库Sqlserver中的数据。

在上次数据导入判断成功后，开始本次数据导入，将数据库sqlserver表中的数据count求总行数，再在phoenix中模糊查询本月的数据行数，相等说明导入成功，插入导入成功日志，确认数据导入成功后，将数据库Sqlserver中的数据清空，以释放数据库Sqlserver空间；不相等说明导入失败，插入导入失败日志；失败后继续执行两次，如果最后还是导入失败，将本次导入的结果，通知管理员处理；充分保证了数据导入的可靠性，避免出现重复数据、错误格式的数据以及丢失数据等情况。

实施例6

本实施例在实施例2的基础上，所述步骤d和步骤e之间包括以下步骤：

如果接收到对分布式系统存储数据库HBase的数据查询指令，则调用Phoenix进行二级索引查询。利用分布式数据库HBase和Phoenix组合的形式进行查询数据，实现了二级索引来提升非主键字段查询的性能，优化主键均匀分布写的压力；Phoenix是一个HBase的开源SQL引擎(用于存储、处理和保护数据的服务)，可以使用标准的JDBC API代替HBase客户端API来创建表，插入数据，查询你的HBase数据，具有完整ACID事务功能的标准SQL和JDBC API的强大功能；不会降低HBase的效率，自身效率也不低。

实施例7

本实施例在实施例2的基础上，所述步骤e包括以下步骤：

根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算某一辆车在第i个站点的营收金额M_i：

其中，M_i为第i个站点的营收金额，P为票价，i为站点个数，P_i为第i个站点的票价，S为站点，S_i为第i个站点，S_up为某个站点的上车人数，S_(i-1)up为在第(i-1)个站点的上车人数，S_down为某个站点的下车人数，S_(i-1)down为在第(i-1)个站点的下车人数。

实施例8

本实施例在实施例7的基础上，所述步骤e还包括以下步骤：

计算某一辆车在从始发站到终点站的营收金额M_t以及一天的总营收金额R：

M_t＝∑M_i

R＝M_t*T

其中，M_i为第i个站点的营收金额，M_t为始发站到终点站的营收金额，R为一天的总营收金额，T为该辆车一天内从始发站发出的车次。

在上述技术方案中，根据车辆客流收集的数据，将每一趟的营收金额预测出来，具体预测方法是：

根据站点的上下车人数，假设靠前站点的上车人数在以次最靠近的站点下车，这样每个站点的营收相对就最大，但是这样对于整趟来说，最后的营收测最小，从而得到这趟车营收的最小值；

相反，根据站点的上下车人数，假设后一站点的下车人数全部来自于上一站点的上车人数，如果上一站点的人数不够，则从次靠前站点的上车人数中取，这样每个站点的营收相对就最小，但是这样对于整趟来说，最后的营收则最大，从而得到这趟车营收的最大值；

最后得到了一趟车辆的营收最大值和最小值，将其作为预测营收的区间；这样算出每趟车辆的预测营收预测值，将其加起来，得到每辆车每天的营收预测值，从而得到每条线路的每天营收预测值；

实现对公交车每天每趟车乃至每个站点营收情况的掌握和预测，且预测准确率高，便于公交公司以此预测数据进行规划、管理。

以上所述实施例仅表达了本发明的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。

Claims (8)

1.一种公交阶梯票价预测方法，其特征在于，包括以下步骤：

a、建立数据库Sqlserver；

b、采集传回数据，并将该传回数据传输至数据库Sqlserver中；传回数据包括车辆ID、关门时间、闭门时间、上车人数、下车人数以及开门地点GPS数据；

c、对传回数据进行清洗，生成站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表；

d、定期将数据库Sqlserver中的数据迁移至分布式系统存储数据库HBase中；

e、根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算出某一辆车一天的预测营收数据。

2.根据权利要求1所述的公交阶梯票价预测方法，其特征在于，还包括以下步骤：

将真实营收数据与预测营收数据进行比对评估，若比值在0.95-1.05之间，则该预测营收数据有效；否则，无效，重新进行预测营收数据计算。

3.根据权利要求1或2所述的公交阶梯票价预测方法，其特征在于，所述步骤a包括以下步骤：

优化数据库Sqlserver，若数据库Sqlserver中储存的数据量超过2G，则进行分区，创建分区索引。

4.根据权利要求1或2所述的公交阶梯票价预测方法，其特征在于，所述步骤d包括以下步骤：

d101、在Tomcat上设定定时代码，并于定时期间执行数据迁移导入；

d102、在数据导入过程中，判断上次导入是否成功，如果是，则进入步骤d104；如果否，则并进入步骤d103；

d103、加载上次导入所需数据，并执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则插入成功日志，清空数据库Sqlserver中的数据，并进入步骤d104；如果两次导入均失败，则插入错误日志，发出错误类型的通知，并进入步骤d104；

d104、执行本次导入，调用Sqoop将数据库Sqlserver中的数据导入分布式系统存储数据库HBase中。

5.根据权利要求4所述的公交阶梯票价预测方法，其特征在于，所述步骤d还包括以下步骤：

d105、判断本次导入是否成功，如果是，则进入步骤d107；如果否，则进入步骤d106；

d106、继续执行两次数据导入操作，判断是否导入成功，如果任意一次导入成功，则进入步骤d107；如果两次导入均失败，则插入错误日志，发出错误类型的通知；

d107、插入成功日志，并清空数据库Sqlserver中的数据。

6.根据权利要求1或2所述的公交阶梯票价预测方法，其特征在于，所述步骤d和步骤e之间包括以下步骤：

如果接收到对分布式系统存储数据库HBase的数据查询指令，则调用Phoenix进行二级索引查询。

7.根据权利要求1或2所述的公交阶梯票价预测方法，其特征在于，所述步骤e包括以下步骤：

根据站点信息表、线路信息表、车辆线路关联表、站点阶梯票价表、线路客流表和线路站点运距表，计算某一辆车在第i个站点的营收金额M_i：

其中，M_i为第i个站点的营收金额，P为票价，i为站点个数，P_i为第i个站点的票价，S为站点，S_i为第i个站点，S_up为某个站点的上车人数，S_(i-1)up为在第(i-1)个站点的上车人数，S_down为某个站点的下车人数，S_(i-1)down为在第(i-1)个站点的下车人数。

8.根据权利要求7所述的公交阶梯票价预测方法，其特征在于，所述步骤e还包括以下步骤：

计算某一辆车在从始发站到终点站的营收金额M_t以及一天的总营收金额R：

M_t＝∑M_i

R＝M_t*T

其中，M_i为第i个站点的营收金额，M_t为始发站到终点站的营收金额，R为一天的总营收金额，T为该辆车一天内从始发站发出的车次。