主流大数据OLAP框架对比
原创主流大数据OLAP框架对比
原创
什么是OLAP ?
随着互联网、物联网、5G、人工智能、云计算等技术的不断发展，越来越多的数据在互联网上产生，对互联网的运营也开始进入精细化，因此大数据、数据分析、数字营销开始变成每个互联网企业的重点。在做数据分析时有OLAP、OLTP是我们必定会遇到的技术，在介绍OLAP引擎技术选型之前，我们先看看这两个技术分别是什么意思？
OLTP（OnlineTransactionProcessing联机事务处理），是传统关系型数据库的应用技术，提供日常的、基本的事务处理，比如在线交易之类。OLAP（OnlineAnalyticalProcessing联机分析处理），是大数据分析的应用技术，提供复杂的分析操作、侧重决策支持。目前主流的OLAP引擎包括Hive、Presto、Druid、Clickhouse、Kylin、Sparksql、Greeplum，每个引擎都有它各自的特点
OLAP（On-line Analytical Processing，联机分析处理）是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：
OLAP 分类
OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的 OLAP 可以分为3类：
1.多维OLAP ( Multi-dimensional OLAP )、
2.关系型OLAP ( Relational OLAP )
3.混合OLAP ( Hybrid OLAP ) 三大类。
1.多维OLAP ( Multi-dimensional OLAP )
MOLAP基于直接支持多维数据和操作的本机逻辑模型。数据物理上存储在多维数组中, 并且使用定位技术来访问它们。
MOLAP架构包含了数据库服务器、MOLAP服务器和前端工具三个组件。
MOLAP的典型代表是：Druid 和 Kylin。MOLAP一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。
MOLAP 的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即使计算，提升了查询性能。
但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时，这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。
因此，MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告主经常使用的广告投放报表分析。
2.关系型OLAP ( Relational OLAP )
关系OLAP（ROLAP）是中间服务器, 它们位于关系后端服务器和用户前端工具之间，其使用关系或扩展关系DBMS来保存和处理仓库数据, 并使用OLAP中间件来提供丢失的数据。
ROLAP的体系结构如下图，其中包含了数据库服务器、ROLAP服务器和前端工具。
ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL。
ROLAP的优势在于以下两个方面：
第一，在数据写入时，ROLAP并未使用像MOLAP那样的预聚合技术。ROLAP收到Query请求时，会先解析Query，生成执行计划，扫描数据，执行关系型算子，在原始数据上做过滤(Where)、聚合(Sum, Avg, Count)、关联(Join)，分组（Group By)、排序（Order By）等，最后将结算结果返回给用户，整个过程都是即时计算，没有预先聚合好的数据可供优化查询速度，拼的都是资源和算力的大小。
第二，ROLAP 不需要进行数据预处理 ( pre-processing )，因此查询灵活，可扩展性好。这类引擎使用 MPP 架构 ( 与Hadoop相似的大型并行处理架构，可以通过扩大并发来增加计算资源 )，可以高效处理大量数据。
但是ROLAP也存在着劣势，那就是当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发 ( 没有预处理 )，因此会耗费更多的计算资源，带来潜在的重复计算。
因此，ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性。
3.混合OLAP ( Hybrid OLAP )
混合 OLAP，是 MOLAP 和 ROLAP 的一种融合。当查询聚合性数据的时候，使用MOLAP 技术；当查询明细数据时，使用 ROLAP 技术。在给定使用场景的前提下，以达到查询性能的最优化。混合OLAP的技术体系架构如下图：
混合 OLAP的优势在于其很好的结合了MOLAP和ROLAP的优势之处，并且提供了所有聚合级别的快速访问。同时因为它仅将聚合信息存储在OLAP服务器上, 而详细记录保留在关系数据库中。因此, 不会保留详细记录的重复副本，平衡了磁盘空间需求。
混合 OLAP的劣势恰恰在于其由于集成了MOLAP和ROLAP，因此需要同时支持MOLAP和ROLAP，并且本身的体系结构也非常复杂。
4.Others
除此之外，还包含一些其他分类，包括启用Web的OLAP（WOLAP），桌面OLAP（DOLAP），移动OLAP（MOLAP）和空间OLAP（SOLAP）。但总体上不太流行，故此不再进行介绍。
OLAP 架构
概念说明
- Serde：序列化反序列化,serialize/deSerialize
- MPP：大规模并行处理技术 (Massively Parallel Processor)
- 按照查询类型划分，OLAP 一般分为即席查询和固化查询，
- 即席查询:通过手写 sql 完成一些临时的数据分析需求，这类 sql 形式多变、逻辑复杂，对查询时间没有严格要求
- 固化查询：指的是一些固化下来的取数、看数需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类的 sql 固定模式，对响应时间有较高要求。
按照架构实现划分，主流的 OLAP 引擎主要有下面三类：
- MPP 架构系统(Presto/Impala/SparkSQL/Drill 等)。这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用 hive+mapreduce 架构，提高查询效率。
- 搜索引擎架构的系统(es，solr 等)，在入库时将数据转换为倒排索引，采用 Scatter-Gather 计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
- 预计算系统（Druid/Kylin 等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。 数据轨迹现有的实现方式，从业务诉求看为:每账期按照指定的查询列取数据，进行分析未结算原因，偏向固化查询的方式。但现有的实现方式为先按照查询列值查询出主表数据，再根据主表附属表的关联字段，获取查询附属表的 sql，sql 为动态拼接出来，这种方式更偏向于即席查询的实现。
需要从以下三个方面考虑框架选型：数据存储和构建、安装搭建、开发成本。
OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式，如果脱离了这两点，OLAP将不复存在，也就没有优势可言。
OLAP引擎的常见操作
下面所述几种OLAP操作，是针对Kimball的星型模型（Star Schema）和雪花模型（Snowflake Schema）来说的。在Kimball模型中，定义了事实和维度。
上卷（Roll Up）/聚合：选定某些维度，根据这些维度来聚合事实，如果用SQL来表达就是select dim_a, aggs_func(fact_b) from fact_table group by dim_a. 下钻（Drill Down）：上卷和下钻是相反的操作。它是选定某些维度，将这些维度拆解出小的维度（如年拆解为月，省份拆解为城市），之后聚合事实。 切片（Slicing、Dicing）：选定某些维度，并根据特定值过滤这些维度的值，将原来的大Cube切成小cube。如dim_a in (‘CN’, ‘USA’) 旋转（Pivot/Rotate）：维度位置的互换。 下图举了一个具体的例子：
执行模型对比
- Scatter-Gather执行模型：相当于MapReduce中的一趟Map和Reduce，没有多轮的迭代，而且中间计算结果往往存储在内存中，通过网络直接交换。Elasticsearch、Druid、Kylin都是此模型。
- MapReduce：Hive是此模型
- MPP：MPP学名是大规模并行计算，其实很难给它一个准确的定义。如果说的宽泛一点，Presto、Impala、Doris、Clickhouse、Spark SQL、Flink SQL这些都算。有人说Spark SQL和Flink SQL属于DAG模型，我们思考后认为，DAG并不算一种单独的模型，它只是生成执行计划的一种方式。
开源OLAP引擎对比
针对于目前大数据业内非常流行的数个开源OLAP引擎：Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Doris、Presto、Impala分别挑选了一些场景进行了对比，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。
组件特点和简介
Hive
https://hive.apache.org/
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
对于hive主要针对的是OLAP应用，其底层是hdfs分布式文件系统，hive一般只用于查询分析统计，而不能是常见的CUD操作，Hive需要从已有的数据库或日志进行同步最终入到hdfs文件系统中，当前要做到增量实时同步都相当困难。
Hive的优势是完善的SQL支持，极低的学习成本，自定义数据格式，极高的扩展性可轻松扩展到几千个节点等等。
但是Hive 在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些 Key 建立索引。Hive 要访问数据中满足条件的特定值时，需要暴力扫描整个数据库，因此访问延迟较高。
Hive真的太慢了。大数据量聚合计算或者联表查询，Hive的耗时动辄以小时计算，在某一个瞬间，我甚至想把它开除出OLAP"国籍"，但是不得不承认Hive仍然是基于Hadoop体系应用最广泛的OLAP引擎。
Spark SQL、Flink SQL
在大部分场景下，Hive计算还是太慢了，别说不能满足那些要求高QPS、低查询延迟的的对外在线服务的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨Hive执行ad-hoc查询太慢。这些痛点，推动了MPP内存迭代和DAG计算模型的诞生和发展，诸如Spark SQL、Flink SQL、Presto这些技术，目前在企业中也非常流行。Spark SQL、Flink SQL的执行速度更快，编程API丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。 注：上面说的在线服务，指的是如阿里对几百万淘宝店主开放的数据应用生意参谋，腾讯对几十万广告主开发的广点通广告投放分析等。
Presto
这是Presto官方的简介。Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，适用于交互式分析查询，可支持众多的数据源，包括 HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口开发数据源连接器。
Presto支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。
Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark SQL有很大的相似性，这是它区别于Hive的最根本的区别。
但Presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误
Presto、Impala、GreenPlum均基于MPP架构，相比Elasticsearch、Druid、Kylin这样的简单Scatter-Gather模型，在支持的SQL计算上更加通用，更适合ad-hoc查询场景，然而这些通用系统往往比专用系统更难做性能优化，所以不太适合做对查询QPS(参考值QPS > 1000)、延迟要求比较高(参考值search latency < 500ms)的在线服务，更适合做公司内部的查询服务和加速Hive查询的服务。Presto还有一个优秀的特性是使用了ANSI标准SQL，并且支持超过30+的数据源Connector。这里我们给读者留下一个思考题：以Presto为代表的MPP模型与Hive为代表的MapReduce模型的性能差异比较大的原因是什么？
Presto 和 Hive 代表了两种不同的数据处理架构，分别是 MPP（Massively Parallel Processing）和 MapReduce。性能差异主要由以下几个因素造成：
- 并行性：MPP 架构下的 Presto 支持并行处理，可以在多个节点上同时执行查询任务，从而提高了查询的并发性和性能。相比之下，Hive 的 MapReduce 任务在执行时会依赖于磁盘 IO，处理数据的速度较慢。
- 内存管理：Presto 使用内存作为主要的计算资源，能够更高效地利用内存进行数据处理和计算，而 Hive 在执行 MapReduce 任务时需要频繁地进行磁盘读写操作，导致性能相对较低。
- 查询优化：Presto 提供了更多的查询优化功能，包括动态分区裁剪、谓词下推、动态过滤等，可以更智能地执行查询并减少不必要的数据扫描和计算，而 Hive 的优化能力相对较弱。
Impala
Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查询工具，是CDH 平台首选的 PB 级大数据实时查询分析引擎。它拥有和Hadoop一样的可扩展性、它提供了类SQL（类Hsql）语法，在多用户场景下也能拥有较高的响应速度和吞吐量。它是由Java和C++实现的，Java提供的查询交互的接口和实现，C++实现了查询引擎部分，除此之外，Impala还能够共享Hive Metastore，甚至可以直接使用Hive的JDBC jar和beeline等直接对Impala进行查询、支持丰富的数据存储格式（Parquet、Avro等）。此外，Impala 没有再使用缓慢的 Hive+MapReduce 批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成），可以直接从 HDFS 或 HBase 中用 SELECT、JOIN 和统计函数查询数据，从而大大降低了延迟。Impala经常搭配存储引擎Kudu一起提供服务，这么做最大的优势是点查比较快，并且支持数据的Update和Delete。 注：部分内容来自https://zhuanlan.zhihu.com/p/55197560
Impala的特性包括：
- 支持Parquet、Avro、Text、RCFile、SequenceFile等多种文件格式
- 支持存储在HDFS、HBase、Amazon S3上的数据操作
- 支持多种压缩编码方式：Snappy、Gzip、Deflate、Bzip2、LZO
- 支持UDF和UDAF
- 自动以最有效的顺序进行表连接
- 允许定义查询的优先级排队策略
- 支持多用户并发查询
- 支持数据缓存
- 提供计算统计信息（COMPUTE STATS）
- 提供窗口函数（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高级分析功能
- 支持使用磁盘进行连接和聚合，当操作使用的内存溢出时转为磁盘操作
- 允许在where子句中使用子查询
- 允许增量统计——只在新数据或改变的数据上执行统计计算
- 支持maps、structs、arrays上的复杂嵌套查询
- 可以使用impala插入或更新HBase
Druid
https://druid.apache.org/
https://blog.csdn.net/warren288/article/details/80629909
Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。
Druid解决的问题包括：数据的快速摄入和数据的快速查询。 所以要理解Druid，需要将其理解为两个系统，即输入系统和查询系统。
Druid的架构如下：
Druid的特点包括：
- Druid实时的数据消费，真正做到数据摄入实时、查询结果实时
- Druid支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发
- Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景
- Druid把数据列分为三类：时间戳、维度列、指标列
- Druid支持多表连接, 但是支持的不够好
- Druid中的数据一般是使用其他计算框架(Spark等)预计算好的低层次统计数据
- Druid不适合用于处理透视维度复杂多变的查询场景
- Druid擅长的查询类型比较单一，一些常用的SQL(groupby 等)语句在druid里运行速度一般
- Druid支持低延时的数据插入、更新，但是比hbase、传统数据库要慢很多
与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等。
我个人对Druid的理解在于，Druid保证数据实时写入，适合将清洗好的记录实时录入，然后迅速查询包含历史的结果，在我们目前的业务上没有实际应用。
Druid的应用可以参考： 《Druid 在有赞的使用场景及应用实践》https://blog.csdn.net/weixin_34273481/article/details/89238947
Kylin
http://kylin.apache.org/cn/ https://www.infoq.cn/article/kylin-apache-in-meituan-olap-scenarios-practice/
提到Kylin就不得不说说ROLAP和MOLAP。
- 传统OLAP根据数据存储方式的不同分为ROLAP（relational olap）以及MOLAP（multi-dimension olap）
- ROLAP 以关系模型的方式存储用作多为分析用的数据，优点在于存储体积小，查询方式灵活，然而缺点也显而易见，每次查询都需要对数据进行聚合计算，为了改善短板，ROLAP使用了列存、并行查询、查询优化、位图索引等技术。
- MOLAP 将分析用的数据物理上存储为多维数组的形式，形成CUBE结构。维度的属性值映射成多维数组的下标或者下标范围，事实以多维数组的值存储在数组单元中，优势是查询快速，缺点是数据量不容易控制，可能会出现维度爆炸的问题。
而Kylin自身就是一个MOLAP系统，多维立方体（MOLAP Cube）的设计使得用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。
Apache Kylin?是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
Kylin的优势有：
- 提供ANSI-SQL接口
- 交互式查询能力
- MOLAP Cube 的概念
- 与BI工具可无缝整合
所以适合Kylin的场景包括：
- 用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上
- 每天有数G甚至数十G的数据增量导入
- 有10个以内较为固定的分析维度
简单来说，Kylin中数据立方的思想就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有N个纬度，就会有2的N次种组合。所以最好控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。
ClickHouse
https://clickhouse.yandex/
https://clickhouse.yandex/docs/zh/development/architecture/
http://www.clickhouse.com.cn/
https://www.jianshu.com/p/a5bf490247ea
官网对ClickHouse的介绍：
ClickHouse is an open source column-oriented database management system capable of real time generation of analytical data reports using SQL queries.
ClickHouse最大的特点就是快，快，快，重要的话说三遍！
ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。目前国内社区火热，各个大厂纷纷跟进大规模使用：
- 今日头条 内部用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。
- 腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。
- 携程内部从18年7月份开始接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。
- 快手内部也在使用ClickHouse，存储总量大约10PB， 每天新增200TB， 90%查询小于3S。
在国外，Yandex内部有数百节点用于做用户点击行为分析，CloudFlare、Spotify等头部公司也在使用。 ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。 注：内容来自https://zhuanlan.zhihu.com/p/98135840 ClickHouse部署架构简单，易用，不依赖Hadoop体系（HDFS+YARN）。它比较擅长的地方是对一个大数据量的单表进行聚合查询。Clickhouse用C++实现，底层实现具备向量化执行（Vectorized Execution）、减枝等优化能力，具备强劲的查询性能。目前在互联网企业均有广泛使用，比较适合内部BI报表型应用，可以提供低延迟（ms级别）的响应速度，也就是说单个查询非常快。但是Clickhouse也有它的局限性，在OLAP技术选型的时候，应该避免把它作为多表关联查询(JOIN)的引擎，也应该避免把它用在期望支撑高并发数据查询的场景，OLAP分析场景中，一般认为QPS达到1000+就算高并发，而不是像电商、抢红包等业务场景中，10W以上才算高并发，毕竟数据分析场景，数据海量，计算复杂，QPS能够达到1000已经非常不容易。例如Clickhouse，如果如数据量是TB级别，聚合计算稍复杂一点，单集群QPS一般达到100已经很困难了，所以它更适合企业内部BI报表应用，而不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。Clickhouse的执行模型决定了它会尽全力来执行一个Query，而不是同时执行很多Query。
与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点：
- 列式存储数据库，数据压缩
- 关系型、支持SQL
- 分布式并行计算，把单机性能压榨到极限
- 高可用
- 数据量级在PB级别
- 实时数据更新
- 索引
使用ClickHouse也有其本身的限制，包括：
- 缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。
- 没有完整的事务支持
- 不支持二级索引
- 有限的SQL支持，join实现与众不同
- 并发度不高，它更适合企业内部BI报表应用
Doris
总结 我以为，我们在这里所做的各个OLAP引擎的介绍和分析，并不一定100%合理准确，只是一种参考。只有真正有OLAP线上经验的人，在特定业务场景、特定数据量的，有过深入优化以上介绍的一种或者几种OLAP引擎经验的专家，才有相应的发言权来给出技术选型的建议。但是由于这些OLAP引擎技术方案太多，不可能有哪个专家全都精通。以我个人为例，过往的工作经验使我在Hive、SparkSQL、FlinkSQL、Presto、Elasticsearch这几个方面更了解，其他的引擎不敢瞎说自己懂，不构成技术选型的建议。所以大概每个专家说的都不准确、不全面，我们在这里鼓励大家多讨论和评论，多提问题，成为各个OLAP引擎方面的专家。
参考资料
/developer/article/1797949
https://doris.apache.org/zh-CN/docs/get-starting/quick-start
/developer/article/1899164?areaId=106001
/developer/article/1506296?areaId=106001
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。