基于spark的车辆分析

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

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

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

基于spark的车辆分析_第1张图片

基于spark的车辆分析_第2张图片

一、   关键需求分解

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数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉,但是本地磁盘不能及时的发现并修正这些错误。

3).数据存储在本地磁盘,一旦本地将近20T的存储盘损坏,需要从副本恢复后才能继续服务,恢复时间太长。

要将数据存储在HDFS之上

1).基于HDFS做了磁盘与网络做了读写控速逻辑。

2).磁盘局部坏点hdfs配有crc32校验,有坏点会立即发现,并不影响服务,会自动切换到没有坏点的数据继续读取。

3).本地磁盘损坏,HDFS自动恢复数据,不会中断读写,不会有服务中断。

10. 数据迁移

不能采取这样的方案:

夸机房搬迁机器,不能让运维人员细心的进行索引1对1复制,这种搬迁方案往往要数星期,且非常容易出错。

迁移过程中为了保证数据的一致性,需要中断服务或者中断数据的实时导入,让数据静态化落地后不允许在变化后,才能进行迁移,这种方案业务中断时间太久。

要采取这样的迁移方案

1.hdfs通过balance自动迁移数据。

2.可以控制迁移过程中的带宽流量。

2.迁移过程中不中断服务,hdfs扩容与移除机器也对服务没影响。

11. 增加主备kafka

采用的是KAFKA主备设置,当主个KAFKA出现问题时会自动切换到备KAFKA,不影响线上业务。

12. 可扩展性-预警与在线扩容

当系统存储出现瓶颈时能及时报警,可容易的对存储进行扩容和数据均衡。在扩容时可以在线扩容。

13. 系统监控

有成熟的系统存储监控平台,可以对平台的运行状态进行实时监控,一旦出现问题可以及时告知监控人员.

 

一、   业界现有方案—优缺点分析

 

1.  开源大数据系统解决方案(Hadoop、Spark、Hive、Impala)

数据规模-数据节点数 基于HDFS之上,数据可无限拓展,存储PB级的数据很轻松。
查询与统计功能灵活性 1.SQL支持较为齐全。

2.与周边系统的集成非常方便,数据导入导出灵活。

3.支持JDBC方式,可以与常见的报表系统无缝集成

检索与并发性能 × 该类系统并非为即席查询而设计,比较适合离线分析,通常来说一个HiveSQL运行时间从几分钟到几小时不等,如果是百亿规模的数据分析时间可能会达到数个小时,如果以现有XX部门的预算来看,可能需要数天的时间,究其根本原因是该类系统是采用暴力扫描的方式,即如果是100亿条数据,也是采用从头遍历到末尾的方式扫描,性能可想而知,

基本无并发性可言。单并发就需要数小时。

数据导入与时效性 × HDFS的特性导致数据延迟较大,常规应用均是T+1数据,即延迟一天。
稳定性-与单点故障 无单点故障,比较完善
排序性能 × 采用暴力排序方式,业界第一腾讯采用512台机器,也是90多秒响应
用户接口 采用hive jdbc接口,目前hive为大数据SQL的即席标准
方便与周边系统

的导入导出

由于采用了hive接口,生态圈均基于该生态圈开发,与周围生态系统集成非常方便,有一系列的生态工具可用,可用与常见的系统集成
数据存储与恢复 hadoop的长项,硬件损坏,机器宕机后可自动迁移任务,不需要人工干预,中间不影响服务。

1.从一开始设计之初,Hadoop即假设所有的硬件均不可靠,一旦硬件损坏,数据不会丢失,有多份副本可以自动恢复数据。

2.数据迁移以及机器扩容有比较完备的方案,中间不停服务,动态扩容。

数据迁移
增加主备kafka × hive不能对接kafka
预警与在线扩容 业界有完完备的方案
系统监控 hdp有完完备的方案

2.  流计算系统(Storm、Spark Streaming)

数据规模-数据节点数 数据规模可随节点拓展
查询与统计功能灵活性 × 无法查看明细数据,只能看特定粒度的汇总结果,而过车记录是无法先计算出来的,即无法预知那个车有可能会犯罪,那个车会出事故,故无法预计算。
检索与并发性能 1.预先将需要查询的数据计算好,查询的时候直接访问预计算好的结果,性能非常好。

2.预计算完毕的结果集存储在HBase或传统数据库里,因数据规模并不大故并发性比较好。

数据导入与时效性 时效性非常好,一般与Kafka采用消息队列的方式导入,时效性可达几秒可见。
稳定性-与单点故障 无单点故障,比较完善
排序性能 预计算的方式,排序结果预先算好,性能比较好
用户接口 × java接口,有独立的API,需要写类似mapreduce的程序
方便与周边系统

的导入导出

× 比较难,需要单独独立开发对接程序
数据存储与恢复 损坏的机器会自动摘除,进行会自动迁移,服务不中断。

 

数据迁移 数据迁移,扩容,容灾均有完善的方案,Storm的扩容需要简单的Rebanlance即可。
增加主备kafka 可以支持
预警与在线扩容 有完完备的方案
系统监控 有完完备的方案

 

3.  全文检索系统(Solr、ElasticSearch)

数据规模-数据节点数 × 1.典型使用场景在千万级别,如果给予较大内存,数据量可上亿。

2.本身系统内存的限定,百亿以上将会是巨大的挑战-除非是512G内存的机器,弄个20~30台左右,且是数据总量百亿,而不是每天百亿。

查询与统计功能灵活性 × 1.为搜索引擎的场景而生,分析功能较弱。只有最简单的统计功能,无法满足过车记录复杂的统计分析需求,无法支撑复杂SQL,多表关联,嵌套SQL甚至自定义函数等功能。

2.与周边系统的集成麻烦,数据导入导出太麻烦,甚至不可行,第三方有SQL引擎插件,但均是简单SQL,且由于Merger server是单节点的问题,很多SQL的查询性能很低,不具备通用性。

3.无法与常见的支持jdbc标准的报表系统集成,定制开发代价较大。

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

5. 基于lucene的分词来实现,但并不考虑单词的匹配顺序,也不保证匹配词语的连续性,中间可以穿插其他单词。

6.solr与es中不支持多列的group by与统计(原因为无法交叉),所谓的实现是通过单列group by后 进行的笛卡尔及,按照每个单元格重新进行的查询。

检索与并发性能 1.采用倒排索引,直接根据索引定位到相关记录,而不需要采用全表暴力扫描的方式,检索查询性能特别高。

2.在千万级别以下,并且给予较多内存的情况下,并发情况很好。

数据导入与时效性 × 1.支持实时导入,在千万数据规模下导入性能较好。

2.数据过亿后,生产系统实时导入经常会出现OOM,以及CPU负载太高的问题,故过亿数据无法实时导入数据,一般过百亿的系统均采用离线创建索引的方式,即数据时效性延迟一天。

3.没有良好的合并控制策略,系统会发生阶段性(几分钟)的负载极高的情况(索引合并),此时系统资源占用特别高,前台查询响应速度极慢。

稳定性-与单点故障 × 1.数据规模一旦过百亿,就会频繁的出现OOM,节点调片的情况。

2.一旦调片后无法自动恢复服务,需要运维人员去重启相关服务。

3.系统无过载保护,经常是一个人员做了一个复杂的查询,导致集群整体宕机,系统崩溃。

lucene在索引合并过程中,每进行一次commit都要进行一次全范围的ord关系的重新映射,数据规模小的时候整个索引文件的映射还没什么,但是当数据量达到亿级别,甚至百亿级别后,这种映射关系会占用超多的CPU、内存、硬盘资源,所以当数据量过亿后,solr与Es在数据比较大的情况下,实时索引几乎是不可能的,频繁的ord关系映射,会让整个系统不可用。

排序性能 × 采用暴力全表遍历的方式排序,性能较差,经常因为排序导致整个系统瘫痪。

采用lucene的Sort接口实现,本质是借助docvalues的暴力扫描,如果数据量很大排序过程耗费非常多的内存与IO,并且排序耗时很高。

用户接口 × 采用java API的方式,用户学习成本高。

因不是通用的通讯协议,与其他大数据系统集成对接麻烦。

方便与周边系统

的导入导出

× 比较难,需要单独独立开发对接程序,

数据如若想导出到其他系统很难,超过百万级别的导出基本是不可行的,没有成型的高可用的导出方案。

全量数据导出基本是不可能的,更别谈经过多表复杂运算后的导出了

 

数据存储与恢复 × 索引存储在本地硬盘,恢复难

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

2.本地硬盘局部坏点,造成局部数据损坏对于lucene来说无法识别,但是对于索引来说哪怕是仅仅一个byte数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉,但是solr与es不能及时的发现并修正这些错误。

3.数据存储在本地磁盘,一旦本地将近20T的存储盘损坏,需要从副本恢复后才能继续服务,恢复时间太长。

数据迁移 × 1.如若夸机房搬迁机器,需要运维人员细心的进行索引1对1复制,搬迁方案往往要数星期,且非常容易出错。

2.迁移过程中为了保证数据的一致性,需要中断服务或者中断数据的实时导入,让数据静态化落地后不允许在变化后,才能进行迁移。

增加字段 支持
增加主备kafka × 不支持,需要业务单独开发导入api
预警与在线扩容 × 分片数不可以随意更改,如果要扩分片数,需要重建全部的历史索引,也就是传说的reindex,另外出现问题后无法自动恢复服务,需要运维人员去现场恢复服务
系统监控 es本身有收费版的监控系统

二、   最终方案-延云YDB混合方案集成多个系统的优势

针对上述典型场景,我们最终将多个系统整合,发挥系统的各自优势,扬长避短,深度集成。延云YDB作为机动车缉查布控即席分析引擎,已经在10个以上城市的成功部署或测试,取得非常好的效果,有的甚至超过了客户的预期。

YDB是一个基于Hadoop分布式架构下的实时的、多维的、交互式的查询、统计、分析引擎,具有万亿数据规模下的万级维度秒级统计分析能力,并具备企业级的稳定可靠表现。

YDB是一个细粒度的索引,精确粒度的索引。数据即时导入,索引即时生成,通过索引高效定位到相关数据。YDB与Spark深度集成,Spark直接对YDB检索结果集分析计算,同样场景让Spark性能加快百倍。

 

延云推荐配置

延云YDB高性能配置 (毫秒响应)

1.机器内存:128G

2.磁盘:企业级SSD,600~800G *12个磁盘

3.CPU:32线程(2颗,16核,32线程)

4.万兆网卡

延云YDB常规配置 (秒级响应)

1.机器内存:128G

2.磁盘:2T*12的磁盘

3.CPU:24线程(2颗,12核,24线程)

4.千兆网卡

 

指标比对

 

数据规模-数据节点数 1.在腾讯我们做到了53台机器 处理每天1800亿的日增量,总量达几万亿的数据规模(每条数据1kb左右)

2.在延云推荐的普通机器

以给的示例数据预估,每个节点每天实时处理30~50亿的数据比较适合。

处理的数据规模以及查询响应速度,根据节点数线性增长。

查询与统计功能灵活性 1.支持hive SQL表达,支持所有的hive内置函数,可以嵌套SQL,可以多表关联,也可以自定义UDF,UDAF

2. 内置的分词类型会确保查询准确度,不会出现漏查,内置的分词类型,很好的解决了lucene默认分词导致的查询数据缺失的问题。另外YDB可以自定义拓展任意的luene分词类型。如词库分词,语义分词,拼音分词等。

3.能支持任意维度的多维查询,多维统计,与分析。

检索与并发性能 常规情况下支持200~300的并发查询,持续性压测20天以上。

但是目前我的真实生产系统,确实没有很大的并发,最大的并发系统也就是每5分钟由系统触发的100并发的检索查询,但是查询完毕后会有5分钟的休息时间。

数据导入与时效性 数据从产生约1~2分钟,系统内可查

每天千亿增量,总量可达万亿

稳定性-与单点故障 1.采用Spark Yarn的方式,系统宕机,硬件损坏,服务会自动迁移,数据不丢失。

2.有守护进程,一旦发现服务异常,自动重启服务,不需要运维人员亲自去机房重启机器。

3.延云YDB只需要部署在一台机器上,由Yarn自动分发,不需要维护一堆机器的配置,改参数很方便。易于部署,易于扩容,易于数据迁移;

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

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

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

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

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

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

7.我们修正了大量的spark的bug,让系统比开源系统更稳定。

http://blog.csdn.net/qq_33160722/article/details/60583286

排序性能 采用延云独有的BLOCK SORT 技术,百亿数据秒级排序。

技术原理请参考

http://blog.csdn.net/muyannian/article/details/60755273

用户接口 采用SQL的方式,用户学习陈本低。

支持HIVE的JDBC接入(编程),可以命令行接入(定时任务),http方式接入。

Hive的JDBC协议,已经是大数据的事实标准。

与常规大数据系统可无缝对接(如hive,spark,kafka等),也提供了拓展接口。

海量数据导入导出灵活方便,也可与常见的支持jdbc的报表工具、SQL可视化工具集成。

方便与周边系统

的导入导出

导出

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

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

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

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

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

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

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

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

 

导入

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

1.索引的设计实现,不会想solr与es那样将数据全部加载到内种内存中进行映射,这无论是在导入还是在查询过程中均大幅的减少了OOM的风险。

2.在内存与磁盘多个区域不同合并策略,在结合控速逻辑,让导入占用的性能控制在一定范围之内,让系统更平稳,尽量减少索引合并瞬间产生的几分钟占据了大量的资源的情况,分散资源的占用,让前台用户的查询更平稳。

3.结合了storm流式处理的优点,采用对接消息队列(如kafka)的方式,数据导入kafka后大约1~2分钟即可在ydb中查到。

 

数据存储与恢复 将数据存储在HDFS之上

1.YDB基于HDFS做了磁盘与网络做了读写控速逻辑。

2.磁盘局部坏点hdfs配有crc32校验,有坏点会立即发现,并不影响服务,会自动切换到没有坏点的数据继续读取。

3.本地磁盘损坏,HDFS自动恢复数据,不会中断读写,不会有服务中断。

数据迁移 1.hdfs通过balance自动迁移数据。

2.可以控制迁移过程中的带宽流量。

2.迁移过程中不中断服务,hdfs扩容与移除机器也对服务没影响。

增加主备kafka 支持,切换过程不中断服务
定时聚集 兼容了hive本身的特性,适合大量数据后台定时计算。

内置支持直接将ydb的计算结果导出到oracle,不需要在单独写etl程序。

实时聚集 兼容了本身索引的特性,适合扫描小范围的数据。

聚焦性能跟命中的记录条数以及机器磁盘数有很大关系。如果是100量车从3000亿条原始数据数据中筛选1.5亿条记录进行统计汇总,6台集群sata盘的磁盘的iops达不到这个性能,需要ssd磁盘才行。

预警与在线扩容 1.数据存储在HDFS之上,不存储在本地硬盘,扩容,迁移,容灾与Hadoop一样,稳定可靠。

2.对于kafka消费延迟,节点宕掉,均有预警机制,可以在moniter页面看到。

系统监控 1.有完备的指标监控系统,可以实时YDB监控集群的运行状态。

2.基于有存储的预警系统,出现问题后会发出通知报警。

3.如果机器异常页面也会显示出warning报警

4.可以自定义报警逻辑

 

常见SQL 写法示例

5.行车轨迹查询/重点车辆分析

描述 一般根据一个车牌号,去搜寻特定车辆的行车轨迹。在XX部门的系统里用于追踪嫌犯的犯罪过程,或者对重点车辆进行分析。
SQL /*ydb.pushdown(‘->’)*/

select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=”云NEW336″ order by jgsj desc limit 10

/*(‘<-‘)pushdown.ydb*/

 

6.同行车辆分析

  描述 可以根据目标车辆过车的前后时间,经过的地点,找到目标车辆的同行车辆。该功能一般用于查询“盯梢”,“跟踪”车辆。如果遇到绑架等案件,可以根据被绑架人的车辆的过车记录,查询出“盯梢”车辆,从而为案件的侦破提供更多的线索。
SQL select tmp.hphm,count(*) as rows,size(collect_set(tmp.kkbh)) as dist_kkbh,concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.kkbh)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsj,kkbh from ydb_oribit where ydbpartion = ‘20160619’ and ( (jgsj like ‘([201604290000 to 201604290200] )’ and kkbh=’10000000′) or ( jgsj like ‘([201604290001 to 201604290301] )’ and kkbh=’10000001′) or (jgsj like ‘([201604290002 to 201604290202] )’  and kkbh=’10000002′)  )

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_kkbh desc

7.区域碰撞分析

  

  描述 根据不同时间段的不同卡口(路段),找出在这些卡口上同时出现的车辆。该功能一般用于破获连环作案的案件,追踪逃犯,如部分城市最近经常在出现抢劫的行为,就可以根据多个抢劫的时间与地点,进行碰撞分析,如果多个抢劫的地点周围均出现该车辆,那么该车为嫌疑车辆的可能性就非常大,从而更有助于连环案件的侦破。
SQL select

tmp.hphm,

count(*) as rows,

size(collect_set(tmp.quyu)) as dist_quyu,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsj,quyu from ydb_jiaotong where ( (jgsj like ‘([201604111454 TO 201604131554] )’ and quyu=’安义路阁馨’) or (jgsj like ‘([201609041043 TO 201609041050] )’ and quyu=’恒仁路太阳星城’) or (jgsj like ‘([201609040909 TO 201609040914] )’ and quyu=’环江路大有恬园’

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_quyu desc limit 10

 

8.陌生车辆分析

  描述 用于搜寻某一地区,在案发期间出现过,并且在这之前没有出现或出现次数较少的车辆。陌生车辆对于小区盗窃,抢劫等案件的侦破可以提供较多的侦破线索。

给出一个时间范围【A TO B】,搜寻出一个区域内的所有车辆.

如果在这个时间范围出现过,并且在之前的 C天内出现次数少于N次的车辆

 

SQL select * from (

select

tmp.hphm,

count(*) as rows,

max(tmp.jgsk) as max_jgsj,

size(collect_set(tmp.jgsk)) as dist_jgsj,

size(collect_set(case when ((tmp.jgsk>=’20161201153315′ and tmp.jgsk<=’20161202153315′) or (tmp.jgsk>=’20161203153315′ and tmp.jgsk<=’20161204153315′)) then 0 else tmp.jgsk end  )) as dist_before,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsk,tmp.kkbh)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select hphm,jgsk,kkbh from t_kk_clxx where

jgsk like ‘([20161201153315 TO 20161204153315] )’

and kkbh IN(‘320600170000089780′,’320600170000000239′,’320600170000000016′,’320600170000000018′,’320600170000002278′,’320600170000092977′,’320600170000092097′,’320600170000092117’)

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm

) tmp2 where tmp2.dist_before<=’1’ order by tmp2.dist_jgsj asc limit 10

 

 

9.昼伏夜出、落脚点分析

  

  描述 可以针对某一车辆,查询其出行规律,分析其日常在每个时段的出行次数,经常出路的地点。通过分析车辆的出行规律,从而可以识别某一量车是否出现异常的出行行为,有助于对案件事发地点出现的车辆进行一起集体扫描,如果有车辆的该次出行行为与平日的出行行为不一致,那么该车极有可能就是嫌疑车辆。
SQL select

tmp.jgsk,

count(*) as rows,

size(collect_set(tmp.quyu)) as dist_quyu,

concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsj,tmp.quyu)))) as detail

from (

/*ydb.pushdown(‘->’)*/

select jgsk,jgsj,quyu from ydb_jiaotong where hphm=’黑NET458′

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.jgsk order by dist_quyu desc limit 10

 

10.嫌疑车牌模糊搜索与定位

  

  描述 因摄像头因夜晚或者天气等原因拍摄到的车牌识别不清,或者交通孽事车辆逃逸,目击证人只记住了车牌号的一部分,但知道车的颜色,是什么车等信息。但是事发路段可能会有多个其他交通探头能识别出该车牌。故可以根据车牌号码模糊检索,在结合车辆颜色,时间,车的型号等综合匹配出最有可能的车牌。从而定位到嫌疑车辆。

 

注意下面的hphm_search为charlike类型,可以进行号牌号码的模糊检索

SQL select tmp.hphm,count(*) as rows,size(collect_set(tmp.kkbh)) as dist_kkbh from (

/*ydb.pushdown(‘->’)*/

select hphm,kkbh from ydb_jiaotong where hphm_search=’NEW33′

/*(‘<-‘)pushdown.ydb*/

) tmp group by tmp.hphm order by dist_kkbh desc limit 10

 

 

 

 

你可能感兴趣的:(基于spark的车辆分析)