随着大数据技术在各行各业的深刻利用，对于海量数据的剖析需要也更加凸显，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 引擎进行了介绍和比照，然而对于最终在技术选型上如何抉择适合的大数据引擎，还是须要用户依据理论状况进行抉择。只凭借本篇文章，还无奈作为选型的倡议。