基于spark的车辆分析

自2012年以来,公安部交通管理局在全国范围内推广了机动车缉查布控系统(简称卡口系统),通过整合共享各地车辆智能监测记录等信息资源,建立了横向联网、纵向贯通的全国机动车缉查布控系统,实现了大范围车辆缉查布控和预警拦截、车辆轨迹、交通流量分析研判、重点车辆布控、交通违法行为甄别查处及侦破涉车案件等应用。在侦破肇事逃逸案件、查处涉车违法行为、治安防控以及反恐维稳等方面发挥着重要作用。

随着联网单位和接入卡口的不断增加,各省市区部署的机动车缉查布控系统积聚了海量的过车数据。截至目前,全国32个省(区、市)已完成缉查布控系统联网工作,接入卡口超过50000个,汇聚机动车通行数据总条数超过2000亿条。以一个中等规模省市为例,每地市每日采集过车信息300万条,每年采集过车信息10亿条,全省每年将汇聚超过200亿条过车信息。如何将如此海量的数据管好、用好成为各省市所面临的巨大挑战。

随着车辆网以及汽车卡口应用的不断扩大,车辆数据的不断积累。对于原始数据的存储、处理、查询是一个很大的考验,为此我们需要一个能实时处理、多维度查询的分布式计算的平台。

一、   关键需求分解

1.   车辆轨迹查询

能够根据输入的车牌号,或通过车牌号模糊查询对车辆进行状态查询、订单轨迹追踪。过车记录查询,过车轨迹查询,落脚点分析,进行轨迹回放。

2.   地理位置检索

能够根据经纬度坐标快速的进行经纬度的过滤,如指定一个坐标,快速圈定周边10公里内的车辆。

3.   多维碰撞, 多维度查询

要求可以有5个条件的维度查询,最常用的是时间,终端号,类型。

可以根据多个维度进行任意条件的组合过滤,进行数据碰撞。

也可以根据多个地理坐标进行车辆碰撞分析。

4.   车辆出行规律分析,

可以按照一辆车,或一批车辆进行统计分析,了解车辆的出行规律,出行时间,频繁出入地点。

5.   出行规律异常车辆分析

选定某一区域的,周边陌生人/车的识别。出行规律异常的人/车识别。

6.   伴随分析

人车轨迹拟合,判断是否有代驾行为,有尾随,盯梢识别。

7.   数据碰撞分析

能够根据根据多个地理位置以及时间进行数据碰撞,连环时间进行数据碰撞分析。

8.   重点车辆分析

根据统计一定区域范围内的客运、危险品运输、特殊车辆等重点车辆通行数量,研判发现通行规律。对在路段内行驶时间异常的车辆、首次在本路段行驶的重点车辆、2到5点仍在道路上行驶的客运车辆等进行预警提示。

9.   车辆出入统计分析

挖掘统计一段时间内在某一个区域内(可设定中心城区、地市区域、省市区域、高速公路等区域)、进出区域、主要干道的经常行驶车辆、“候鸟”车辆、过路车辆的数量以及按车辆类型、车辆发证地的分类统计。

二、   关键技术能力要求

1.   数据规模-数据节点数

能够承载日均数百亿条增量,数据要可以长久保留

也要支撑未来三到五年,每天百亿,甚至数千亿条数据增量。

每个数据节点每天能处理20亿的数据量。

2.   查询与统计功能灵活性

根据不同的厂商,车型,往往在逻辑上有较大的区别,他们业务的不同查询逻辑也会有较大的区别,故一个查询系统要求非常灵活,可以处理复杂的业务逻辑,算法,而不是一些常规的简单的统计。

能支持复杂SQL

当业务满足不了需求的时候可以拓展SQL,自定义开发新的逻辑,udf,udaf,udtf。

要能支持模糊检索

对于邮箱、手机号、车牌号码、网址、IP地址、程序类名、含有字母与数字的组合之类的数据会匹配不完整,导致数据查不全,因分词导致漏查以及缺失数据,对于模糊检索有精确匹配要求的场景下,业务存在较大的风险

多维分析多维碰撞

要求可以有5个条件的维度查询,最常用的是时间,终端号,类型。

3.   检索与并发性能

每次查询在返回100条以内的数据时能在1秒内返回,并发数不少于200(6个节点以内)。对于并发数要做到随着节点数的增加可以按比例增加。

4.   数据导入与时效性

对数据时效性要求较高,要求某一车辆在经过产生数据后,可达到分钟级别内系统可查可分析。对检索性能要求很高,以上典型需求均要求能够在秒级内返回结果及明细。

采用SQL方式的批量导入,也要支持kafka的流式导入

5.   稳定性-与单点故障

易于部署,易于扩容,易于数据迁移;

多数据副本保护,硬件不怕硬件损坏;

服务异常能自动检测及恢复,减轻运维人员经常需要半夜起床的痛苦;

系统不能存在任何单点故障,当某个服务器存在问题时不能影响线上业务。

数据过百亿后,不能频繁的OOM,也不能出现节点调片的情况。

系统出现异常后,可以自动侦探服务异常,并自动重启恢复服务,不能每次调片都要运维    人员半夜去机房重启。需要服务有自动迁移与恢复的特性,大幅减少运维人员驻场的工作量。

提供了导入与查询的限流控制,也提供了过载保护控制,甚至在极端场景提供了有损查询与有损服务

6.   要有较高的排序性能

排序可以说是很多日志系统的硬指标(如按照时间逆序排序),如果一个大数据系统不能进行排序,基本上是这个系统属于不可用状态,排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark,还是impala,hive,总之排序是必不可少的,排序的性能测试也是必不可少的。

7.   用户接口

尽量是SQL接口。如果是程序接口学习成本与接入成本均较高。

8.   方便与周边系统的导入导出

能与现有的常见系统如hadoop,hive ,传统数据库,kafka等集成,方便数据导入导出。

支持原始数据的任意维度导出

可以全表,也可以通过过滤筛选局部导出

支持数据经过各种组合计算过滤后的导出

可以将Y多个表与其他系统的多个表,进行组合筛选过滤计算后在导出

可以将多个数据从一张表导入到、另外一张表

可以将数据导出到别的系统里面(如hive,hbase,数据库等)

也可以将其他系统的数据导入到当前系统里面。

可以导出成文件,也可以从文件导入。

可以从kafka流式导入,也可以写插件,导出到kafka。

9. 数据存储与恢复

数据不能存储在本地磁盘,迁移难,恢复也难。

1).磁盘读写没有很好的控速机制,导入数据没有良好的流量控制机制,无法控制流量,而生产系统,磁盘控速与流量控速是必须的,不能因为业务高峰对系统造成较大的冲击,导致磁盘都hang住或挂掉。

2).本地硬盘局部坏点,造成局部数据损坏对于系统来说可能无法识别,但是对于索引来说哪怕是仅仅一个byte数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉ÿ

  • 5
    点赞
  • 32
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值