各个OLAP 引擎详细对比介绍
|
本文主要介绍了主流开源的OLAP引擎：Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等，逐一介绍了每一款开源 OLAP 引擎，包含架构、优缺点、使用场景等，希望可以给大家有所启发。 PS: 文章较长，建议收藏慢慢看。
说起 OLAP 要追溯到 1993 年。 OLAP场景的关键特征 与OLAP 不同的是，OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性。 OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。
OLAP开源引擎 目前市面上主流的开源OLAP引擎包含不限于：Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。 从事数据开发工作的小伙伴，大概率用过以上的几种甚至全部。所以下面就开门见山了，默认大家熟悉大数据的专业名词和生态环境。 Hive hive.apache.org Hive 是基于 Hadoop 的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的 sql 查询功能，可以将 sql 语句转换为 MapReduce 任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。 Spark SQL spark.apache.org/sql SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。 几点说明： 1）Spark SQL的应用并不局限于SQL； 2）访问hive、json、parquet等文件的数据； 3）SQL只是Spark SQL的一个功能而已； 4）Spark SQL这个名字起的并不恰当； Spark SQL在整个Spark体系中的位置如下
看图说话，分成三个部分，第一部分是前端的，第二部分是后端的，对三个部分是中间的Catalyst，这个Catalyst是整个架构的核心。 关于架构的流程总结，下面引用知乎@ysiwgtus 的内容 1、首先我们看前端。前端有不同种的访问方式。 1）典型的我们可以使用hive，你hive过来就是一个SQL语句，SQL语句就是一个字符串，那么这个字符串如何才能够被Catalyst进行解析呢，或者说如何将一个SQL语句翻译成spark的作业呢，他要经过解析的，有一个抽象语法树，这是第一种访问方式。 2）第二种访问方式，我们可以通过spark的应用程序，编程的方式来操作，编程的时候我们可以使用SQL，也可以使用dataframe或者是dataset api。 3）第三种是Streaming SQL，也就是说流和SQL综合起来使用。 2、我们看Catalyst 1）前端三个访问方式，当前端过来以后他首先会生成一个Unresolved Logical Plan，也就是一个没有彻底解析完的一个执行计划，这个执行计划会和我们的元数据，也就是metastore里面的schema一个表信息进行整合然后生成一个Logical Plan（逻辑执行计划）。 2）那么这个逻辑执行计划是最原始的，中间还会做各种优化也很多规则作用上去，也就是图中的Optimization Rules，然后进行优化以后生成优化过后的逻辑执行计划，就是图中的Optimized Logical Plan。 3）那么逻辑执行计划生成完了以后，才会生成物理执行计划，也就是我们spark的一个作业。 那么从你的SQL语句解析成抽象语法树之后后续的部分全部交给Catalyst来完成，包括你逻辑执行计划的生成，逻辑执行计划的优化都是由Catalyst完成的，我们再回顾一下shark，他的解析然后逻辑执行计划的生成和优化全部都是依赖于hive的，那么这就是sparkSQL和hive典型的一个区别从抽象语法树之后，也就是图上AST之后完全由sparkSQL里的Catalyst接管以后，由他来生成物理执行计划，并最终提交到生产上面去运行就行了。 3、以上就是sparkSQL架构的整体的流程，这个流程当中主要有几个部分，语法树、逻辑执行计划、优化之后的逻辑执行计划、物理执行计划。如果熟悉SQL的执行流程或者了解hive的SQL语句是怎么样从SQL翻译成mapreduce作业的话，那么其实你会看出来整个流程都是非常相似的，那么在SQL on hadoop框架里面的那么多框架，只要是基于SQL的，他的大概流程都是这样子的，从SQL解析过后成为一个抽象语法树，然后再到了逻辑执行计划，然后逻辑执行计划优化，再到物理执行计划，再到物理执行计划的优化，最终生成你对应框架的作业，有可能是mapreduce作业，可能是spark作业，提交到对应的集群上运行就可以了。 Presto prestodb.io
Presto支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。 Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark SQL有很大的相似性大数据引擎，这是它区别于Hive的最根本的区别。 Presto由于是基于内存的，而 Hive 是在磁盘上读写的，因此 presto 比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误。 Apache Kylin? kylin.apache.org/cn Apache Kylin?是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表。 Kylin 提供与多种数据可视化工具的整合能力，如 Tableau，PowerBI 等，令用户可以使用 BI 工具对 Hadoop 数据进行分析。
简单的讲解一下上面的架构图，以Hive或者Kafka作为数据源，里面保存着真实表，而Kylin做的就是将数据进行抽象，通过引擎实现Cube的构建。将Hbase作为数据的仓库，存放Cube。因为Hbase的直接读取比较复杂，所以Kylin提供了近似SQL和HQL的形式，满足了数据读取的基本需求。对外提供了RestApi和JDBC/ODBC方便操作。
Kylin自身就是一个MOLAP系统，多维立方体（MOLAP Cube）的设计使得用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。立方体的设计，我的理解是就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有N个纬度，就会有2的N次种组合。所以最好事先控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。 Impala impala.apache.org Impala 是 Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。
执行流程 1、基于内存进行计算，能够对PB级数据进行交互式实时查询、分析 2、无需转换为MR，直接读取HDFS及Hbase数据 ,从而大大降低了延迟。 Impala没有MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成 3、C++编写，LLVM统一编译运行 在底层对硬件进行优化， LLVM：编译器，比较稳定，效率高 4、兼容HiveSQL 支持hive基本的一些查询等，hive中的一些复杂结构是不支持的 5、具有数据仓库的特性，可对hive数据直接做数据分析 6、支持Data Local 数据本地化：无需数据移动，减少数据的传输 7、支持列式存储 可以和Hbase整合：因为Hive可以和Hbasez整合 8、支持JDBC/ODBC远程访问 Impala劣势 1、对内存依赖大 只在内存中计算，官方建议128G(一般64G基本满足)，可优化: 各个节点汇总的节点(服务器)内存选用大的，不汇总节点可小点 2、C++编写 开源 ？ 对于java, C++可能不是很了解 3、完全依赖hive 4、实践过程中分区超过1w 性能严重下下降 定期删除没有必要的分区，保证分区的个数不要太大 5、稳定性不如hive 因完全在内存中计算，内存不够，会出现问题, hive内存不够，可使用外存 Druid druid.apache.org 说起 Druid，大家首先想到的是阿里的 Druid 数据库连接池，而本文介绍的 Druid 是一个在大数据场景下的解决方案，是需要在复杂的海量数据下进行交互式实时数据展现的 BI/OLAP 工具。
Druid 的架构是 Lambda 架构，分成实时层( Overlord、 MiddleManager )和批处理层( Broker 和 Historical )。 更多关于架构的描述，可以看官方文档或者 《Druid在有赞的实践》 目前 Druid 广泛应用在国内外各个公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。Druid 之所以能够在 OLAP 家族中占据一席之地，主要依赖其强大的 MPP 架构设计。初次之外，它还运用到了四点重要的技术，分别是：预聚合、列式存储、字典编码、位图索引。 常见的应用场景：（druid.apache.org/use-cases） Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。 （druid.apache.org/technology） 什么样的业务适合用 Druid? 建议如下： Clickhouse clickhouse.tech Clickhouse 由俄罗斯 yandex 公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse 日处理记录数"十亿级"。 这个列式存储数据库的跑分要超过很多流行的商业MPP数据库软件，例如Vertica。 特性： 1.真正的面向列的DBMS 2.数据压缩 3.磁盘存储的数据 览量和会话。 4.多核并行处理 5.在多个服务器上分布式处理 6.SQL支持 7.向量化引擎 8.实时数据更新 9.索引 10.支持在线查询 11.支持近似计算 12.数据复制和对数据完整性的支持。 使用ClickHouse也有其本身的限制，包括： 目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
