OLAP 常用引擎对比与概述

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

能力对比

并发能力与查询延迟对比

这里可能有朋友有疑问：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 来完成流式或离线的计算上。

执行模型对比

• 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 引擎的主要特点

Hive

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

Spark SQL、Flink SQL

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

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

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 极速的分析性能奠定了基础。

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。

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 计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大或进行扫描聚合类查询时，查询性能会有较大影响。

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。

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。

Doris

Doris 是百度主导的，根据 Google Mesa 论文和 Impala 项目改写的一个大数据分析引擎，在百度、美团团、京东的广告分析等业务有广泛的应用。Doris 的主要功能特性如下所示：

• 现代化 MPP 架构
  • 支持大规模数据集、集群灵活扩展
  • 支持高并发小查询
• 强悍的 SQL 执行引擎、全新的预聚合技术
  • 支持亚秒级 OLAP 多维分析
  • 支持高效快速的多表关联分析
• 基于 LSM 的列式存储引擎、MVCC 事务隔离机制
  • 支持数据高效的实时导入
  • 支持数据批量、实时更新

Druid

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

Druid 的特点包括：

• Druid 实时的数据消费，真正做到数据摄入实时、查询结果实时
• Druid 支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发
• Druid 的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景
• Druid 把数据列分为三类：时间戳、维度列、指标列
• Druid 不支持多表连接
• Druid 中的数据一般是使用其他计算框架(Spark 等)预计算好的低层次统计数据
• Druid 不适合用于处理透视维度复杂多变的查询场景
• Druid 擅长的查询类型比较单一，一些常用的 SQL(groupby 等)语句在 druid 里运行速度一般
• Druid 支持低延时的数据插入、更新，但是比 hbase、传统数据库要慢很多

与其他的时序数据库类似，Druid 在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏 Join、子查询等。

Kylin

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

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

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

Links