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