常见开源OLAP技术架构对比

1.OLAP

On-line Analytical Processing，联机分析处理是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

数据处理类型	OLTP	OLAP
面向对象	业务开发人员	分析决策人员
数据模型	关系模型	多维模型
操作数据量	几条或者几十条	百万千万条记录
操作类型	增删改查	查询为主
主要衡量指标	事务吞吐量	查询响应速度（QPS）

2.OLAP的基本操作

　　我们已经知道OLAP的操作是以查询——也就是数据库的SELECT操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用COUNT、SUM、AVG等聚合函数。OLAP正是基于多维模型定义了一些常见的面向分析的操作类型是这些操作显得更加直观。

　　OLAP的多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），下面还是以上面的数据立方体为例来逐一解释下：

3.OLAP分类

OLAP 是一种让用户可以用从不同视角方便快捷的分析数据的计算方法。主流的 OLAP 可以分为3类：多维 OLAP ( Multi-dimensional OLAP )、关系型 OLAP ( Relational OLAP ) 和混合 OLAP ( Hybrid OLAP ) 三大类。

3.1 MOLAP

MOLAP的典型代表是：Druid，Kylin，Doris，MOLAP一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。

MOLAP 的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即时计算，提升了查询性能。

但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高；同时这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。

因此，MOLAP 适用于查询场景相对固定并且对查询性能要求非常高的场景。如广告主经常使用的广告投放报表分析。

3.2 ROLAP

ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL

数据写入时，ROLAP并未使用像MOLAP那样的预聚合技术；ROLAP收到Query请求时，会先解析Query，生成执行计划，扫描数据，执行关系型算子，在原始数据上做过滤(Where)、聚合(Sum, Avg, Count)、关联(Join)，分组（Group By)、排序（Order By）等，最后将结算结果返回给用户，整个过程都是即时计算，没有预先聚合好的数据可供优化查询速度，拼的都是资源和算力的大小。

ROLAP 不需要进行数据预处理 ( pre-processing )，因此查询灵活，可扩展性好。这类引擎使用 MPP 架构 ( 与Hadoop相似的大型并行处理架构，可以通过扩大并发来增加计算资源 )，可以高效处理大量数据。

但是当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发 ( 没有预处理 )，因此会耗费更多的计算资源，带来潜在的重复计算。

因此，ROLAP 适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性。

3.3 HOLAP

混合 OLAP，是 MOLAP 和 ROLAP 的一种融合。当查询聚合性数据的时候，使用MOLAP 技术；当查询明细数据时，使用 ROLAP 技术。在给定使用场景的前提下，以达到查询性能的最优化。

顺便提一下，国内外有一些闭源的商业OLAP引擎，没有在这里归类和介绍，主要是因为使用的公司不多并且源码不可见、资料少，很难分析学习其中的源码和技术点。

4.OLAP引擎的对比

我们花一些篇幅来介绍和对比一下目前大数据业内非常流行的几个OLAP引擎，它们是Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Presto、Impala、Doris。可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。

4.1 查询能力对比

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

查询速度：Search Latency（常用Search Latency Pct99来衡量）
查询并发能力：QPS

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

场景一：简单查询

简单查询指的是点查、简单聚合查询或者数据查询能够命中索引或物化视图（物化视图指的是物化的查询中间结果，如预聚合数据）。这样的查询经常出现在【在线数据服务】的企业应用中，如阿里生意参谋、腾讯的广点通、京东的广告业务等，它们共同的特点是对外服务、面向B端商业客户（通常是几十万的级别）；并发查询量(QPS)大；对响应时间要求高，一般是ms级别（可以想象一下，如果广告主查询页面投放数据，如果10s还没有结果，很伤害体验）；查询模式相对固定且简单。从下图可知，这种场景最合适的是Elasticsearch、Doris、Druid、Kylin这些。

场景二：复杂查询

复杂查询指的是复杂聚合查询、大批量数据SCAN、复杂的查询（如JOIN）。在ad-hoc场景中，经常会有这样的查询，往往用户不能预先知道要查询什么，更多的是探索式的。这里也根据QPS和查询耗时分几种情况，如下图所示，根据业务的需求来选择对应的引擎即可。有一点要提的是FlinkSQL和SparkSQL虽然也能完成类似需求，但是它们目前还不是开箱即用，需要做周边生态建设，这两种技术目前更多的应用场景还是在通过操作灵活的编程API来完成流式或离线的计算上。

4.2 执行模型对比

Scatter-Gather执行模型：单节点汇聚，无法完成大表join及高基数聚合，Elasticsearch是此模型。

MapReduce：任务之间需要等待中间数据落盘，有磁盘IO的消耗，Hive是此模型。

MPP：MPP学名是大规模并行计算（Massively Parallel Processing），流水线执行无需等待，数据内存传输，无磁盘IO消耗，Doris、Druid

5.OLAP引擎的主要特点

5.1 Hive

Hive是一个分布式SQL on Hadoop方案，底层依赖MapReduce计算模型执行分布式计算。Hive擅长执行长时间运行的离线批处理，数据量越大，优势越明显。Hive在数据量大、数据驱动需求强烈的互联网大厂比较流行。近2年，随着clickhouse的逐渐流行，对于一些总数据量不超过百PB级别的互联网数据仓库需求，已经有多家公司改为了clickhouse的方案。clickhouse的优势是单个查询执行速度更快，不依赖hadoop，架构和运维更简单。

5.2 Spark SQL、Flink SQL

在大部分场景下，Hive计算还是太慢了，别说不能满足那些要求高QPS、低查询延迟的对外在线服务的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨Hive执行ad-hoc查询太慢。这些痛点，推动了MPP内存迭代和DAG计算模型的诞生和发展，诸如Spark SQL、Flink SQL、Presto这些技术，目前在企业中也非常流行。Spark SQL、Flink SQL的执行速度更快，编程API丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。

注：上面说的在线服务，指的是如阿里对几百万淘宝店主开放的数据应用生意参谋，腾讯对几十万广告主开发的广点通广告投放分析等。

5.3 Presto

Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，基于内存的低延迟高并发并行计算（MPP）引擎，适用于交互式分析查询，大部分场景比hive快一个数量级。Presto特点：

本身并不存储数据，但是可以接入多种数据源，包括 Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。
完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算。
可以混合多个catalog进行join查询和计算，支持跨数据源的级联查询。
基于PipeLine进行设计的，流水管道式数据处理，支持数据规模GB~PB，计算中拿出一部分放在内存、计算、抛出、再拿。
SQL on Hadoop：弥补Hive的效率性能和灵活性的不足，Presto和Spark SQL、Impala有很多异曲同工之处。

5.4 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。

5.5 Kylin

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

适合Kylin的场景包括：

用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上。
每天有数G甚至数十G的数据增量导入。
有10个以内较为固定的分析维度。

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

5.6 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引擎，有几项优势：

擅长高QPS（QPS > 1K）、低延迟、过滤条件多、查询模式简单（如点查、简单聚合）的查询场景。
集群自动化管理能力（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.7 Doris

架构图

Doris是百度主导的，根据Google Mesa论文和Impala项目改写的一个大数据分析引擎，在百度、美团团、京东的广告分析等业务有广泛的应用。Doris 的整体架构和 TiDB 类似，借助 MySQL 协议，用户使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客户端，都可以直接访问 Doris。

Doris数据模型在建表时就已经确定，且无法修改。所以，选择一个合适的数据模型非常重要，主要有Aggregate、Uniq、Duplicate三种模型：

Aggregate 模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。但是该模型对 count(*) 查询很不友好。同时因为固定了 Value 列上的聚合方式，在进行其他类型的聚合查询时，需要考虑语意正确性。
Uniq 模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利用 ROLLUP 等预聚合带来的查询优势（因为本质是 REPLACE，没有 SUM 这种聚合方式）。
Duplicate 适合任意维度的 Ad-hoc 查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列）。

Doris适用场景：

1、对数据分析、统计

数据分析大体上可以分为两大类场景：一种偏向于报表类的，另一种偏向于多维分析的。

2、报表

报表类数据分析，数据分析以及查询的模式相对比较固定，而且后台 SQL 的模式往往都是确定的。针对此类应用场景，选择使用 MySQL 存结果数据，用户可从界面选择执行批处理以及发送邮件。在 Doris 平台中，报表类查询时延一般在秒级以下。

3、多维分析

这里提到的多维分析，同样要求数据是结构化的，适用于查询相对灵活的场景，例如数据分析条件以及聚合维度等方面不是很确定，一般将此类数据分析定义为多维分析。相对于报表类分析，多维分析的查询时延会稍慢，大约在会在 10s 的级别。

5.8 Druid

架构图:

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

Druid的特点包括：

Druid实时的数据消费，真正做到数据摄入实时、查询结果实时。
Druid支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
Druid把数据列分为三类：时间戳（timestamp）、维度列（Dimension）、指标列（Metric）。
Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景。
Druid不支持多表连接。
Druid不适合用于处理维度复杂多变的查询场景。

5.9 Clickhouse

集群模式架构图（基于ReplicatedMergeTree+Distributed）

数据查询过程：

ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。主要特性如下：

PB级数据处理能力
列式数据存储
优秀的数据压缩
多核并行处理
多服务器分布式处理
SQL支持（部分语句有点怪）
向量化引擎
支持实时数据更新
高吞吐写入
近似计算
少依赖，上手非常容易

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。

6. 总结

简单对比下个人认为未来比较有前途的OLAP：Elasticsearch、Doris、Druid、ClickHouse

OLAP引擎	优点	缺点	运维复杂度	支持SQL	GitHub Star
Elasticsearch	搜索场景第一选择高并发、低延迟支持特殊数据类型（如IP、经纬度等）跨集群搜索数据“冷热分离” 跨集群复制（X-pack）数据Roll up（X-pack）完善的集群管理机制	多维度聚合性能一般耗内存：索引信息、cache 写放大问题：磁盘空间占用大	低	有限支持	56k
Doris	MPP架构向量化执行引擎高效的聚集表技术预聚合Roll up 支持更新表Schema	开源版本还没有从apache毕业生态待完善	低	支持标准SQL，兼容MySQL协议	3.4k
Druid	MPP架构实时/批量数据摄入支持较高并发数据预聚合	运维部署复杂，有6种进程服务对高基数聚合和精确去重支持不好不支持根据主键的单条记录更新	高	有限支持	11k
ClickHouse	多核并行处理向量化执行引擎实时数据更新数据压缩比高单表查询性能高数据“冷热分离” 跨集群复制丰富的表引擎数据预聚合	并发不高（QPS小于100）不适合通过其键检索单行的点查询多副本之间的数据同步依赖zookeeper 分片与副本功能完全靠配置文件实现，无法自动管理，所以当集群规模较大时，集群运维成本较高	中	支持（接近标准SQL）	19k