presto、druid、sparkSQL、kylin的对比分析,如性能、架构等,有什么异同?

作者:iseeyou
链接:https://www.zhihu.com/question/41541395/answer/114798939
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

这几个框架都是OLAP大数据分析比较常见的框架,各自特点如下:presto:facebook开源的一个java写的分布式数据查询框架,原生集成了Hive、Hbase和关系型数据库,Presto背后所使用的执行模式与Hive有根本的不同,它没有使用MapReduce,大部分场景下比hive快一个数量级,其中的关键是所有的处理都在内存中完成。Druid:是一个实时处理时序数据的Olap数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。spark SQL:基于spark平台上的一个olap框架,本质上也是基于DAG的MPP, 基本思路是增加机器来并行计算,从而提高查询速度。kylin:核心是Cube,cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。这几种框架各有优缺点,存在就是合理,如何选型个人看法如下:从成熟度来讲:kylin>spark sql>Druid>presto从超大数据的查询效率来看:Druid>kylin>presto>spark sql从支持的数据源种类来讲:presto>spark sql>kylin>Druid大数据查询目前来讲可以大体分为三类:1.基于hbase预聚合的,比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标,在数据接入的时候根据指定的指标进行聚合运算,适合相对固定的业务报表类需求,只需要统计少量维度即可满足业务报表需求2.基于Parquet列式存储的,比如Presto, Drill,Impala等,基本是完全基于内存的并行计算,Parquet系能降低存储空间,提高IO效率,以离线处理为主,很难提高数据写的实时性,超大表的join支持可能不够好。spark sql也算类似,但它在内存不足时可以spill disk来支持超大数据查询和join3.基于lucene外部索引的,比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储,但对于日志、行为类时序数据,所有的搜索请求都也必须搜索所有的分片,另外,对于聚合分析场景的支持也是软肋

据我不完全收集,包括:商业系统InfoBrightGreenplum(已开源)、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery(Dremel)开源实现Impala、Presto、Spark SQL、Drill、HawqDruid、PinotKylin其中你列的presto、druid、sparkSQL、kylin可以分为三类。其中presto和spark sql都是解决分布式查询问题,提供SQL查询能力,但数据加载不一定能保证实时。Druid是保证数据实时写入,但查询上不支持SQL,或者说目前只支持部分SQL,我个人觉得适合用于工业大数据,比如一堆传感器实时写数据的场景。Kylin是MOLAP,就是将数据先进行预聚合,然后把多维查询变成了key-value查询。这里要看你实际要应用于什么场景了。

作者:桑文锋
链接:https://www.zhihu.com/question/41541395/answer/91709171
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

作者:吴镝
链接:https://www.zhihu.com/question/41541395/answer/130713893
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

简单说几句。
1. kylin 预计算。用户指定dimensions和要计算的metric,kylin通过MR将结果保存在HBase中,后续读取直接读HBase。适合那种业务清楚的知道自己要分析什么的场景。查询模式比较固定,只不过所查看的时间不同的场景。注意的点是要避免维度灾难。

2. presto java8写的,代码质量非常高。设计:纯内存,没有容错,一个task失败就整个query fail。需要注意调整内存相关,线程数等参数,容易OOM。benchmark还行。支持标准SQL

3. spark sql 个人觉得支持查询Hive的数据,支持HQL非常重要,因为很多公司以前的数据都是放在Hive上的。我们测试了spark sql 2.0.1,对于鄙司这种分区数很多,每个分区很多parquet文件的情形来说,几乎不可用,原因在于 [SPARK-16980] Load only catalog table partition metadata required to answer a query 转而测试spark sql 2.1.0, 结果还是比较满意的。不过容错性还有待检验,benchmark过程中如果个别task失败,job 有时候会hang住,待分析。

其他没用过不评价。

总体来说,至少从我们的benchmark结果来看,spark sql 很有前景。

你可能感兴趣的:(presto、druid、sparkSQL、kylin的对比分析,如性能、架构等,有什么异同?)