随着大数据技术在各行各业的深刻利用，对于海量数据的剖析需要也更加凸显，OLAP技术也逐步走入人们的视线。本文将围绕常见的开源OLAP引擎开展，介绍什么是OLAP以及OLAP的常见操作和分类，并对目前支流的开源OLAP引擎进行比照和特点的总结。

一、什么是OLAP

OLAP（On-line Analytical Processing，联机剖析解决）是在基于数据仓库多维模型的根底上实现的面向剖析的各类操作的汇合。能够比拟下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

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）：维度地位的调换。

下图举了一个具体的例子：

三、OLAP分类

OLAP 是一种让用户能够用从不同视角方便快捷的剖析数据的计算方法。支流的 OLAP 能够分为3类：多维OLAP ( Multi-dimensional OLAP )、关系型OLAP ( Relational OLAP ) 和混合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引擎比照

针对于目前大数据业内十分风行的数个开源OLAP引擎：Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Presto、Impala别离筛选了一些场景进行了比照，能够说目前没有一个引擎能在数据量，灵便水平和性能上做到完满，用户须要依据本人的需要进行选型。

1.并发能力与查问提早比照

看到这里可能有人会提出疑难：Hive，SparkSQL，FlinkSQL这些它们要么查问速度慢，要么QPS上不去，怎么能算是OLAP引擎呢？其实OLAP的定义中并没有对于查问执行速度和QPS的限定。进一步来说，这里引出了掂量OLAP特定业务场景的两个重要的指标：

  • 查问速度：Search Latency
  • 查问并发能力：QPS

如果依据不同的查问场景、再依照查问速度与查问并发能力这两个指标来划分以上所列的OLAP引擎，这些OLAP引擎的能力划分如下：

场景一：简略查问

简略查问指的是点查、简略聚合查问或者数据查问可能命中索引或物化视图（物化视图指的是物化的查问两头后果，如预聚合数据）。这样的查问经常出现在【在线数据服务】的企业应用中，如阿里生意顾问、腾讯的广点通、京东的广告业务等，它们独特的特点是对外服务、面向B端商业客户（通常是几十万的级别）；并发查问量(QPS)大；对响应工夫要求高，个别是ms级别（能够设想一下，如果广告主查问页面投放数据，如果10s还没有后果，很挫伤体验）；查问模式绝对固定且简略。从下图可知，这种场景最合适的是Elasticsearch、Druid、Kylin。
![上传中...]()

场景二：简单查问

简单查问指的是简单聚合查问、大批量数据SCAN、简单的查问（如JOIN）。在ad-hoc场景中，常常会有这样的查问，往往用户不能事后晓得要查问什么，更多的是摸索式的。这里也依据QPS和查问耗时分几种状况，如下图所示，依据业务的需要来抉择对应的引擎即可。有一点要提的是FlinkSQL和SparkSQL尽管也能实现相似需要，然而它们目前还不是开箱即用，须要做周边生态建设，这两种技术目前更多的利用场景还是在通过操作灵便的编程API来实现流式

2.执行模型比照

  • Scatter-Gather执行模型：相当于MapReduce中的一趟Map和Reduce，没有多轮的迭代，而且两头计算结果往往存储在内存中，通过网络间接替换。Elasticsearch、Druid、Kylin都是此模型。
  • MapReduce：Hive采纳的正是这个模型。
  • MPP：MPP学名是大规模并行计算，其实很难给它一个精确的定义。如果说的宽泛一点，Presto、Impala、Clickhouse、Spark SQL、Flink SQL这些都算。有人说Spark SQL和Flink SQL属于DAG模型，咱们思考后认为，DAG并不算一种独自的模型，它只是生成执行打算的一种形式。

五、支流开源OLAP引擎的次要特点

1.Hive

Hive是一个分布式SQL on Hadoop计划，底层依赖MapReduce计算模型执行分布式计算。Hive善于执行长时间运行的离线批处理，数据量越大，劣势越显著。Hive在数据量大、数据驱动需要强烈的互联网大厂比拟风行。近2年，随着Clickhouse的逐步风行，对于一些总数据量不超过百PB级别的互联网数据仓库需要，曾经有多家公司改为了Clickhouse的计划。Clickhouse的劣势是单个查问执行速度更快，不依赖Hadoop，架构和运维更简略。

2.Spark SQL、Flink SQL

在大部分场景下，Hive计算速度过慢，别说不能满足那些要求高QPS、低查问提早的的对外在线服务的需要，就连企业外部的产品、经营、数据分析师也会常常埋怨Hive执行ad-hoc查问太慢。这些痛点，推动了MPP内存迭代和DAG计算模型的诞生和倒退，诸如Spark SQL、Flink SQL、Presto这些技术，目前在企业中也十分风行。Spark SQL、Flink SQL的执行速度更快，编程API丰盛，同时反对流式计算与批处理，并且有流批对立的趋势，使大数据利用更简略。

3.Clickhouse

ClickHouse是近年来备受关注的开源列式数据库，次要用于数据分析（OLAP）畛域。目前国内社区炽热，各个大厂纷纷跟进大规模应用。

ClickHouse从OLAP场景需要登程，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稠密索引、数据Sharding、数据Partitioning、TTL、主备复制等丰盛性能。以上性能独特为ClickHouse极速的剖析性能奠定了根底。

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。

4.Elasticsearch

提到Elasticsearch，很多人的印象是这是一个开源的分布式搜索引擎，底层依靠Lucene倒排索引构造，并且反对文本分词，非常适合作为搜寻服务。并且用Elasticsearch作为搜索引擎，一个三节点的集群，撑持1000+的查问QPS也不是什么难事，这是搜寻场景。

然而，咱们这里要讲的内容是Elasticsearch的另一个性能，即作为聚合（aggregation）场景的OLAP引擎，它与搜寻型场景区别很大。聚合场景，能够等同于select c1, c2, sum(c3), count(c4) from table where c1 in ('china', 'usa') and c2 < 100 这样的SQL，也就是做多维度分组聚合。尽管Elasticsearch DSL是一个简单的JSON而不是SQL，然而意思雷同，能够相互转换。

用Elasticsearch作为OLAP引擎，有几项劣势：（1）善于高QPS（QPS > 1K）、低提早、过滤条件多、查问模式简略（如点查、简略聚合）的查问场景。（2）集群自动化治理能力（shard allocation，recovery）能力十分强。集群、索引治理和查看的API十分丰盛。

ES的执行引擎是最简略的Scatter-Gather模型，相当于MapReduce计算模型的一趟Map和Reduce。Scatter和Gather之间的节点数据交换也是基于内存的不会像MapReduce那样每次Shuffle要先落盘。ES底层依赖的Lucene文件格式，咱们能够把Lucene了解为一种行列混存的模式，并且在查问时通过FST，跳表等放慢数据查问。这种Scatter-Gather模型的问题是，如果Gather/Reduce的数据量比拟大，因为ES是单节点执行，可能会十分慢。整体来讲，ES是通过就义灵活性，进步了简略OLAP查问的QPS、升高了提早。

用Elasticsearch作为OLAP引擎，有几项劣势：多维度分组排序、分页。不反对Join。在做aggregation后，因为返回的数据嵌套档次太多，数据量会过于收缩。

ElasticSearch和Solar也能够归为宽表模型。但其零碎设计架构有较大不同，这两个个别称为搜索引擎，通过倒排索引，利用Scatter-Gather计算模型进步查问性能。对于搜寻类的查问成果较好，但当数据量较大或进行扫描聚合类查问时，查问性能会有较大影响。

5.Presto

Presto、Impala、GreenPlum均基于MPP架构，相比Elasticsearch、Druid、Kylin这样的简略Scatter-Gather模型，在反对的SQL计算上更加通用，更适宜ad-hoc查问场景，然而这些通用零碎往往比专用零碎更难做性能优化，所以不太适宜做对查问QPS(参考值QPS > 1000)、提早要求比拟高(参考值search latency < 500ms)的在线服务，更适宜做公司外部的查问服务和减速Hive查问的服务。Presto还有一个优良的个性是应用了ANSI规范SQL，并且反对超过30+的数据源Connector。

6.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。

7.Druid

Druid 是一种能对历史和实时数据提供亚秒级别的查问的数据存储。Druid 反对低延时的数据摄取，灵便的数据摸索剖析，高性能的数据聚合，简便的程度扩大。Druid反对更大的数据规模，具备肯定的预聚合能力，通过倒排索引和位图索引进一步优化查问性能，在广告剖析场景、监控报警等时序类利用均有宽泛应用；

Druid的特点包含：

Druid实时的数据生产，真正做到数据摄入实时、查问后果实时

Druid反对 PB 级数据、千亿级事件疾速解决，反对每秒数千查问并发

Druid的外围是工夫序列，把数据依照工夫序列分批存储，非常适宜用于对按工夫进行统计分析的场景

Druid把数据列分为三类：工夫戳、维度列、指标列

Druid不反对多表连贯

Druid中的数据个别是应用其余计算框架(Spark等)预计算好的低层次统计数据

Druid不适宜用于解决透视维度复杂多变的查问场景

Druid善于的查问类型比拟繁多，一些罕用的SQL(groupby 等)语句在druid里运行速度个别

Druid反对低延时的数据插入、更新，然而比hbase、传统数据库要慢很多

与其余的时序数据库相似，Druid在查问条件命中大量数据状况下可能会有性能问题，而且排序、聚合等能力广泛不太好，灵活性和扩展性不够，比方不足Join、子查问等。

8.Kylin

Kylin本身就是一个MOLAP零碎，多维立方体（MOLAP Cube）的设计使得用户可能在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。

适宜Kylin的场景包含：

用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据形式存取，数据量微小，在500G以上

每天无数G甚至数十G的数据增量导入

有10个以内较为固定的剖析维度

简略来说，Kylin中数据立方的思维就是以空间换工夫，通过定义一系列的纬度，对每个纬度的组合进行事后计算并存储。有N个纬度，就会有2的N次种组合。所以最好管制好纬度的数量，因为存储量会随着纬度的减少爆炸式的增长，产生灾难性结果。

六、总结

本文通过介绍了什么是OLAP以及OLAP的分类，从而对目前支流的8款OLAP引擎进行了介绍和比照，然而对于最终在技术选型上如何抉择适合的大数据引擎，还是须要用户依据理论状况进行抉择。只凭借本篇文章，还无奈作为选型的倡议。