spark、hadoop、storm、solr、es在车辆分析上的分析与比较

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

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