hadoop、spark、hive、solr、es与YDB在车辆即席分析上的对比分析

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

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

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

的导入导出

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

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

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

的导入导出

2.本身系统内存的限定，百亿以上将会是巨大的挑战-除非是512G内存的机器，弄个20~30台左右，且是数据总量百亿，而不是每天百亿。

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

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

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

5. 基于lucene的分词来实现，但并不考虑单词的匹配顺序，也不保证匹配词语的连续性，中间可以穿插其他单词。

6.solr与es中不支持多列的group by与统计（原因为无法交叉），所谓的实现是通过单列group by后 进行的笛卡尔及，按照每个单元格重新进行的查询。

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

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

3.没有良好的合并控制策略，系统会发生阶段性（几分钟）的负载极高的情况（索引合并），此时系统资源占用特别高，前台查询响应速度极慢。

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

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

lucene在索引合并过程中，每进行一次commit都要进行一次全范围的ord关系的重新映射，数据规模小的时候整个索引文件的映射还没什么，但是当数据量达到亿级别，甚至百亿级别后，这种映射关系会占用超多的CPU、内存、硬盘资源，所以当数据量过亿后，solr与Es在数据比较大的情况下，实时索引几乎是不可能的，频繁的ord关系映射，会让整个系统不可用。

采用lucene的Sort接口实现，本质是借助docvalues的暴力扫描，如果数据量很大排序过程耗费非常多的内存与IO，并且排序耗时很高。

因不是通用的通讯协议，与其他大数据系统集成对接麻烦。

的导入导出

数据如若想导出到其他系统很难，超过百万级别的导出基本是不可行的,没有成型的高可用的导出方案。

全量数据导出基本是不可能的，更别谈经过多表复杂运算后的导出了

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

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

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

2.迁移过程中为了保证数据的一致性，需要中断服务或者中断数据的实时导入，让数据静态化落地后不允许在变化后，才能进行迁移。

2.在延云推荐的普通机器

以给的示例数据预估，每个节点每天实时处理30~50亿的数据比较适合。

处理的数据规模以及查询响应速度，根据节点数线性增长。

2. 内置的分词类型会确保查询准确度，不会出现漏查，内置的分词类型，很好的解决了lucene默认分词导致的查询数据缺失的问题。另外YDB可以自定义拓展任意的luene分词类型。如词库分词，语义分词，拼音分词等。

3.能支持任意维度的多维查询，多维统计，与分析。

但是目前我的真实生产系统，确实没有很大的并发，最大的并发系统也就是每5分钟由系统触发的100并发的检索查询，但是查询完毕后会有5分钟的休息时间。

每天千亿增量，总量可达万亿

2.有守护进程，一旦发现服务异常，自动重启服务，不需要运维人员亲自去机房重启机器。

3.延云YDB只需要部署在一台机器上，由Yarn自动分发，不需要维护一堆机器的配置,改参数很方便。易于部署，易于扩容，易于数据迁移；

4.多数据副本保护，硬件不怕硬件损坏；

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

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

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

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

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

7.我们修正了大量的spark的bug，让系统比开源系统更稳定。

http://blog.csdn.net/qq_33160722/article/details/60583286

技术原理请参考

http://blog.csdn.net/muyannian/article/details/60755273

支持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中查到。

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

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

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

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

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

内置支持直接将ydb的计算结果导出到oracle,不需要在单独写etl程序。

聚焦性能跟命中的记录条数以及机器磁盘数有很大关系。如果是100量车从3000亿条原始数据数据中筛选1.5亿条记录进行统计汇总，6台集群sata盘的磁盘的iops达不到这个性能，需要ssd磁盘才行。

2.对于kafka消费延迟，节点宕掉，均有预警机制，可以在moniter页面看到。

2.基于有存储的预警系统，出现问题后会发出通知报警。

3.如果机器异常页面也会显示出warning报警

4.可以自定义报警逻辑

select hphm,kkbh,jgsj,jgsk,quyu from ydb_jiaotong where hphm=”云NEW336″ order by jgsj desc limit 10

/*(‘<-‘)pushdown.ydb*/

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

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

给出一个时间范围【A TO B】,搜寻出一个区域内的所有车辆.

如果在这个时间范围出现过，并且在之前的 C天内出现次数少于N次的车辆

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

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

注意下面的hphm_search为charlike类型，可以进行号牌号码的模糊检索

/*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