hadoop、spark、hive、solr、es与YDB在车辆即席分析上的对比分析
自2012年以来,公安部交通管理局在全国范围内推广了机动车缉查布控系统(简称卡口系统),通过整合共享各地车辆智能监测记录等信息资源,建立了横向联网、纵向贯通的全国机动车缉查布控系统,实现了大范围车辆缉查布控和预警拦截、车辆轨迹、交通流量分析研判、重点车辆布控、交通违法行为甄别查处及侦破涉车案件等应用。在侦破肇事逃逸案件、查处涉车违法行为、治安防控以及反恐维稳等方面发挥着重要作用。
榕江网站制作公司哪家好,找创新互联!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作,到程序开发,运营维护。创新互联2013年至今到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联。
随着联网单位和接入卡口的不断增加,各省市区部署的机动车缉查布控系统积聚了海量的过车数据。截至目前,全国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数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉,但是本地磁盘不能及时的发现并修正这些错误。
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 |
分享标题:hadoop、spark、hive、solr、es与YDB在车辆即席分析上的对比分析
分享地址:http://pwwzsj.com/article/ihsgdd.html