10亿数据量的即席查询 spark 和 kylin的对比

Kylin 与 Spark SQL相比,有哪些差异和优势

SparkSQL本质上是基于DAG模型的MPP。而Kylin核心是Cube(多维立方体)。关于MPP和Cube预处理的差异,重复如下:

>

MPP [1] 

的基本思路是增加机器来并行计算,从而提高查询速度。比如扫描8亿记录一台机器要处理1小时,但如果用100台机器来并行处理,就只要一分钟不到。再配合

列式存储和一些索引,查询可以更快返回。要注意这里在线运算量并没有减小,8亿条记录还是要扫描一次,只是参与的机器多了,所以快了。

>

MOLAP Cube [2][3] 

是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。8亿记录的一个3维索引可能只有几万条记录,规模大大缩

小,所以在线计算量大大减小,查询可以很快。索引表也可以采用列存储,并行扫描等MPP常用的技术。但多维索引要对多维度的各种组合作预计算,离线建索引

需要较大计算量和时间,最终索引也会占用较多磁盘空间。

了有无预处理的差异外,SparkSQL与Kylin对数据集大小的偏好也不一样。如果数据可以基本放入内存,Spark的内存缓存会让SparkSQL

有好的表现。但对于超大规模的数据集,Spark也不能避免频繁的磁盘读写,性能会大幅下降。反过来Kylin的Cube预处理会大幅减小在线数据规模,

对于超大规模数据更有优势。



数据量大约在10亿+,需要做一个即席查询,用户可以主动输入搜索条件,如时间。可提供一定的预处理时间。每天还有新数据加入。

    10亿+的数据对于普通的rdbms还是有些压力的,而且数据每天还在不停的增长,所以我们运用了我们的spark技术来做一个计算加速。关于增量更新的相关,我会在后续的博客中介绍。

语句如下

select count(*) a,b from table_a where c = '20170101' group by a,b order by a

首先用我们的spark-local模式进行测试数据量成倍上涨。

数据量table_a的倍数spark-local i3 ddr3 8gspark-local i7 ddr4

32g

spark-yarn

5g,3core 3instance

800w10.512s0.40.771

1600w20.512s0.50.552

3200w40.794s0.680.579

6400w81.126s0.9450.652

1亿2800w161.968s1.40.922

2亿5600w323.579s2.5741.475

5亿1200w646.928s5.0013.384

10亿2400w12813.395s9.5285.372

    我们可以看到单核cpu的性能也会影响spark的性能,所以在衡量一个spark集群的计算性能时,不光要看有几个core,几个instance,还要看单个core的计算能力,而且数据量越大,差距也越大。

    spark-sql有一个特点,同样的语句,第二,第三次计算会比之前快,如果不停地运行同一个语句,你会发现时间会成下降趋势直到一个稳定值,一般为2-3次后会达到最小值,在10亿这个级别上,在yarn模式下,运行3次左右后,性能可以达到3s左右,对于一个测试用的小集群已经很让人满意了,如果是正规的spark集群,相信性能还会好很多,做即席查询完全够用了。个人理解是spark会有一定的缓存机制,但是不会缓存在多的东西,这个和之后要讲的Kylin还是不同的。kylin如果是同样的语句,第二次绝对是秒出。

下面我们尝试了用Kylin,效果很让人震撼。

Kylin官网如下

http://kylin.apache.org/

Apache Kylin是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

Kylin中国唯一Apache顶级项目。支持下哦

Kylin是基于Hive表的,所以我们还是要将我们的数据先导入到hive中去。

Kylin的安装在这里就不将了,很简单,官网有介绍,启动下服务就可以了。然后打开7070端口

要使用Kylin计算,我们要先建立Model,一个model需要对应一张hive表,然后再model的基础上建立cube,这里我们创建一个默认的cube即可。

在Model页面我们可以看我们创建的cube如下图所示。

10亿数据量的即席查询 spark 和 kylin的对比_第1张图片

在列表中我们可以看到cube大小,记录数,上次构建时间等信息。

build好cube后就可以查询了,如果build成功cube的状态会变为READY,这时就可以查询了。

还是用之前的3节点的集群做性能测试

10亿数据量的即席查询 spark 和 kylin的对比_第2张图片

如上图所示,我们在查询界面可以看到这个语句走了哪个project,cubes,耗时等信息

测试结果如下

数据量构建时间(全量)sql时间

800w6.5min0.15s

1亿2800w48min0.15s

2亿5600w90.17min0.15s

5亿1200w142.40min执行错误

    这里到5亿的时候构建cube可以成功,但是运行sql会报错。应该是我没配置好。

    可以看到,kylin的查询性能还是非常可观的,而且查询时的资源消耗非常少,这点和spark不一样,由于这样的特性相对于spark,同样性能的集群上kylin就可以支持高得多的并发,并且提供高得多的查询性能,但是kylin的代价是很长的构建cube的时间和更多的磁盘占用,而且据我的经验来看,kylin对sql的支持不如spark-sql支持的好。如果要把原来rdbms的查询迁移到大数据集群中来,spark-sql的适应性会更好。

    虽然kylin也支持增量构建,但是相对于spark来说,数据准备的时间还是会长很多,因为spark也支持增量更新。如果允许有数据预处理时间的,例如把构建放到晚上12:00过后进行,在这种场景下,kylin也许更适合.但是如果需要数据实时变化,而且维度很多,sql完全不确定的情况,也许spark-sql更合适一些,具体怎么选择,还要看应用场景。

你可能感兴趣的:(10亿数据量的即席查询 spark 和 kylin的对比)