数据规模

√

基于hdfs之上，数据可无限拓展，存储PB级的数据很轻松。

时效性

×

hdfs的特性导致数据延迟较大，常规应用均是T+1数据，即延迟一天。

查询性能与并发

×

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

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

灵活性

√

1.SQL支持较为齐全。

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

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

运维

√

硬件损坏，机器宕机后可自动迁移任务，不需要人工干预，中间不影响服务。

扩容迁移容灾

√

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

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

数据规模

√

基于hdfs之上，数据可无限拓展，

时效性

√

时效性非常好，一般与kafka采用消息队列的方式导入，时效性可达几秒可见。

查询性能与并发

√

1.预先将需要查询的数据计算好，查询的时候直接访问预计算好的结果，性能非常好。

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

灵活性

×

无法查看明细数据，只能看特定粒度的汇总结果，而过车记录是无法先计算出来的，即无法预知那个车有可能会犯罪，那个车会出事故，故无法预计算。

运维

√

损坏的机器会自动摘除，进行会自动迁移，服务不中断。

扩容迁移容灾

√

数据迁移，扩容，容灾均有完善的方案，storm的扩容需要简单的rebanlance即可。

数据规模

×

1.典型使用场景在千万级别，如果给予较大内存，数据量可上亿。

2.本身系统内存的限定，百亿以上降会是巨大的挑战。

时效性

×

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

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

查询性能与并发

√

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

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

灵活性

×

1.为搜索引擎的场景而生，分析功能较弱。只有最简单的统计功能，无法满足过车记录复杂的统计分析需求。

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

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

运维

×

1.数据规模一旦过百亿，就会频繁的出现OOM，节点调片的情况。

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

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

扩容迁移容灾

×

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

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

3.数据如若想导出到其他系统很难，超过百万级别的导出基本是不可行的，更别提复杂计算后的导出，没有成型的高可用的导出方案。

数据规模

√

在政府某部门:用4~10台普通PC即可支撑百亿规模的数据。

在IBM的小型机上:用10台机器就支持一万亿的数据规模。

在某互联网公司:支撑了每天7000亿，总量几万亿的数据查询。

时效性

√

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

并发查询性能

√

1.借鉴了solr与elasticsearch，使用了倒排索引，查询的时候直接定位到相关记录，避免了对数据的暴力扫描。

2.借鉴spark的process local方式，让同一份数据尽量在同一个进程内重用，以便能够高效的Cache。

3.结合标签技术、不必读取列的值本身，而是只读取其数值字典代号，更小的IO，能够让数据比常规计算能够更快的进行process local级的combine。

4.延迟列加载技术，可以让一些列的值在最终返回给用户的时候在读取，相比spark的列存储方式通常可以节省该列90%以上的IO。

5.采用列存储计算，列与列之间在存储上分开，

6.百亿规模1秒内响应，万亿规模10台IBM机器3~5秒响应。一般根据数据量，常规查询可支撑200~300个人一起并发查询。

灵活性

√

1.我们将索引集成到了spark内部，这样结合Spark可以做很多复杂的计算，但又兼顾了倒排索引的高性能。用户可以写复杂的SQL，可以嵌套、可以join、可以distinct、可以自定义UDF\UDAF\UDTF函数来扩中SQL的功能。

2.因HIVE已经成为大数据的实时标准，YDB采用HIVE SQL的方式与周边系统的集成非常方便，数据导入导出灵活。

3.HIVE本身支持jdbc方式，可以与常见的报表系统无缝集成。

运维

√

1.采用spark yarn的方式，系统宕机，硬件损坏，服务会自动迁移，数据不丢失。

2.延云YDB只需要部署在一台机器上，由yarn自动分发，不需要维护一堆机器的配置,改参数很方便。

扩容迁移容灾

√

数据存储在hdfs之上，不存储在本地硬盘，扩容，迁移，容灾与hadoop一样，稳定可靠。

描述

一般根据一个车牌号，去搜寻特定车辆的行车轨迹。在XX部门的系统里用于追踪嫌犯的犯罪过程，或者对重点车辆进行分析。

SQL

select r[0] as hphm,r[1] as kkbh,r[2] as jgsj,r[3] as jgsk,r[4] as quyu

 from  ydb where YSQL(‘from‘,‘select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=\‘津AHF715\‘ order by jgsj desc ‘,‘segment‘) order by r[2] desc limit 10;

截图

  描述

可以根据目标车辆过车的前后时间，经过的地点，找到目标车辆的同行车辆。该功能一般用于查询“盯梢”，“跟踪”车辆。如果遇到绑架等案件，可以根据被绑架人的车辆的过车记录，查询出“盯梢”车辆，从而为案件的侦破提供更多的线索。

SQL

select * from (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 (

   select r[0] as hphm,r[1] as jgsj,r[2] as kkbh from ydb where YSQL(‘from‘,‘select hphm,jgsj,kkbh from ydb_jiaotong where ( (jgsj like \‘([201610121100 TO 201610121300] )\‘ and kkbh=\‘97910\‘) or (jgsj like \‘([201610110900 TO 201610121300] )\‘ and kkbh=\‘42977\‘) or (jgsj like \‘([201602201100 TO 201602201300] )\‘  and kkbh=\‘14168\‘)) ‘,‘segment‘) 

 ) tmp group by tmp.hphm

) tmp2 where tmp2. dist_kkbh>=2order by dist_kkbh desc limit 10

截图

  描述

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

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 (

   select r[0] as hphm,r[1] as jgsj,r[2] as quyu from ydb where

   YSQL(‘from‘,‘select hphm,jgsj,quyu from ydb_jiaotong where ( (jgsj like \‘([201609040244 TO 201609040249] )\‘ and quyu=\‘爱华路昭日\‘) or (jgsj like \‘([201609041043 TO 201609041050] )\‘ and quyu=\‘恒仁路太阳星城\‘) or (jgsj like \‘([201609040909 TO 201609040914] )\‘ and quyu=\‘环江路大有恬园\‘) ) ‘,‘segment‘) 

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

截图

  描述

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

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 (

    select r[0] as jgsk,r[1] as jgsj,r[2] as quyu from ydb where YSQL(‘from‘,‘select jgsk,jgsj,quyu from ydb_jiaotong where hphm=\‘津AHF715\‘ ‘,‘segment‘) 

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

截图

  描述

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

SQL

select * from (

select

   tmp.hphm,

   count(*) as rows,

   max(tmp.jgsj) as max_jgsj,

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

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

from (

   select r[0] as hphm,r[1] as jgsj,r[2] as quyu from ydb where

   YSQL(‘from‘,‘select hphm,jgsj,quyu from ydb_jiaotong where ( quyu=\‘恒仁路太阳星城\‘ and jgsj <=\‘201603012000\‘   ) ‘,‘segment‘) 

) tmp group by tmp.hphm 

) tmp2 where tmp2.max_jgsj>201603010043 order by tmp2.dist_jgsj asc limit 10

截图

  描述

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

SQL

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

select r[0] as hphm,r[1] as kkbh from ydb where

YSQL(‘from‘,‘select hphm,kkbh from ydb_jiaotong where hphm_search=\‘FGG45\‘ ‘,‘segment‘) 

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

截图