延云YDB车辆分析

延云YDB车辆分析

2012年以来,公安部交通管理局在全国范围内推广了机动车缉查布控系统(简称卡口系统),通过整合共享各地车辆智能监测记录等信息资源,建立了横向联网、纵向贯通的全国机动车缉查布控系统,实现了大范围车辆缉查布控和预警拦截、车辆轨迹、交通流量分析研判、重点车辆布控、交通违法行为甄别查处及侦破涉车案件等应用。在侦破肇事逃逸案件、查处涉车违法行为、治安防控以及反恐维稳等方面发挥着重要作用。

随着联网单位和接入卡口的不断增加,各省市区部署的机动车缉查布控系统积聚了海量的过车数据。截至目前,全国32个省(区、市)已完成缉查布控系统联网工作,接入卡口超过50000个,汇聚机动车通行数据总条数超过2000亿条。以一个中等规模省市为例,每地市每日采集过车信息300万条,每年采集过车信息10亿条,全省每年将汇聚超过200亿条过车信息。如何将如此海量的数据管好、用好成为各省市所面临的巨大挑战。

随着车辆网以及汽车卡口应用的不断扩大,车辆数据的不断积累。对于原始数据的存储、处理、查询是一个很大的考验,为此我们需要一个能实时处理、多维度查询的分布式计算的平台。

 

 

一、   关键需求分解

1.   车辆轨迹查询

能够根据输入的车牌号,或通过车牌号模糊查询对车辆进行状态查询、订单轨迹追踪。过车记录查询,过车轨迹查询,落脚点分析,进行轨迹回放。

2.   地理位置检索

能够根据经纬度坐标快速的进行经纬度的过滤,如指定一个坐标,快速圈定周边10公里内的车辆。

3.   多维碰撞, 多维度查询

要求可以有5个条件的维度查询,最常用的是时间,终端号,类型。

可以根据多个维度进行任意条件的组合过滤,进行数据碰撞。

也可以根据多个地理坐标进行车辆碰撞分析。

4.   车辆出行规律分析,

可以按照一辆车,或一批车辆进行统计分析,了解车辆的出行规律,出行时间,频繁出入地点。

5.   出行规律异常车辆分析

选定某一区域的,周边陌生人/车的识别。出行规律异常的人/车识别。

6.   伴随分析

人车轨迹拟合,判断是否有代驾行为,有尾随,盯梢识别。

7.   数据碰撞分析

能够根据根据多个地理位置以及时间进行数据碰撞,连环时间进行数据碰撞分析。

8.   重点车辆分析

根据统计一定区域范围内的客运、危险品运输、特殊车辆等重点车辆通行数量,研判发现通行规律。对在路段内行驶时间异常的车辆、首次在本路段行驶的重点车辆、25点仍在道路上行驶的客运车辆等进行预警提示。

9.   车辆出入统计分析

挖掘统计一段时间内在某一个区域内(可设定中心城区、地市区域、省市区域、高速公路等区域)、进出区域、主要干道的经常行驶车辆、候鸟车辆、过路车辆的数量以及按车辆类型、车辆发证地的分类统计。

二、   关键技术能力要求

1.   数据规模-数据节点数

能够承载日均数百亿条增量,数据要可以长久保留

也要支撑未来三到五年,每天百亿,甚至数千亿条数据增量。

每个数据节点每天能处理20亿的数据量。

2.   查询与统计功能灵活性

根据不同的厂商,车型,往往在逻辑上有较大的区别,他们业务的不同查询逻辑也会有较大的区别,故一个查询系统要求非常灵活,可以处理复杂的业务逻辑,算法,而不是一些常规的简单的统计。

能支持复杂SQL

当业务满足不了需求的时候可以拓展SQL,自定义开发新的逻辑,udf,udaf,udtf

要能支持模糊检索

对于邮箱、手机号、车牌号码、网址、IP地址、程序类名、含有字母与数字的组合之类的数据会匹配不完整,导致数据查不全,因分词导致漏查以及缺失数据,对于模糊检索有精确匹配要求的场景下,业务存在较大的风险

多维分析多维碰撞

要求可以有5个条件的维度查询,最常用的是时间,终端号,类型。

3.   检索与并发性能

每次查询在返回100条以内的数据时能在1秒内返回,并发数不少于2006个节点以内)。对于并发数要做到随着节点数的增加可以按比例增加。

4.   数据导入与时效性

对数据时效性要求较高,要求某一车辆在经过产生数据后,可达到分钟级别内系统可查可分析。对检索性能要求很高,以上典型需求均要求能够在秒级内返回结果及明细。

采用SQL方式的批量导入,也要支持kafka的流式导入

5.   稳定性-与单点故障

易于部署,易于扩容,易于数据迁移;

多数据副本保护,硬件不怕硬件损坏;

服务异常能自动检测及恢复,减轻运维人员经常需要半夜起床的痛苦;

系统不能存在任何单点故障,当某个服务器存在问题时不能影响线上业务。

数据过百亿后,不能频繁的OOM,也不能出现节点调片的情况。

系统出现异常后,可以自动侦探服务异常,并自动重启恢复服务,不能每次调片都要运维    人员半夜去机房重启。需要服务有自动迁移与恢复的特性,大幅减少运维人员驻场的工作量。

提供了导入与查询的限流控制,也提供了过载保护控制,甚至在极端场景提供了有损查询与有损服务

6.   要有较高的排序性能

排序可以说是很多日志系统的硬指标(如按照时间逆序排序),如果一个大数据系统不能进行排序,基本上是这个系统属于不可用状态,排序算得上是大数据系统的一个刚需”,无论大数据采用的是hadoop,还是spark,还是impala,hive,总之排序是必不可少的,排序的性能测试也是必不可少的。

7.   用户接口

尽量是SQL接口。如果是程序接口学习成本与接入成本均较高。

8.   方便与周边系统的导入导出

能与现有的常见系统如hadoophive ,传统数据库,kafka等集成,方便数据导入导出。

支持原始数据的任意维度导出

可以全表,也可以通过过滤筛选局部导出

支持数据经过各种组合计算过滤后的导出

可以将Y多个表与其他系统的多个表,进行组合筛选过滤计算后在导出

可以将多个数据从一张表导入到、另外一张表

可以将数据导出到别的系统里面(如hivehbase,数据库等)

也可以将其他系统的数据导入到当前系统里面。

可以导出成文件,也可以从文件导入。

可以从kafka流式导入,也可以写插件,导出到kafka

9. 数据存储与恢复

数据不能存储在本地磁盘,迁移难,恢复也难。

1.磁盘读写没有很好的控速机制,导入数据没有良好的流量控制机制,无法控制流量,而生产系统,磁盘控速与流量控速是必须的,不能因为业务高峰对系统造成较大的冲击,导致磁盘都hang住或挂掉。

2.本地硬盘局部坏点,造成局部数据损坏对于系统来说可能无法识别,但是对于索引来说哪怕是仅仅一个byte数据的读异常,就会造成索引指针的错乱,导致检索结果数据丢失,甚至整个索引废掉,但是本地磁盘不能及时的发现并修正这些错误。

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

要将数据存储在HDFS之上

1).基于HDFS做了磁盘与网络做了读写控速逻辑。

2).磁盘局部坏点hdfs配有crc32校验,有坏点会立即发现,并不影响服务,会自动切换到没有坏点的数据继续读取。

3).本地磁盘损坏,HDFS自动恢复数据,不会中断读写,不会有服务中断。

10. 数据迁移

不能采取这样的方案:

夸机房搬迁机器,不能让运维人员细心的进行索引11复制,这种搬迁方案往往要数星期,且非常容易出错。

迁移过程中为了保证数据的一致性,需要中断服务或者中断数据的实时导入,让数据静态化落地后不允许在变化后,才能进行迁移,这种方案业务中断时间太久。

要采取这样的迁移方案

1.hdfs通过balance自动迁移数据。

2.可以控制迁移过程中的带宽流量。

2.迁移过程中不中断服务,hdfs扩容与移除机器也对服务没影响。

11. 增加主备kafka

采用的是KAFKA主备设置,当主个KAFKA出现问题时会自动切换到备KAFKA,不影响线上业务。

12. 可扩展性-预警与在线扩容

当系统存储出现瓶颈时能及时报警,可容易的对存储进行扩容和数据均衡。在扩容时可以在线扩容。

13. 系统监控

有成熟的系统存储监控平台,可以对平台的运行状态进行实时监控,一旦出现问题可以及时告知监控人员.

 

一、   业界现有方案优缺点分析

 

1.  开源大数据系统解决方案(HadoopSparkHiveImpala

数据规模-数据节点数

基于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.  流计算系统(StormSpark Streaming

数据规模-数据节点数

数据规模可随节点拓展

查询与统计功能灵活性

×

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

检索与并发性能

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

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

数据导入与时效性

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

稳定性-与单点故障

无单点故障,比较完善

排序性能

预计算的方式,排序结果预先算好,性能比较好

用户接口

×

java接口,有独立的API,需要写类似mapreduce的程序

方便与周边系统

的导入导出

×

比较难,需要单独独立开发对接程序

数据存储与恢复

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

 

数据迁移

数据迁移,扩容,容灾均有完善的方案,Storm的扩容需要简单的Rebanlance即可。

增加主备kafka

可以支持

预警与在线扩容

有完完备的方案

系统监控

有完完备的方案

 

3.  全文检索系统(SolrElasticSearch

数据规模-数据节点数

×

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是一个细粒度的索引,精确粒度的索引。数据即时导入,索引即时生成,通过索引高效定位到相关数据。YDBSpark深度集成,Spark直接对YDB检索结果集分析计算,同样场景让Spark性能加快百倍。

 

延云推荐配置

延云YDB高性能配置 (毫秒响应)

1.机器内存:128G

2.磁盘:企业级SSD600~800G *12个磁盘

3.CPU32线程(2,16,32线程)

4.万兆网卡

延云YDB常规配置 (秒级响应)

1.机器内存:128G

2.磁盘:2T*12的磁盘

3.CPU24线程(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.可以自定义报警逻辑