选择适合自己的 OLAP 引擎



摘要：本文主要介绍了主流开源的OLAP引擎：Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等，逐一介绍了每一款开源 OLAP 引擎，包含架构、优缺点、使用场景等，希望可以给大家有所启发。

PS: 文章较长，建议收藏慢慢看。



说起 OLAP 要追溯到 1993 年。



• 准则1 OLAP模型必须提供多维概念视图

• 准则2 透明性准则

• 准则3 存取能力准则

• 准则4 稳定的报表能力

• 准则5 客户/服务器体系结构

• 准则6 维的等同性准则

• 准则7 动态的稀疏矩阵处理准则

• 准则8 多用户支持能力准则

• 准则9 非受限的跨维操作

• 准则10 直观的数据操纵

• 准则11 灵活的报表生成

• 准则12 不受限的维与聚集层次



OLAP场景的关键特征



• 大多数是读请求

• 数据总是以相当大的批(> 1000 rows)进行写入

• 不修改已添加的数据

• 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列

• 宽表，即每个表包含着大量的列

• 较少的查询(通常每台服务器每秒数百个查询或更少)

• 对于简单查询，允许延迟大约50毫秒

• 列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)

• 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）

• 事务不是必须的

• 对数据一致性要求低

• 每一个查询除了一个大表外都很小

• 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中



与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内存不够，可使用外存

• Impala不提供任何对序列化和反序列化的支持。

• Impala只能读取文本文件，而不能读取自定义二进制文件。

• 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。



Druid  druid.apache.org



说起 Druid，大家首先想到的是阿里的 Druid 数据库连接池，而本文介绍的 Druid 是一个在大数据场景下的解决方案，是需要在复杂的海量数据下进行交互式实时数据展现的 BI/OLAP 工具。





Druid 的架构是 Lambda 架构，分成实时层( Overlord、 MiddleManager )和批处理层( Broker 和 Historical )。



更多关于架构的描述，可以看官方文档或者 《Druid在有赞的实践》



目前 Druid 广泛应用在国内外各个公司，比如阿里，滴滴，知乎，360，eBay，Hulu 等。Druid 之所以能够在 OLAP 家族中占据一席之地，主要依赖其强大的 MPP 架构设计。初次之外，它还运用到了四点重要的技术，分别是：预聚合、列式存储、字典编码、位图索引。



常见的应用场景：（https://druid.apache.org/use-cases）

• 点击流分析（网络和移动分析）

• 风险/欺诈分析

• 网络遥测分析（网络性能监控）

• 服务器指标存储

• 供应链分析（制造指标）

• 应用程序性能指标

• 商业智能/ OLAP



Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。

（https://druid.apache.org/technology）



什么样的业务适合用 Druid?

建议如下：

• 时序化数据：Druid 可以理解为时序数据库，所有的数据必须有时间字段。

• 实时数据接入可容忍丢数据(tranquility)：目前 tranquility 有丢数据的风险，所以建议实时和离线一起用，实时接当天数据，离线第二天把今天的数据全部覆盖，保证数据完备性。

• OLAP 查询而不是 OLTP 查询：Druid 查询并发有限，不适合 OLTP 查询。

• 非精确的去重计算：目前 Druid 的去重都是非精确的。

• 无 Join 操作：Druid 适合处理星型模型的数据，不支持关联操作。

• 数据没有 update 更新操作，只对 segment 粒度进行覆盖：由于时序化数据的特点，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也有其本身的限制，包括：

• 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。

• 没有完整的事务支持

• 不支持二级索引

• 有限的SQL支持，join实现与众不同

• 不支持窗口功能

• 元数据管理需要人工干预维护



目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。



参考

https://xie.infoq.cn/article/77ec0d231d36c963a8e6d1630

https://www.jianshu.com/p/26c18e6a30c3

https://www.jianshu.com/p/4d0e0b42a3b0

https://www.jianshu.com/p/257ff24db397

https://www.cnblogs.com/tgzhu/p/6033373.html

https://zhuanlan.zhihu.com/p/29385628

https://blog.csdn.net/yongshenghuang/article/details/84925941https://www.jianshu.com/p/b5c85cadb362

https://clickhouse.yandex/docs/zh/development/architecture/

http://www.clickhouse.com.cn

https://www.jianshu.com/p/a5bf490247ea

https://blog.csdn.net/weixin_34273481/article/details/89238947

https://blog.csdn.net/warren288/article/details/80629909



往期推荐



2020 年 Flink 最佳学习路线，学习的路上，你，并不孤单

Apache Flink OLAP引擎性能优化及应用【干货】趣头条基于 Flink+ClickHouse 构建实时数据分析平台

来了来了，2020 首场 Meetup ，可！

本地Spark连接远程集群Hive(Scala/Python)Spark 性能优化指南(官网文档)





关注我，带你不同角度看数据架构