一种基于SparkStreaming的快速实时预警方法与流程

一种基于spark streaming的快速实时预警方法
技术领域
1.本发明涉及智能交通控制技术领域，具体为一种基于spark streaming的快速实时预警方法。


背景技术：

2.截至2022年6月底，全国机动车保有量达4.06亿辆，其中汽车3.10亿辆；机动车驾驶人4.92亿人，其中汽车驾驶人4.54亿人。2022年上半年全国新注册登记机动车1657万辆，新领证驾驶人1103万人。每天实时产生海量庞杂、动态变化的交通数据。
3.同时基于交通管理的需求，需要快速查处各类交通事件，实现大范围车辆搜索和预警拦截，提高公路管理、路面管理能力。比如，需要在某个城市或者全国范围内实时查找和定位指定车辆，或者实时发现有涉牌、涉证行为嫌疑的车辆，然后追踪预警拦截这些车辆；而现有的用于交通数据计算的大数据计算方法，因为数据量和实时性的要求，导致对服务器的性能要求极高，进而导致成本过高。


技术实现要素：

4.为了解决现有的用于交通数据计算的大数据计算方法，对服务器的性能要求过高的问题，本发明提供一种基于spark streaming的快速实时预警方法，其可以在完成计算需求的基础上，降低对服务器性能的要求，进而降低系统成本。
5.本发明的技术方案是这样的：一种基于spark streaming的快速实时预警方法，其特征在于，其包括以下步骤：
6.s1：确定需要实时处理的车辆轨迹数据，记作待处理车辆轨迹数据；
7.s2：在kafka系统中，为所述待处理车辆轨迹数据建立一个过车topic，
8.将所述待处理车辆轨迹数据按照车牌号码分别存储到所述过车topic的不同存储分区中；
9.s3：基于spark streaming分布式流式处理框架将预警比对处理程序分配到各个工作节点，单个工作节点启动执行器executor来运行所述预警比对处理程序；
10.所述工作节点和所述执行器executor的关系为1:n，n为大于等于1的正整数；
11.s4：所述预警比对处理程序确定进行实时计算的所有实时监测事件，以及每个所述实时监测事件中使用到的所有基础数据库数据和嫌疑车辆黑名单数据；
12.所述基础数据库为在所述实时监测事件中需要比对车辆信息时用到的基础车辆信息所在的数据库；
13.所述嫌疑车辆黑名单中记载了在所述实时监测事件中需要找到并进行预警的嫌疑车辆；
14.s5：每个所述预警比对处理程序中包括所有并行处理的所述实时监测事件；
15.每个所述实时监测事件分别对应一个预警规则和一个实时比对线程thread；
16.每个所述实时监测事件对应一个预警缓存队列作为数据输出，所述实时比对线程
thread找到符合条件的所述待处理车辆轨迹数据后，推送到所述预警缓存队列中；
17.s6：构建过车缓存队列消费线程和预警缓存队列消费线程；
18.s7：每个所述预警比对处理程序启动后，并获取本次计算的所述实时计算车辆数据对应的车牌号码范围，记作：车牌提取范围；
19.按照所述车牌提取范围，在所述基础数据库和所述嫌疑车辆黑名单中提取对应车牌号码范围的数据，分别记作：比对基础数据、比对黑名单数据；
20.s8：所述预警比对处理程序按照预设的数据提取量，从所述过车topic中获取参与本次计算的数据，记作：实时计算车辆数据；将所述实时计算车辆数据封装成离散数据流dstream结构，传递给所述预警比对处理程序中所有的所述实时比对线程thread中进行比对计算；
21.所述实时比对线程thread按照所述监测事件对应的所述预警规则，将输入的所述待处理车辆数据与所述比对基础数据和所述比对黑名单数据进行碰撞比对，找到符合预警条件的待处理车辆数据推送到预警缓存队列；
22.s9：所述预警缓存队列消费线程从所述预警缓存队列中读取数据发布预警信息。
23.其进一步特征在于：
24.其还包括步骤s10：保存每一次参与计算的所述实时计算车辆数据对应的过车topic分区p的偏移量offset；
25.步骤s2中，所述待处理车辆轨迹数据的存储方法，具体包括以下步骤：
26.a1：在kafka系统中，为所述待处理车辆轨迹数据建立一个所述过车topic；
27.设：所述过车topic中包括的分区总数为z，z为自然数；
28.a2：逐一取出每一份所述待处理车辆轨迹数据，确认是否有车牌号码；
29.如果没有车牌号码，则实施步骤a3，计算对应的存储分区；
30.否则，将车牌号码记作：待计算车牌号码，实施步骤a4；
31.a3：基于随机函数，计算得到一个位于[0，(z-1)]之间的整数，即为所述待处理车辆轨迹数据对应的存储分区对应的分区号码p，p为小于等于z的自然数；
[0032]
执行步骤a5；
[0033]
a4：基于哈希函数计算所述待计算车牌号码对应的哈希值h，所述待处理车辆轨迹数据对应的存储分区对应的分区号码p为：
[0034]
p＝h mod z；
[0035]
a5：将所述待处理车辆轨迹数据对应的文本数据存储到对应的所述存储分区p中；
[0036]
所述执行器executor的个数大于等于1；
[0037]
所述存储分区与所述执行器executor的对应关系为：m：1，其中m为大于等于1的自然数。
[0038]
本发明提供的一种基于spark streaming的快速实时预警方法，将待处理车辆轨迹数据按照车牌号码分别存储到不同的存储分区中，将所有实时监测事件分别建立一个实时比对线程thread，每次将待处理车辆轨迹数据同时送入到所有的实时比对线程thread中并行计算，提高了处理效率；同时，因为待处理车辆轨迹数据是按照车牌号码存储的，每次计算时，车缓存队列消费线程将数据送入存储分区对应的过车数据缓存队列中，在每个实时比对线程thread中，因为是按照需要比对的待处理车辆轨迹数据对应的车牌范围从基础
数据库和嫌疑车辆黑名单中提取对应车牌号码范围的数据，所以数据对比查找的命中率会提高，极大的提高了系统的计算效率，同时每个thread中每次需要计算的数据量有限，进一步的提高了计算速度。基于本发明技术方案，不但能满足预警的实时性的要求，而且降低了对服务器的性能要求，同时，本方法因为提高服务器资源使用率和并发处理能力，所以降低了系统成本。
附图说明
[0039]
图1为本发明中基于spark streaming实现的实时预警方法流程图；
[0040]
图2为本发明执行器executor中实时比对线程thread中的流程图；
[0041]
图3为本发明提供快速实时推送预警数据的实施例的流程图；
[0042]
图4为实施例中卡口设备和车辆的位置关系示意图；
[0043]
图5为实施例中，过车topic与3个存储分区的逻辑关系示意图；
[0044]
图6为实施例中，执行器executor基于offset读取数据的过程示意图。
具体实施方式
[0045]
如图1～图3所示，本发明包括一种基于spark streaming的快速实时预警方法，其特征在于，其包括以下步骤：
[0046]
s1：确定需要实时处理的车辆轨迹数据，记作待处理车辆轨迹数据。
[0047]
具体实施时，获取待处理车辆轨迹数据包括三个过程：数据采集、数据清洗和数据汇聚。
[0048]
基于统一的数据格式要求，由前端卡口系统、电子警察等设备负责采集过车文本数据及图片，完成数据采集过程。基于现有技术处理缺失字段、补全默认值、校验号牌号码规则，完成数据清洗过程。由于数据采集的速度和数据处理的速度不同步，会造成数据的不断积压，后端业务数据推送延时，因此添加kafka 消息中间件作为缓冲，实现数据汇聚。根据分配策略将消息加密压缩后发送到对应的分区，避免kafka发生数据倾斜现象。
[0049]
如图4所示，有6辆车分别经过卡口1、卡口2两个点位。卡口采集到的过车文本数据及图片，对应 12条过车数据如下表1所示：
[0050]
表1：卡口采集的过车数据实施例
[0051][0052]
经过数据清洗，处理缺失字段、补全默认值、校验号牌号码规则。表1中的数据，对号牌号码为空的，补全为
“‑”
,号牌种类为空的补全为”41”(41指无号牌)，具体参照下面表2：
[0053]
表2：清洗后的数据实施例：
[0054][0055]
s2：在kafka系统中，为待处理车辆轨迹数据建立一个过车topic，
[0056]
将待处理车辆轨迹数据按照车牌号码分别存储到过车topic的不同存储分区中。
[0057]
步骤s2中，待处理车辆轨迹数据的存储方法，具体包括以下步骤：
[0058]
a1：在kafka系统中，为待处理车辆轨迹数据建立一个过车topic；
[0059]
设：过车topic中包括的分区总数为z，z为自然数；
[0060]
a2：逐一取出每一份待处理车辆轨迹数据，确认是否有车牌号码；
[0061]
如果没有车牌号码，则实施步骤a3，计算对应的存储分区；
[0062]
否则，将车牌号码记作：待计算车牌号码，实施步骤a4；
[0063]
a3：基于随机函数，计算得到一个位于[0，(z-1)]之间的整数，即为待处理车辆轨迹数据对应的存储分区对应的分区号码p，p为小于等于z的自然数；
[0064]
执行步骤a5；
[0065]
a4：基于哈希函数计算待计算车牌号码对应的哈希值h，待处理车辆轨迹数据对应的存储分区对应的分区号码p为：
[0066]
p＝h mod z；
[0067]
a5：将待处理车辆轨迹数据对应的文本数据存储到对应的存储分区p中。
[0068]
如：将z设置为10；则，使用现有的随机函数，为每个无号码车牌计算得到一个位于
[0，9]之间的整数，作为无号牌数据的存储分区号码p，确保无号牌的车辆能够均匀地存储在过车topic的存储分区中。在实际应用中，所有的无号码车牌在业务逻辑中一般进行无号牌车辆预警。本实施例中，具体的计算结果如下面表3示：
[0069]
表3基于车牌计算分区p的实施例
[0070]
号牌号码分区总数z哈希值h分区p无牌10-随机数[0-9]苏a111110337977苏a111210337988
[0071]
将表2中数据存储到过车topic中，本实施例中，z＝3；根据车辆轨迹文本数据中的号牌号码字段，计算对应的分区号，相应车辆轨迹文本数据就存储在对应的分区。参照表4内容：
[0072]
表4待处理车辆轨迹数据存储过车topic中的实施例：
[0073][0074]
汇聚后的数据，在kafka系统中的逻辑示意图，如图5所示，过车topic中包括3个存储分区：分区0、分区1和分区2，待处理过程数据按照车牌号码分别存储到过车topic的3个存储分区中；读取时，根据每个待处理车辆轨迹数据对应的偏移量offset读取数据。
[0075]
s3：如图1所示，基于spark streaming分布式流式处理框架将预警比对处理程序分配到各个工作节点，单个工作节点启动执行器executor来运行预警比对处理程序；
[0076]
工作节点和执行器executor的关系为1:n，n为大于等于1的正整数。
[0077]
具体实施时，执行器executor的个数大于等于1；存储分区与执行器executor的对应关系为：m：1，其中m为大于等于1的自然数；具体的执行器executor的个数和存储分区的
对应关系根据服务器个数以及计算需求进行确定。
[0078]
s4：预警比对处理程序确定进行实时计算的所有实时监测事件，以及每个实时监测事件中使用到的所有基础数据库数据和嫌疑车辆黑名单数据；
[0079]
基础数据库为在实时监测事件中需要比对车辆信息时用到的基础车辆信息所在的数据库；
[0080]
嫌疑车辆黑名单中记载了在实时监测事件中需要找到并进行预警的嫌疑车辆。
[0081]
s5：每个预警比对处理程序中包括所有并行处理的实时监测事件；
[0082]
每个实时监测事件分别对应一个预警规则和一个实时比对线程thread；
[0083]
每个实时监测事件对应一个预警缓存队列作为数据输出，实时比对线程thread找到符合条件的待处理车辆轨迹数据后，推送到预警缓存队列中。
[0084]
s6：构建过车缓存队列消费线程和预警缓存队列消费线程。
[0085]
s7：每个预警比对处理程序启动后，并获取本次计算的实时计算车辆数据对应的车牌号码范围，记作：车牌提取范围；
[0086]
按照车牌提取范围，在基础数据库和嫌疑车辆黑名单中提取对应车牌号码范围的数据，分别记作：比对基础数据、比对黑名单数据。
[0087]
s8：预警比对处理程序按照预设的数据提取量，从过车topic中获取参与本次计算的数据，记作：实时计算车辆数据；将实时计算车辆数据封装成离散数据流dstream结构，传递给预警比对处理程序中所有的实时比对线程thread中进行比对计算；
[0088]
实时比对线程thread按照监测事件对应的预警规则，将输入的待处理车辆数据与比对基础数据和比对黑名单数据进行碰撞比对，找到符合预警条件的待处理车辆数据推送到预警缓存队列。
[0089]
具体实施时，采用kafka简单的consumer api方式来读取数据。kafka作为数据源，整合spark streaming 和kafka，启用批量消费消息列表batch方式传递数据，将batch数据的offsetrange(topic、partition、起始地址from offset、终止地址until offset)元数据传送给spark driver之后，batch任务被触发，由executor使用pull模式直接拉取相应offset range范围的数据，即图1中标记的direct模式，将数据同时并行送入executor 中，开始业务处理，快速实时比对分析嫌疑车辆。
[0090]
附图5所示的实施例中，基于spark streaming过车消费任务，配置3个executor(executor1～3)来消费处理过车topic的3个分区数据。executor与partition是1:1模式消费。
[0091]
读取数据时，获取分区partition的消费偏移量offset，即：上一个批次数据处理完保存的最新offset；
[0092]
如果偏移量offset》0，表示需要从存储分区中段部位开始取数据，则从指定偏移量offset开始拉取分区 partition数据得到数据流dstream；如果不是，表示，需要从存储分区的最开始拉去数据，则从分区partition 最新的偏移量offset开始拉取partition数据得到数据流dstream。具体实施步骤，参照consumer api读取方法。
[0093]
本实施例中，指定偏移量offset都为大于0的数字，具体参照附图6，executor1拉取分区0(偏移量859-869) 的数据，executor2拉取分区1(偏移量866-869)的数据，executor3拉取分区2(偏移量867-869)的数据。
[0094]
实时比对线程thread按照监测事件对应的预警规则，将输入的待处理车辆数据与比对基础数据和比对黑名单数据进行碰撞比对，找到符合预警条件的待处理车辆数据推送到预警缓存队列。
[0095]
系统运行时，预警比对处理程序启动后，首先判断各类基础数据是否加载，如果没有，则加载牌号码范围的相应数据到内存，再判断各类嫌疑车辆黑名单库是否加载，如果没有，则加载牌号码范围的相应数据到内存。然后，判断过车缓存队列消费线程和判断预警缓存队列消费线程是否启动，如果没有则开启相应线程。确保都启动了之后，遍历处理dstream数据，比对分析嫌疑车辆。
[0096]
本实施例中，基础数据库包括：部门、道路、人员、卡口、系统内部参数等数据库；嫌疑车辆黑名单库包括：逾期未年检、逾期未报废、应处理但未处理、本地及上级搜索数据等数据库。
[0097]
如图2所示，比对过程中，解密后的待处理车辆数据被推送到过车缓存队列后，实时比对线程thread (图中标记为：比对线程1～比对线程n)将数据批量写入预先在hbase中构建的过车表中，每个thread 根据自身的预警规则，开启预警实时比对线程。如果满足预警条件，thread将预警数据推送到预警缓存队列，即，thread将符合条件的预警数据批量写入hbase预警表。不满足预警条件的数据则直接结束比对。
[0098]
s9：与实时比对线程thread的操作同时，预警缓存队列消费线程实时地从预警缓存队列中读取数据，将预警信息发布到redis。
[0099]
如图3所示，在应用端，应用端后台订阅redis预警主题的数据，并基于websocket实时推送至网页端，确保能够将预警数据实时发布，满足预警的实时性的要求。
[0100]
本实施例中，每一个预警比对处理程序都会遍历处理dstream数据中的每条过车文本数据进行比对。如对下面表5的待处理车辆轨迹数据的文本数据，假设其存在需要预警的问题：
[0101]
表5待处理车辆轨迹数据的文本数据实施例
[0102][0103]
其在实时比对线程thread中的比对过程为：
[0104]
thread1、比对未年检，车牌沪*a333d在逾期未年检黑名单库中存在，生成一条逾期未年检预警。
[0105]
thread2、比对未报废，车牌沪*a333d在逾期未报废黑名单库中存在，生成一条逾期未报废预警。
[0106]
thread3、比对红眼客车，判断沪*a333d的机动车信息是旅游客运，但经过时间不在凌晨2点-5点，不生成红眼客车预警。
[0107]
thread4、比对疲劳驾驶，拉取沪*a333d前4小时的轨迹，判断是否连续行驶超过4小时，满足生成疲劳驾驶预警。
[0108]
thread5、比对本地及上级搜索数据，该车在搜索数据中存在则生成相应搜索类型(来源于搜索数据的字段)的预警。
[0109]
thread6、........
[0110]
s10：预警比对处理程序每处理一批数据，都会保存每一次参与计算的实时计算车辆轨迹数据对应的过车topic分区的偏移量offset；以便下一批数据处理可以从当前批次的数据offset之后开始拉取数据，进而保证数据处理过程中零丢失，通过对offset的保存，确保每个数据都能够被消费一次且只能消费一次。
[0111]
使用本发明的技术方案后，能够实时地处理过车轨迹数据，具有高吞吐量和容错性，能够准确的实时地进行嫌疑车辆的预警。本发明技术方案基于spark streaming框架进行数据批处理，spark streaming是粗粒度的准实时处理框架，一次读取完或异步读完之后处理数据，且其计算可基于大内存进行，因而具有较高的吞吐量。同时，业务处理过程中，从过车topic中获取数据时，会拉取偏移量offset的数据，在实时比对线程thread中数据处理完成后，offset信息被可靠地存储。一旦因意外发生处理失败，重新恢复时可以直接读取这些偏移量信息，保证数据处理过程中零丢失，消费一次且仅消费一次。比对分析嫌疑车辆过程中，在预警比对处理程序中，采用多线程比对，保证每一类嫌疑预警比对逻辑互不影响，预警数据写入 hbase和发布redis采用异步方式处理，保证一旦发现一条预警，就能实时推送至应用端。