数据仓库的对比和选择

14次阅读

共计 1453 个字符,预计需要花费 4 分钟才能阅读完成。

整理了一些相关的产品,包括:
商业系统

InfoBright
Greenplum(已开源)、HP Vertica、TeraData、Palo、ExaData、RedShift、BigQuery(Dremel)

开源实现

Impala、Presto、Spark SQL、Drill、Hawq
Druid、Pinot
Kylin

presto、druid、sparkSQL、kylin 的对比

presto 和 spark sql 都是解决分布式查询问题,提供 SQL 查询能力,但数据加载不一定能保证实时;
Druid 是保证数据实时写入,但查询上不支持 SQL,或者说目前只支持部分 SQL,我个人觉得适合用于工业大数据,比如一堆传感器实时写数据的场景;
Kylin 是 MOLAP,就是将数据先进行预聚合,然后把多维查询变成了 key-value 查询。基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速;

  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
大数据查询目前来讲可以大体分为三类:

基于 hbase 预聚合的。适合相对固定的业务报表类需求。需要指定预聚合的指标,在数据接入的时候根据指定的指标进行聚合运算,只需要统计少量维度即可满足业务报表需求。比如 Opentsdb,Kylin,Druid 等
基于 Parquet 列式存储的,基本是完全基于内存的并行计算,Parquet 系能降低存储空间,提高 IO 效率,以离线处理为主,很难提高数据写的实时性,超大表的 join 支持可能不够好。spark sql 也算类似,但它在内存不足时可以 spill disk 来支持超大数据查询和 join。比如 Presto, Drill,Impala 等
基于 lucene 外部索引的,比如 ElasticSearch 和 Solr, 能够满足的的查询场景远多于传统的数据库存储,但对于日志、行为类时序数据,所有的搜索请求都也必须搜索所有的分片,另外,对于聚合分析场景的支持也是软肋

欢迎订阅「K 叔区块链」– 专注于区块链技术学习 博客地址:http://www.jouypub.com 简书主页:https://www.jianshu.com/u/756c9c8ae984segmentfault 主页:https://segmentfault.com/blog/jouypub 腾讯云主页:https://cloud.tencent.com/developer/column/72548

正文完
 0