一种用于存储、查询交通数据的方法和系统与流程

1.本申请涉及大数据存储和查询技术领域，尤其涉及一种用于存储、查询交通数据的方法和系统。


背景技术：

2.目前交通大数据领域的卡口和门架过车记录是交通大数据的重要组成部分，记录了车辆在公路和高速上经过卡口和门架的时间和位置信息。通常整个省份或城市的采集设备会非常多，且每天经过卡口和门架的车辆数量也非常大。存储数据的交通大数据平台通常会存储大量的车辆过卡口和门架数据信息，因此对存储资源的要求比较高，导致成本较高。同时随着时间的累积，数据量越来越大，会导致对数据的查询和计算性能也随之下降。但是交通大数据平台上存储的这些信息在业务上的分析价值，会随时时间推移而逐步降低。
3.综上所述，需要提供一种能够降低存储成本和提高查询效率的用于存储、查询交通数据的方法和系统。


技术实现要素：

4.为解决以上问题，本申请提出了一种用于存储、查询交通数据的方法和系统。
5.第一方面，本申请提出了一种用于存储交通数据的方法，包括：
6.根据第一周期对接收到的实时交通数据，得到一级热数据，存储至热数据存储区中的临时分区；
7.根据第二周期，合并多个所述临时分区中的所述一级热数据，得到二级热数据，转移至热数据存储区中的第一分区，其中，所述第二周期为第一周期的第一倍数，被合并的所述一级热数据对应的所述临时分区的数量与所述第一倍数相等；
8.根据第三周期，合并多个所述第一分区中的所述二级热数据，得到三级热数据，转移至热数据存储区中的第二分区，其中，所述第三周期为第二周期的第二倍数，被合并的所述二级热数据对应的所述第一分区的数量与所述第二倍数相等；
9.根据第四周期，合并多个第二分区中的所述三级热数据，转移至冷数据存储区中，得到一级冷数据，其中，所述第四周期为第三周期的第三倍数，被合并的所述三级热数据的数量与所述第三倍数相等；
10.对所述一级冷数据进行格式转换和压缩，得到二级冷数据，存储在所述冷数据存储区中。
11.优选地，所述一级热数据、二级热数据和三级热数据均采用支持htap处理模式的存储格式，存储在所述热数据存储区中。
12.优选地，所述一级冷数据和二级冷数据均采用支持olap查询模式的存储格式，存储在所述冷数据存储区中。
13.优选地，所述热数据存储区为固态硬盘。
14.优选地，所述冷数据存储区为机械硬盘。
15.第二方面，本申请提出了一种用于查询交通数据的方法，所述交通数据根据上的一种用于存储交通数据的方法进行存储，包括：
16.接收查询请求，根据所述查询请求和元数据，查询目标交通数据的存储区域，将所述存储区域作为目标存储区域，所述目标存储区域包括热数据存储区和/或冷数据存储区；
17.采用大规模并发处理引擎从所述目标存储区域中查询目标交通数据。
18.优选地，采用大规模并发处理引擎从所述目标存储区域中查询目标交通数据，包括：
19.若所述目标储存区域只包括所述热数据存储区，则采用大规模并发引擎处理从所述热数据存储区中获取所述目标交通数据；
20.若所述目标储存区域只包括所述冷数据存储区，则采用大规模并发处理引擎从所述冷数据存储区中获取所述目标交通数据；
21.若所述目标存储区域包括所述热数据存储区和冷数据存储区，则采用大规模并发处理引擎，分别从所述热数据存储区中获取目标热数据，从所述冷据存储区中获取目标冷数据，合并所述目标热数据和所述目标冷数据作为所述目标交通数据。
22.第三方面，本申请提出了一种用于存储交通数据的系统，包括：
23.数据模块，用于根据第一周期对接收到的实时交通数据，得到一级热数据；根据第二周期，合并多个所述一级热数据，得到二级热数据，其中，所述第二周期为第一周期的第一倍数，被合并的所述一级热数据对应的临时分区的数量与所述第一倍数相等；根据第三周期，合并多个所述二级热数据，得到三级热数据，其中，所述第三周期为第二周期的第二倍数，被合并的所述二级热数据对应的第一分区的数量与所述第二倍数相等；根据第四周期，合并多个所述三级热数据，得到一级冷数据，所述第四周期为第三周期的第三倍数，被合并的所述三级热数据的数量与所述第三倍数相等；
24.数据压缩模块，用于对所述一级冷数据进行格式转换和压缩，得到二级冷数据；
25.热数据存储模块，包括的临时分区、第一分区和第二分区，用于存储一级热数据、二级热数据和三级热数据；
26.冷数据存储模块，用于存储一级冷数据和二级冷数据。
27.第四方面，本申请提出了一种用于查询交通数据的系统，包括：
28.目标存储区域查询模块，用于接收查询请求，根据所述查询请求和元数据，查询所述目标交通数据的存储区域，将所述存储区域作为目标存储区域，所述目标存储区域包括热数据存储区和/或冷数据存储区；
29.目标交通数据查询模块，用于采用大规模并发处理引擎从所述目标存储区中查询目标交通数据。
30.优选地，所述目标交通数据查询模块包括：
31.数据获取单元，用于根据所述目标储存区域，采用大规模并发处理引擎从所述热数据存储区中获取所述目标交通数据，或采用大规模并发处理引擎从所述冷数据存储区中获取所述目标交通数据，或采用大规模并发处理引擎，或分别从所述热数据存储区中获取目标热数据，从所述冷据存储区中获取目标冷数据；
32.数据合并单元，用于当所述目标存储区域包括热数据存储区和冷数据存储区时，
合并所述目标热数据和所述目标冷数据作为所述目标交通数据。
33.本申请的优点在于：通过依据第一周期、第二周期、第三周期和第四周期，依次对热数据存储区中的各分区合并，得到一级冷数据，移动至冷数据存储区，能够降低热数据存储区中的热数据存储量，从而减小热数据存储区所占资源的压力；对冷数据存储区中的一级冷数据进行格式转换和压缩，能够降低冷数据存储区中的冷数据存储量，从而减小冷数据存储区所占资源的压力；根据查询条件和元数据，判断目标交通数据的目标存储区域，使用大规模并发处理引擎从包括热数据存储区和/或冷数据存储区的目标存储区域中查询目标交通数据，能够提高查询效率。
附图说明
34.通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选事实方案的目的，而并不认为是对本申请的限制。而且在整个附图中，用同样的参考符号表示相同的部件。在附图中：
35.图1是本申请提供的一种用于存储交通数据的方法的步骤示意图；
36.图2是本申请提供的一种用于存储交通数据的方法的热数据存储区的示意图；
37.图3是本申请提供的一种用于存储交通数据的方法的冷数据存储区的示意图；
38.图4是本申请提供的一种用于查询交通数据的方法的步骤示意图；
39.图5是本申请提供的一种用于查询交通数据的方法的流程示意图；
40.图6是本申请提供的一种用于存储交通数据的系统的示意图；
41.图7是本申请提供的一种用于查询交通数据的系统的示意图。
具体实施方式
42.下面将参照附图更详细地描述本公开的示例性实施方式。虽然附图中显示了本公开的示例性实施方式，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
43.第一方面，根据本申请的实施方式，提出一种用于存储交通数据的方法，用于车载模块，如图1所示，包括：
44.s101，根据第一周期对接收到的实时交通数据，得到一级热数据，存储至热数据存储区中的临时分区；
45.s102，根据第二周期，合并多个临时分区中的一级热数据，得到二级热数据，转移至热数据存储区中的第一分区，其中，第二周期为第一周期的第一倍数，被合并的一级热数据对应的临时分区的数量与第一倍数相等；
46.s103，根据第三周期，合并多个第一分区中的二级热数据，得到三级热数据，转移至热数据存储区中的第二分区，其中，第三周期为第二周期的第二倍数，被合并的二级热数据对应的第一分区的数量与第二倍数相等；
47.s104，根据第四周期，合并多个第二分区中的三级热数据，转移至冷数据存储区中，得到一级冷数据，其中，第四周期为第三周期的第三倍数，被合并的三级热数据的数量与第三倍数相等；
48.s105，对一级冷数据进行格式转换和压缩，得到二级冷数据，存储在冷数据存储区中。
49.一级热数据、二级热数据和三级热数据均采用支持htap处理模式的存储格式，存储在热数据存储区中。一级冷数据和二级冷数据均采用支持olap查询模式的存储格式，存储在冷数据存储区中。热数据存储区为固态硬盘。冷数据存储区为机械硬盘。
50.由于对交通大数据场景下卡口和门架过车数据通常数据量大，并且数据实时写入吞吐量大，因此，传统大数据平台通常更适合处理t+1周期的大数据应用，而对数据的实时写入的支持较差。对于实时写入(t+0)的大数据场景，通常对硬件要求较高，需要较大的内存配置和ssd固定硬盘存储。本申请的实施方式通过对冷热数据采用不同的存储策略和存储介质，并使冷热数据存储格式可以兼容多种mpp引擎，实现对冷热数据的关联查询。
51.下面，对本申请实施例进行进一步说明。
52.首先需要根据数据的业务生命周期特征，合理的划分数据的热冷时间范围，划分热数据及冷数据。在此以第一周期为30分钟，第二周期1小时，第三周期为24小时，第四周期为6个月为例。
53.热数据的写入通过数据采集模块将车辆过卡口和门架数据实时写入到热数据存储程序中，存储介质适合使用ssd固态硬盘。
54.如图2所示，由于热数据是实时写入，并且写入量较大，因此在热数据写入的过程中，在大数据平台通常会产生大量的小文件(每次/每批写入通常就会生成一个小文件)。大量的小文件会影响磁盘io读取效率，并且在查询和计算时对磁盘产生巨大压力，因此需要对热数据进行合并，然而文件合并会产生系统卡顿。因此，需要对热数据按照数据特性进行分区。对于车辆过卡口和门架的数据，根据数据更新的时间频率，对热数据划分为两部分，临时分区和正式分区。设置热数据的临时分区数和正式分区数。正式分区可以分为两个部分，分别为第一分区和第二分区。其中，第一分区用于存储按小时合并的二级热数据；第二分区用于存储按天合并的三级热数据。其中，临时分区可以用于存储短时间内合并的一级热数据，如按30分钟合并的一级热数据。
55.在临时分区中，按照每30分钟为一个分区进行数据存储，即临时分区中包括多个30分钟分区，每个30分钟分区都存储不同的一级热数据，每一个小时将过去2个30分钟的分区进行一次合并，被合并的一级热数据形成二级热数据，将合并后得到的二级热数据迁移到第一分区，同时删除临时分区中的这2个30分钟的分区及其对应的一级热数据。
56.在正式分区中，保留最近48个小时的小时分区对应的二级热数据和按天分区对应的二级热数据。第一分区中包括多个1小时分区，每个1小时分区都存储不同的二级热数据。第二分区中包括多个24小时分区，每个24小时分区都存储不同的三级热数据。第一分区中，每24个小时合并一次过去24小时的小时分区，被合并的二级热数据形成二级热数据，合并后得到的三级热数据被迁移到用于按天存储的第二分区中。每48小时删除一次第一分区中保留超过48小时的分区及其对应的二级热数据。默认每天将累计超过6个月的第二分区中的三级热数据归档到冷数据存储区中，并删除存储(归档)至冷数据存储区中的按天分区及其对应的三级热数据。
57.对于第二分区中的三级热数据，根据数据的业务生命周期，定期将按第二分区合并，将被合并的三级热数据转换为一级冷数据，归档到冷数据存储区域中，然后将对应的热
数据存储区域的第二分区中的与转移后的三级热数据对应的第二分区进行删除。
58.如图3所示，由于冷数据存储的都是历史数据，且数据都是批量写入到冷数据存储，因此数据的变更频率较低，所以热数据和冷热数据通常为不同的存储格式，因此需要将作为一级冷数据转移至冷数据存储区域中的合并后的三级热数据先转换为对应冷数据存储区的存储格式，使三级热数据满足冷数据的存储方式，因此对进行格式转换后的一级冷数据采用列式存储。由于冷数据的访问频率和修改频率均较低，因此可以使用压缩比更高的压缩算法对每列的数据进行编码压缩，来减少对磁盘存储空间的占用，降低海量冷数据的硬件存储成本。因此，还需要对进行格式转换后的一级冷数据按照列的数据类型进行编码压缩，得到二级冷数据。由于冷数据的查询频率较低，也不需要频繁进行修改，且数据都是顺序批量写入，因此冷数据可以采用机械磁盘进行存储。冷数据和热数据一样采用的是分布式多副本存储，因此不需要搭建raid存储进行数据的备份。其中，格式转换方式包括：parquet和orc两种方式，可以从中任选其一作为冷数据存储区的转换方式。编码压缩方式包括：lzo和snappy两种方式，可以从中任选其一作为冷数据存储区的编码压缩方式。分区存储方式包括：三副本和纠删码两种方式，可以从中任选其一作为冷数据存储区的分区存储方式。
59.本申请的实施方式中，三级热数据迁移到冷数据存储区，通常是将按天分区的三级热数据归档到冷数据存储区进行存储，正常情况下每天归档一个按天分区的三级热数据。第一次进行三级热数据归档的时候，如果有历史数据，会一次归档n个按天分区的三级热数据。
60.第二方面，本申请提出了一种用于查询交通数据的方法，如图4所示，交通数据根据上述的一种用于存储交通数据的方法进行存储，包括：
61.s201，接收查询请求，根据查询请求和元数据，查询目标交通数据的存储区域，将存储区域作为目标存储区域，目标存储区域包括热数据存储区和/或冷数据存储区；
62.s202，采用大规模并发处理引擎从目标存储区域中查询目标交通数据。
63.采用大规模并发处理引擎从目标存储区域中查询目标交通数据，包括：若目标储存区域只包括热数据存储区，则采用大规模并发处理引擎从热数据存储区中获取目标交通数据；若目标储存区域只包括在冷数据存储区，则采用大规模并发处理引擎从冷数据存储区中获取目标交通数据；若目标存储区域包括热数据存储区和冷数据存储区，则采用大规模并发处理引擎，分别从热数据存储区中获取目标热数据，从冷据存储区中获取目标冷数据，合并目标热数据和目标冷数据作为目标交通数据。
64.下面，对本申请实施例进行进一步说明，如图5所示。
65.热数据存储区为采用ssd固态硬盘的kudu等适于htap处理模式的分布式存储，冷数据存储区为采用机械磁盘的hdfs等适于olap查询模式的分布式存储。热数据(一级热数据、二级热数据和三级热数据)存储于kudu等适于htap处理模式的分布式存储中，采用ssd固态硬盘进行物理存储；冷数据(一级冷数据和二级冷数据)存储于hdfs等适于olap查询模式的分布式存储中，采用机械磁盘进行物理存储。采用大规模并发处理引擎的查询目标交通数据的数据查询引擎采用impala或presto等大规模并发处理(massively parallel processing，mpp)引擎。元数据统一存储于hive中进行保存。hive是一种数据库技术，可以定义数据库和表以分析结构化数据。门架数据车辆数据、收费站信息、车辆信息、缴费信息
和时间信息都可以是hive中存储的元数据的一个字段。根据数据查询请求中的时间条件作为查询的判断依据。具体为采用大规模并发处理引擎从存储于hive中的元数据中的时间信息中获取目标交通数据所在的存储区域，作为目标存储区域，其中，目标存储区域包括热数据存储区和/或冷数据存储区中查询目标交通数据，获取到目标存储区域之后，当目标存储区域只包括热数据存储区范围时，数据查询引擎直接对kudu存储进行查询，从热数据中获取目标交通数据，返回数据。当目标存储区域只包括冷数据存储区范围时，数据查询引擎直接对hdfs存储上的数据进行查询，从冷数据中获取目标交通数据，返回数据。当目标存储区域包括热数据存储区和冷数据存储区时，数据查询引擎同时从kudu和hdfs上查询获取热数据和冷数据，在内存中对查询到的热数据和冷数据进行join关联操作，得到结果集，并将合并后的结果集作为返回数据。本申请实施方式使用的大数据存储与查询技术，可以使用但是不限于业内常用的开源hadoop大数据生态组件。
66.第三方面，本申请提出了一种用于存储交通数据的系统，如图6所示，包括：
67.数据模块101，用于根据第一周期对接收到的实时交通数据，得到一级热数据；根据第二周期，合并多个一级热数据，得到二级热数据，其中，第二周期为第一周期的第一倍数，被合并的一级热数据对应的临时分区的数量与第一倍数相等；根据第三周期，合并多个二级热数据，得到三级热数据，其中，第三周期为第二周期的第二倍数，被合并的二级热数据对应的第一分区的数量与第二倍数相等；根据第四周期，合并多个三级热数据，得到一级冷数据，第四周期为第三周期的第三倍数，被合并的三级热数据的数量与第三倍数相等；
68.数据压缩模块102，用于对一级冷数据进行格式转换和压缩，得到二级冷数据；
69.热数据存储模块103，包括的临时分区、第一分区和第二分区，用于存储一级热数据、二级热数据和三级热数据；
70.冷数据存储模块104，用于存储一级冷数据和二级冷数据。
71.第四方面，本申请提出了一种用于查询交通数据的系统，如图7所示，包括：
72.目标存储区域查询模块201，用于接收查询请求和元数据，查询目标交通数据的存储区域，将存储区域作为目标存储区域，目标存储区域包括热数据存储区和/或冷数据存储区；
73.目标交通数据查询模块202，用于采用大规模并发处理引擎从目标存储区中查询目标交通数据。
74.目标交通数据查询模块包括：
75.数据获取单元，用于根据目标储存区域，采用大规模并发处理引擎从热数据存储区中获取目标交通数据，或采用大规模并发处理引擎从冷数据存储区中获取目标交通数据，或采用大规模并发处理引擎，分别从热数据存储区中获取目标热数据，从冷据存储区中获取目标冷数据；
76.数据合并单元，用于当目标存储区域包括热数据存储区和冷数据存储区时，合并目标热数据和目标冷数据作为目标交通数据。
77.本申请的方法中，通过依据第一周期、第二周期、第三周期和第四周期，依次对热数据存储区中的各分区进行合并，得到一级冷数据，移动至冷数据存储区，能够降低热数据存储区中的热数据存储量，从而减小热数据存储区所占资源的压力；对冷数据存储区中的一级冷数据进行格式转换和压缩，能够降低冷数据存储区中的冷数据存储量，从而减小冷
数据存储区所占资源的压力；根据查询条件和元数据，判断目标交通数据的存储区域，使用大规模并发处理引擎从包括热数据存储区和/或冷数据存储区的目标存储区域中查询目标交通数据，能够提高查询效率和数据查询范围。相较于现有的数据存储方案，本申请的实施方式能够根据数据的业务生命周期特征，合理的划分数据的热冷时间范围，而非只是简单的按照数据的是时效性，只存储一段时间的热数据，而将冷热数据直接删除，并且，现有的数据存储方案即使保留冷数据，也是独立于热数据单独存储，无法同时对冷热数据进行关联查询。本申请实施方式使用的服务器硬件成本更低，尤其是存储成本大幅降低；支持同时查询冷数据和热数据，扩大了数据有效查询范围；解决了大数据平台t+0周期(实时)的频繁写入数据，产生大量小文件带来的文件合并压力。
78.以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。