SQL如何通过视图或存储过程实现信息预警_百度知道
SQL如何通过视图或存储过程实现信息预警
现有两张表，一张存储迟到信息，一张存储预警信息。当有人员迟到时，录入一条迟到信息到迟到表里。当同一人员迟到5次（即录入的迟到信息达到5次）时，自动在预警信息表里存储一条预警...
现有两张表，一张存储迟到信息，一张存储预警信息。当有人员迟到时，录入一条迟到信息到迟到表里。当同一人员迟到5次（即录入的迟到信息达到5次）时，自动在预警信息表里存储一条预警信息。该怎么实现？
答题抽奖
首次认真答题后
即可获得3次抽奖机会，100%中奖。
采纳数：590
获赞数：1393
想到几种办法：第一、在迟到表上面创建触发器。当插入记录时，去预警信息表里面查是否已经有5次，如果有则在预警信息表里面插入一条第二、创建一个sp来插入迟到表，里面逻辑同触发器
触发器该怎么写呢？附加：需要查询的是本年度迟到达到5次的数据
采纳数：43
获赞数：55
可以使用sql 触发器
为你推荐：
其他类似问题
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。自2012年以来，公安部交通管理局在全国范围内推广了机动车缉查布控系统（简称卡口系统），通过整合共享各地车辆智能监测记录等信息资源，建立了横向联网、纵向贯通的全国机动车缉查布控系统，实现了大范围车辆缉查布控和预警拦截、车辆轨迹、交通流量分析研判、重点车辆布控、交通违法行为甄别查处及侦破涉车案件等应用。在侦破肇事逃逸案件、查处涉车违法行为、治安防控以及反恐维稳等方面发挥着重要作用。
随着联网单位和接入卡口的不断增加，各省市区部署的机动车缉查布控系统积聚了海量的过车数据。截至目前，全国32个省（区、市）已完成缉查布控系统联网工作，接入卡口超过50000个，汇聚机动车通行数据总条数超过2000亿条。以一个中等规模省市为例，每地市每日采集过车信息300万条，每年采集过车信息10亿条，全省每年将汇聚超过200亿条过车信息。如何将如此海量的数据管好、用好成为各省市所面临的巨大挑战。
随着车辆网以及汽车卡口应用的不断扩大，车辆数据的不断积累。对于原始数据的存储、处理、查询是一个很大的考验，为此我们需要一个能实时处理、多维度查询的分布式计算的平台。
关键需求分解
车辆轨迹查询
能够根据输入的车牌号，或通过车牌号模糊查询对车辆进行状态查询、订单轨迹追踪。过车记录查询，过车轨迹查询，落脚点分析，进行轨迹回放。
地理位置检索
能够根据经纬度坐标快速的进行经纬度的过滤，如指定一个坐标，快速圈定周边10公里内的车辆。
多维碰撞, 多维度查询
要求可以有5个条件的维度查询，最常用的是时间，终端号，类型。
可以根据多个维度进行任意条件的组合过滤，进行数据碰撞。
也可以根据多个地理坐标进行车辆碰撞分析。
车辆出行规律分析，
可以按照一辆车，或一批车辆进行统计分析，了解车辆的出行规律，出行时间，频繁出入地点。
出行规律异常车辆分析
选定某一区域的，周边陌生人/车的识别。出行规律异常的人/车识别。
人车轨迹拟合，判断是否有代驾行为，有尾随，盯梢识别。
数据碰撞分析
能够根据根据多个地理位置以及时间进行数据碰撞，连环时间进行数据碰撞分析。
重点车辆分析
根据统计一定区域范围内的客运、危险品运输、特殊车辆等重点车辆通行数量，研判发现通行规律。对在路段内行驶时间异常的车辆、首次在本路段行驶的重点车辆、2到5点仍在道路上行驶的客运车辆等进行预警提示。
车辆出入统计分析
挖掘统计一段时间内在某一个区域内（可设定中心城区、地市区域、省市区域、高速公路等区域）、进出区域、主要干道的经常行驶车辆、“候鸟”车辆、过路车辆的数量以及按车辆类型、车辆发证地的分类统计。
关键技术能力要求
数据规模-数据节点数
能够承载日均数百亿条增量，数据要可以长久保留
也要支撑未来三到五年，每天百亿，甚至数千亿条数据增量。
每个数据节点每天能处理20亿的数据量。
查询与统计功能灵活性
根据不同的厂商，车型，往往在逻辑上有较大的区别，他们业务的不同查询逻辑也会有较大的区别，故一个查询系统要求非常灵活，可以处理复杂的业务逻辑，算法，而不是一些常规的简单的统计。
能支持复杂SQL
当业务满足不了需求的时候可以拓展SQL，自定义开发新的逻辑,udf,udaf,udtf。
要能支持模糊检索
对于邮箱、手机号、车牌号码、网址、IP地址、程序类名、含有字母与数字的组合之类的数据会匹配不完整，导致数据查不全，因分词导致漏查以及缺失数据，对于模糊检索有精确匹配要求的场景下，业务存在较大的风险
多维分析多维碰撞
要求可以有5个条件的维度查询，最常用的是时间，终端号，类型。
检索与并发性能
每次查询在返回100条以内的数据时能在1秒内返回，并发数不少于200（6个节点以内）。对于并发数要做到随着节点数的增加可以按比例增加。
数据导入与时效性
对数据时效性要求较高，要求某一车辆在经过产生数据后，可达到分钟级别内系统可查可分析。对检索性能要求很高，以上典型需求均要求能够在秒级内返回结果及明细。
采用SQL方式的批量导入，也要支持kafka的流式导入
稳定性-与单点故障
易于部署，易于扩容，易于数据迁移；
多数据副本保护，硬件不怕硬件损坏；
服务异常能自动检测及恢复，减轻运维人员经常需要半夜起床的痛苦；
系统不能存在任何单点故障，当某个服务器存在问题时不能影响线上业务。
数据过百亿后，不能频繁的OOM，也不能出现节点调片的情况。
系统出现异常后，可以自动侦探服务异常，并自动重启恢复服务，不能每次调片都要运维
人员半夜去机房重启。需要服务有自动迁移与恢复的特性，大幅减少运维人员驻场的工作量。
提供了导入与查询的限流控制，也提供了过载保护控制，甚至在极端场景提供了有损查询与有损服务
要有较高的排序性能
排序可以说是很多日志系统的硬指标（如按照时间逆序排序），如果一个大数据系统不能进行排序，基本上是这个系统属于不可用状态，排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark，还是impala,hive，总之排序是必不可少的，排序的性能测试也是必不可少的。
尽量是SQL接口。如果是程序接口学习成本与接入成本均较高。
方便与周边系统的导入导出
能与现有的常见系统如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. 系统监控
有成熟的系统存储监控平台，可以对平台的运行状态进行实时监控，一旦出现问题可以及时告知监控人员.
业界现有方案—优缺点分析
开源大数据系统解决方案（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有完完备的方案
流计算系统（Storm、Spark Streaming）
数据规模-数据节点数
数据规模可随节点拓展
查询与统计功能灵活性
无法查看明细数据，只能看特定粒度的汇总结果，而过车记录是无法先计算出来的，即无法预知那个车有可能会犯罪，那个车会出事故，故无法预计算。
检索与并发性能
1.预先将需要查询的数据计算好，查询的时候直接访问预计算好的结果，性能非常好。
2.预计算完毕的结果集存储在HBase或传统数据库里，因数据规模并不大故并发性比较好。
数据导入与时效性
时效性非常好，一般与Kafka采用消息队列的方式导入，时效性可达几秒可见。
稳定性-与单点故障
无单点故障，比较完善
预计算的方式，排序结果预先算好，性能比较好
java接口，有独立的API，需要写类似mapreduce的程序
方便与周边系统
的导入导出
比较难，需要单独独立开发对接程序
数据存储与恢复
损坏的机器会自动摘除，进行会自动迁移，服务不中断。
数据迁移，扩容，容灾均有完善的方案，Storm的扩容需要简单的Rebanlance即可。
增加主备kafka
预警与在线扩容
有完完备的方案
有完完备的方案
全文检索系统（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_/article/details/
采用延云独有的BLOCK SORT 技术，百亿数据秒级排序。
技术原理请参考
http://blog.csdn.net/muyannian/article/details/
采用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部门的系统里用于追踪嫌犯的犯罪过程，或者对重点车辆进行分析。
/*ydb.pushdown(‘-&’)*/
select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=”云NEW336″ order by jgsj desc limit 10
/*(‘&-‘)pushdown.ydb*/
6.同行车辆分析
可以根据目标车辆过车的前后时间，经过的地点，找到目标车辆的同行车辆。该功能一般用于查询“盯梢”，“跟踪”车辆。如果遇到绑架等案件，可以根据被绑架人的车辆的过车记录，查询出“盯梢”车辆，从而为案件的侦破提供更多的线索。
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
/*ydb.pushdown(‘-&’)*/
select hphm,jgsj,kkbh from ydb_oribit where ydbpartion = ‘’ and ( (jgsj like ‘([ to ] )’ and kkbh=’′) or ( jgsj like ‘([ to ] )’ and kkbh=’′) or (jgsj like ‘([ to ]
and kkbh=’′)
/*(‘&-‘)pushdown.ydb*/
) tmp group by tmp.hphm order by dist_kkbh desc
7.区域碰撞分析
根据不同时间段的不同卡口（路段），找出在这些卡口上同时出现的车辆。该功能一般用于破获连环作案的案件，追踪逃犯，如部分城市最近经常在出现抢劫的行为，就可以根据多个抢劫的时间与地点，进行碰撞分析，如果多个抢劫的地点周围均出现该车辆，那么该车为嫌疑车辆的可能性就非常大，从而更有助于连环案件的侦破。
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
/*ydb.pushdown(‘-&’)*/
select hphm,jgsj,quyu from ydb_jiaotong where ( (jgsj like ‘([ TO ] )’ and quyu=’安义路阁馨’) or (jgsj like ‘([ TO ] )’ and quyu=’恒仁路太阳星城’) or (jgsj like ‘([ TO ] )’ and quyu=’环江路大有恬园’
/*(‘&-‘)pushdown.ydb*/
) tmp group by tmp.hphm order by dist_quyu desc limit 10
8.陌生车辆分析
用于搜寻某一地区，在案发期间出现过，并且在这之前没有出现或出现次数较少的车辆。陌生车辆对于小区盗窃，抢劫等案件的侦破可以提供较多的侦破线索。
给出一个时间范围【A TO B】,搜寻出一个区域内的所有车辆.
如果在这个时间范围出现过，并且在之前的 C天内出现次数少于N次的车辆
select * from (
count(*) as rows,
max(tmp.jgsk) as max_jgsj,
size(collect_set(tmp.jgsk)) as dist_jgsj,
size(collect_set(case when ((tmp.jgsk&=’15′ and tmp.jgsk&=’15′) or (tmp.jgsk&=’15′ and tmp.jgsk&=’15′)) then 0 else tmp.jgsk end
)) as dist_before,
concat_ws(‘#’, sort_array(collect_set(concat_ws(‘,’,tmp.jgsk,tmp.kkbh)))) as detail
/*ydb.pushdown(‘-&’)*/
select hphm,jgsk,kkbh from t_kk_clxx where
jgsk like ‘([15 TO 15] )’
and kkbh IN(‘089780′,’000239′,’000016′,’000018′,’002278′,’092977′,’092097′,’092117’)
/*(‘&-‘)pushdown.ydb*/
) tmp group by tmp.hphm
) tmp2 where tmp2.dist_before&=’1’ order by tmp2.dist_jgsj asc limit 10
9.昼伏夜出、落脚点分析
可以针对某一车辆，查询其出行规律，分析其日常在每个时段的出行次数，经常出路的地点。通过分析车辆的出行规律，从而可以识别某一量车是否出现异常的出行行为，有助于对案件事发地点出现的车辆进行一起集体扫描，如果有车辆的该次出行行为与平日的出行行为不一致，那么该车极有可能就是嫌疑车辆。
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
/*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类型，可以进行号牌号码的模糊检索
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
基于轨迹数据的伴随关系分析挖掘
solr与hadoop结合
用Apache Hadoop和Apache Solr处理和索引医学图像
Hadoop配置使用Solr
实现Solr索引数据存放到HDFS下
Solr+Hbase多条件查（优劣互补）
大数据并发处理 hadoop solr
如何利用Spark提高批量插入Solr的效率
没有更多推荐了，
(window.slotbydup=window.slotbydup || []).push({
id: "5865575",
container: s,
size: "300,250",
display: "inlay-fix"