主流开源OLAP对比分析

数据库按照应用场景划分可以分为OLTP和OLAP，OLTP是针对交易型的场景比如像银行的存取款、转账类业务，OLAP是针对分析型的场景比如用于企业决策支持的BI、报表类业务。
而在OLAP领域，又可以根据具体技术实现分为MOLAP及ROLAP。MOLAP是基于多维分析的OLAP系统，一般对存储有优化，进行部分预计算，查询性能最高，但查询灵活性有限制。ROLAP是更偏向传统关系型的OLAP系统，ROLAP又分为两类：一类是MPP数据库，另一类是SQL引擎。MPP数据库是完整的数据库，一般需要把数据导入到库中进行OLAP分析，入库时对数据分布进行优化，进而获得后期查询性能的提升，提供灵活的即席查询能力，但无法支持超大数据量的查询。SQL引擎只提供SQL执行能力，不负责具体的数据存储。

目前主流的开源OLAP产品按照此分类主要有以下产品：

以下针对以上几种开源组件分别进行概要的介绍说明，并进行相关特性的对比。

MOLAP

Kylin

Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供 Hadoop 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc.开发并贡献至开源社区。Kylin的核心思想是预计算，理论基础是：以空间换时间。即将多维分析可能用到的度量进行预计算，将计算好的结果保存成Cube并存储到HBase中，供查询时直接访问。把高复杂度的聚合运算，多表连接等操作转换成对预计算结果的查询。最新版本的Apache Kylin4.0采用了全新的 Spark 构建引擎和 Parquet 作为存储，同时使用 Spark 作为查询引擎。
Kylin的架构图如下：

优点：

亚秒级查询响应；
支持百亿、千亿甚至万亿级别交互式分析；

缺点：

不支持 insert, update, delete 等 SQL 操作，用户修改数据的话需要重新批量导入（构建）；
需要预先建立模型后加载数据到 Cube 后才可进行查询

Druid

Apache Druid是高性能的实时分析数据库，主要提供对大量的基于时序的数据进行OLAP查询能力。支持毫秒级的快速的交互式查询。Druid的核心设计结合了数据仓库、时间序列数据库和搜索系统的思想，适用于多种场景的高性能数据实时分析。
Druid的架构图如下：
优点：

为分析而设计：为OLAP工作流的探索性分析而构建。它支持各种filter、aggregator和查询类型。
交互式查询：低延迟数据摄取架构允许事件在它们创建后毫秒内查询。
高可用：数据在系统更新时依然可用、可查询。规模的扩大和缩小不会造成数据丢失。
可伸缩：每天处理数十亿事件和TB级数据。

缺点：

不支持更新操作，数据不可更改
不支持事实表之间的关联

对比Kylin:

都是cube预计算
支持流式更灵活
Kylin 利用 Hadoop/HBase 做计算和存储，使用 SQL 查询，提供 JDBC/ODBC 驱动与常见 BI 工具集成
Druid 有自己独立的分布式集群，能够实时摄入数据，有自己的查询接口（与BI兼容性较弱），通常多用于实时要求高的场景

ROLAP

Greeplum

GreenPlum是基于PostgreSQL的开源MPP数据库，具有良好的线性扩展能力，具有高效的并行运算和并行存储特性。
GreenPlum的架构图如下：

优点：

支持多态数据存储(行存、列存)，允许用户根据应用定义数据分布方式，可提高查询性能。
具有高效的SQL优化器，针对OLAP查询进行优化。
SQL支持完善，支持insert、delete、update，支持事务的ACID。

缺点：

存在“木桶效应”，单机故障会导致性能严重下降，因此集群规模不能太大。
并发性能不高。

ClickHouse

ClickHouse是Yandex（号称俄罗斯的百度）开源的MPP架构的列式存储数据库。在 ClickHouse 中，数据始终是按列存储的，包括矢量（向量或列块）执行的过程。只要有可能，操作都是基于矢量进行分派的，而不是单个的值，这被称为«矢量化查询执行»，它有利于降低实际的数据处理开销。
ClickHouse的特点有：

着眼硬件。基于将硬件功效最大化的目的，ClickHouse会在内存中进行GROUP BY；与此同时，他们非常在意CPU L3级别的缓存，因为一次L3的缓存失效会带来70～100ns的延迟，意味着在单核CPU上，它会浪费4000万次/秒的运算。正因为注意了这些细节，所以ClickHouse在基准查询中能做到1.75亿次/秒的数据扫描性能。
注重算法。例如，在字符串搜索方面，针对不同的场景，ClickHouse选择了多种算法：对于常量，使用Volnitsky算法；对于非常量，使用CPU的向量化执行SIMD，暴力优化；正则匹配使用re2和hyperscan算法。除了字符串之外，其余的场景也与它类似，ClickHouse会使用最合适、最快的算法。如果世面上出现了号称性能强大的新算法，ClickHouse团队会立即将其纳入并进行验证。
特定场景，特殊优化。针对同一个场景的不同状况，选择使用不同的实现方式，尽可能将性能最大化。对于数据结构比较清晰的场景，会通过代码生成技术实现循环展开，以减少循环次数。
向量化执行。SIMD被广泛地应用于文本转换、数据过滤、数据解压和JSON转换等场景。相较于单纯地使用CPU，利用寄存器暴力优化也算是一种降维打击了。

ClickHouse的架构图如下：

优点：

单表查询速度极快

缺点：

不支持事务，不支持真正的删除/更新；
不支持高并发，Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行；
join性能不高

Impala

Cloudera公司推出，提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。 基于Hive，使用内存计算，兼顾数据仓库、具有实时、批处理、多并发等优点。是CDH平台首选的PB级大数据实时查询分析引擎。
Impala架构如下：

优点：

基于内存运算，不需要把中间结果写入磁盘，省掉了大量的I/O开销。
无需转换为MapReduce，直接访问存储在HDFS，HBase中的数据进行作业调度，速度快。
使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。
支持各种文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。
可以访问hive的metastore，对hive数据直接做数据分析。

缺点：

对内存的依赖大，且完全依赖于hive。
实践中，分区超过1万，性能严重下降。
只能读取文本文件，而不能直接读取自定义二进制文件。

Hawq

HAWQ是Pivotal公司开源的一个Hadoop原生大规模并行SQL分析引擎，针对的是分析型应用。Apache HAWQ 采用主从（Master-Slave）的改进MPP架构，通过将MPP与批处理系统有效的结合，克服了MPP的一些关键的限制问题，如短板效应、并发限制、扩展性等。其整体架构与Pivotal另一开源MPP数据库Greenplum比较相似：

优点：

对SQL标准的完善支持：ANSI SQL标准，OLAP扩展，标准JDBC/ODBC支持。
支持ACID事务特性：这是很多现有基于Hadoop的SQL引擎做不到的，对保证数据一致性很重要。
动态数据流引擎：基于UDP的高速互联网络。
多种UDF（用户自定义函数）语言支持：java, python, c/c++, perl, R等。

缺点：

基于GreenPlum实现，技术实现复杂，包含多个组件。比如对于外部数据源，需要通过PXF单独进行处理；
C++实现，对内存的控制比较复杂，如果出现segmentfault直接导致当前node挂掉;

Presto

Presto是Facebook推出分布式SQL交互式查询引擎，完全基于内存的并行计算，支持任意数据源，数据规模GB~PB。
它采用典型的master-slave架构，架构图如下：

优点：

基于内存运算，减少没必要的硬盘IO，所以快。
能够处理PB级别的海量数据分析。（虽然能够处理PB级别的海量数据分析，但不是代表Presto把PB级别都放在内存中计算的。而是根据场景，如count，avg等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。）
能够连接多个数据源，跨数据源关联查询。
清晰的架构，是一个能够独立运行的系统，不依赖于任何其他外部系统，部署简单。

缺点：

不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的。
Presto的一个权衡是不关心中间查询容错。如果其中一个Presto工作节点出现故障（例如，关闭），则大多数情况下正在进行的查询将中止并需要重新启动。

对比Hive:

Hive默认采用MapReduce，MR每个操作要么需要写磁盘，要么需要等待前一个stage全部完成才开始执行，而Presto将SQL转换为多个stage，每个stage又由多个tasks执行，每个tasks又将分为多个split。所有的task是并行的方式进行允许，stage之间数据是以pipeline形式流式的执行，数据之间的传输也是通过网络以Memory-to-Memory的形式进行，没有磁盘io操作。这也是Presto性能比Hive快很多倍的决定性原因。

对比Spark:

目标：Presto强调查询，但Spark重点强调计算。
架构：Presto的体系结构与MPP SQL引擎非常相似。这意味着仅针对SQL查询执行进行了高度优化，而Spark是一个通用执行框架，能够运行多个不同的工作负载，如ETL，机器学习等。
任务启动：Presto的查询没有太多开销，Presto协调器始终处于启动状态并等待查询。而Spark驱动程序启动需要时间与集群管理器协商资源，复制jar，才开始处理。
任务提交：Spark提交任务并在每个阶段实时应用资源（与presto相比，这种策略可能导致处理速度稍慢）; Presto一次申请所需资源，并且一次提交所有任务。
数据处理：在spark中，数据需要在进入下一阶段之前完全处理。 Presto是流水线式处理模式。只要一个page完成处理，就可以将其发送到下一个task（这种方法大大减少了各种查询的端到端响应时间）。
内存：两者都是内存存储和计算，当它无法获得足够的内存时，spark会将数据写入磁盘，但presto会导致OOM。
容错：如果Spark任务失败或数据丢失，它将重新计算。但是presto会导致查询失败。

Drill

Drill是MapR开源的一个低延迟的大数据集的分布式SQL查询引擎，是谷歌Dremel的开源实现。它支持对本地文件、HDFS、HBASE等数据进行数据查询，也支持对如JSON等schema-free的数据进行查询。
Drill的架构图如下：

从架构上看，与同是源自Dremel的Impala比较类似。
优点：

能够自动解析数据（json，text，parquet）的结构。
支持自定义的嵌套数据集，数据灵活，支持查询复杂的半结构化数据。
与Hive一体化（Hive表和视图的查询，支持所有的Hive文件格式和HiveUDFS）。
支持多数据源，包括NoSQL数据库。

缺点：

SQL语法和常规SQL有区别,一般是如“select * from 插件名.表名”的形式。
安装部署比较复杂。
GC机制还有待提高。

SparkSQL

Spark SQL与传统 DBMS 的查询优化器 + 执行器的架构较为类似，只不过其执行器是在分布式环境中实现，并采用的 Spark 作为执行引擎。Spark SQL 的查询优化是Catalyst，Catalyst 将 SQL 语言翻译成最终的执行计划，并在这个过程中进行查询优化。这里和传统不太一样的地方就在于， SQL 经过查询优化器最终转换为可执行的查询计划是一个查询树，传统 DB 就可以执行这个查询计划了。而 Spark SQL 最后执行还是会在 Spark 内将这棵执行计划树转换为 Spark 的有向无环图DAG 再执行。

优点：

将sql查询与spark无缝融合
兼容HiveQL

缺点：

查询性能不高
以thrift server方式提供的SparkSQL服务不支持多种数据源，必须使用DataFrame API。

Hive

Hive是一个构建于Hadoop顶层的数据仓库工具。定义了简单的类似SQL 的查询语言——HiveQL，可以将HiveQL查询转换为MapReduce 的任务在Hadoop集群上执行。

优点：

高可靠、高容错：HiveServer采用集群模式。双MetaStore。超时重试机制。
类SQL：类似SQL语法，内置大量函数。
可扩展：自定义存储格式，自定义函数。
多接口：Beeline，JDBC，ODBC，Python，Thrift。

缺点：

延迟较高：默认MR为执行引擎，MR延迟较高。
不支持物化视图：Hive支持普通视图，不支持物化视图。Hive不能再视图上更新、插入、删除数据。
不适用OLTP：暂不支持列级别的数据添加、更新、删除操作。

性能对比

针对这几款开源OLAP组件的性能，网上有一份相关的对比测试报告，这里引用https://blog.csdn.net/oDaiLiDong/article/details/86570211中的测试情况进行补充说明。整体来说，这个性能对比测试是一个TPC-DS的标准测试，是针对Hadoop(2.7)、Hive(2.1)、Hawq(3.1.2.0)、Presto(0.211)、Impala(2.6.0)、Sparksql(2.2.0)、Clickhouse(18.1.0-1.El7)、Greenplum(5.7.0) 具体版本进行的。采用多表关联和单大表性能分别对比不同组件在查询性能、系统负载等方面的情况。环境是采用的一个三节点的物理机，操作系统为CentOS7。
测试的结果如下表格所示：

多表关联性能对比

结论：多表关联查询场景，Presto、Impala、Hawq、GreePlum性能较好，是SparkSQL和Clickhouse性能的2-3倍。(Hive是性能最差的，与前几个组件不是同一个数据级的差别)

单表查询性能对比

结论：单表查询场景，Clickhouse性能比较突出，是其它组件的3-6倍。这其中，Hawq、GreenPlum在单表查询的场景性能要更差一些。

整体上总结就是，Presto、Impala以及Hawq在多表查询方面体现出了优势，虽说Presto和Impala在多表查询方面的性能差别不大，但是在查询过程中却发现Impala的一些局限性，并尽量避开这些局限问题进行测试。Impala不支持的地方，例如：不支持update、delete操作，不支持Date数据类型，不支持ORC文件格式等等，而Presto则基本没有这些局限问题（本次测试中基本没有发现）。

在单表测试方面clickhouse体现出了比其余组件的优势，性能比其他组件要好一大截，而presto相比于hawq和impala以及sparksql在单大表聚合操作方面的表现也相对优秀。

综合对比分析

针对上述各开源产品的描述及性能对比，我们使用下面表格来对这些产品进行一个较全面的对比，

	Druid	Kylin	Greenplum	ClickHouse	Impala	Hawq	Presto	Drill	Hive	SparkSQL
分类	MOLAP	MOLAP	ROLAP	ROLAP	ROLAP	ROLAP	ROLAP	ROLAP	ROLAP	ROLAP
架构	预计算	预计算	MPP数据库	MPP数据库	SQL引擎	SQL引擎	SQL引擎	SQL引擎	SQL引擎	SQL引擎
依赖Hadoop	否	是	否	否	是	是	否	是	是	是
事务支持	否	否	是	否	否	是	否	否	否	否
SQL功能支持	有限	有限	完善	有限	有限	完善	有限	有限	有限	有限
支持更新	不支持	不支持	支持	不支持	不支持	支持	不支持	不支持	不支持	不支持
优点	超大数据集支持	超大数据集支持	完善的数据库产品，适合用于企业级数仓	单表查询性能极佳	多表关联性能不错	Hadoop之上的事务支持	整体性能不错，支持多数据源	支持多数据源	可靠性较高	融合SQL与Spark
缺点	灵活性差	灵活性差	单机故障导致木桶效应	多表关联性能不佳	查询内存占用大	不适合单表复杂聚合操作	容错性不强，纯内存操作，内存放不下会报错	GC问题	延迟较高	多表单表性能都不突出