SnappyData与Presto,Druid,Kylin,ES的对比-2_presto es对比

OLAP简介

On-Line Analytical Processing，简称OLAP，即联机分析处理，其主要的功能在于方便大规模数据分析及统计计算，对决策提供参考和支持。

OLAP发展到现在的阶段，很多的查询分析需求具有以下4种显著的特点：

1
2
3
4

1、数据量大
2、高速响应
3、灵活交互
4、多维分析

根据存储类型，OLAP又分为ROLAP(RelationalOLAP)、MOLAP(MultidimensionalOLAP)以及HOLAP(HybridOLAP)。

根据处理类型，OLAP又分为MPP架构、搜索引擎架构和预处理架构。

在开源领域OLAP的解决方案中，包括了诸如Presto、SparkSQL、Impala以及SnappyData等MPP架构和ROLAP的引擎；也包括了Druid和Kylin等预处理架构和MOLAP的引擎；同时还包含了ES这种搜索引擎;除此之外，还有ClickHouse以及IndexR这种列式数据库用于OLAP分析。

下面我们就这些开源引擎，从上述中以下几个方面进行对比：数据规模、查询性能、灵活性、易用性、处理方式以及实时性进行对比。

分布式开源OLAP引擎

基于MPP架构的ROLAP引擎

Presto、Impala以及Spark SQL，都是利用关系模型来处理OLAP查询，通过并发来提高查询性能。

这类引擎的优点和缺点如下：

1
2
3
4
5
6
7
8
9

优点：
1、支持的数据规模大(非存储引擎)；
2、灵活性高，随意查询数据；
3、易用性强，支持标准SQL以及多表join和窗口函数；
4、处理方式简单，无需预处理，全部后处理，没有冗余数据。

缺点：
1、性能较差，当查询复杂度高且数据量大时，可能分钟级别的响应。同时其不是存储引擎，因此没有本地存储，当join时shuffle开销大，性能差。
2、实时性较差，不支持数据的实时导入，偏离线处理。

我们以Spark SQL为例来说明，由于其本身只是个计算引擎，而非存储引擎，导致其需要从外部加载数据，使得数据的实时性得不到保证；同时当涉及多表join时，其查询性能很难得到秒级的响应。

因此，其实时性和查询性能较弱，所以只适合那些对实时性要求不是很高，但灵活性很强的需要多表join的ad-hoc类查询以及需求变化较频繁的查询。

目前开源社区出现了一种依托Spark SQL，同时自己存储数据的一类OLAP引擎，比如TiSpark以及SnappyData。

关于TiSpark项目，其虽然以TiKV为存储减少了数据加载的延迟，使得实时性可以得到保证，但是其在数据量较大时的join，查询响应依然得不到保证；同时对于窗口函数的分析不支持，部分adhoc需求也得不到有效保证。

关于SnappyData，其也是个存储引擎，而且表join时通过数据存储本地化以及其他优化，有效将性能差、实时性差的缺点避免掉，我们会在最后就SnappyData做个总结。

预计算引擎与MOLAP

Kylin是完全的预计算引擎，通过枚举所有维度的组合，建立各种Cube进行提前聚合，以HBase为基础的OLAP引擎。

Druid则是轻量级的提前聚合(roll-up)，同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。

Kylin的优缺点如下：

1
2
3
4
5
6
7
8
9

优点：
1、支持数据规模超大(HBase)
2、易用性强，支持标准SQL
3、性能很高，查询速度很快

缺点：
1、灵活性较弱，不支持adhoc查询；且没有二级索引，过滤时性能一般；不支持join以及对数据的更新。
2、处理方式复杂，需要定义Cube预计算；当维度超过20个时，存储可能会爆炸式增长；且无法查询明细数据了；维护复杂
3、实时性很差，很多时候只能查询前一天或几个小时前的数据。

Druid的优缺点如下：

1
2
3
4
5
6
7
8
9

优点：
1、支持的数据规模大(本地存储+DeepStorage--HDFS)
2、性能高，列存压缩，预聚合加上倒排索引以及位图索引，秒级查询
3、实时性高，可以通过kafka实时导入数据

缺点：
1、灵活性适中，虽然维度之间随意组合，但不支持adhoc查询，不能自由组合查询，且丢失了明细数据
2、易用性较差，不支持join，不支持更新，sql支持很弱(有些插件类似于pinot的PQL语言)，只能JSON格式查询；对于去重操作不能精准去重。
3、处理方式复杂，需要流处理引擎将数据join成宽表，维护相对复杂；对内存要求较高。

因此，Kylin适合对实时数据需求不高，但响应时间较高的查询，且维度较多，需求较为固定的特定查询；而不适合实时性要求高的adhoc类查询。

Druid适合那种数据量大，对实时性要求高且响应时间短，以及维度较少且需求固定的简单聚合类查询(sum，count，TopN)，多以storm和flink组合进行预处理；而不适合需要join、update和支持SQL和窗口函数等复杂的adhoc查询。

如果分析人员想用SQL进行复杂的分析操作，那么Druid不适合。

搜索引擎架构

ES是典型的搜索引擎类的架构系统，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型提高查询性能。对于搜索类的查询效果较好，但当数据量较大时，对于Scan类和聚合类为主的查询性能较低。

ES的优缺点如下：

1
2
3
4
5
6
7
8
9

优点：
1、性能较高，支持倒排索引和各种过滤后的聚合查询。
2、实时性强，在文档上建立完索引后，立刻可以查询。
3、处理方式简单，无需预处理

缺点：
1、支持的数据规模较小，高并发不理想。
2、灵活性差，不支持复杂的adhoc查询
3、易用性差，不支持SQL；DSL成本高，且不能精准去重。

因此，ES适合那种全文检索，且数据规模较少时过滤条件很多的聚合查询，并发度也不大的场景。

同样，如果分析人员想用SQL分析，那么也不适合ES。

纯列存OLAP

ClickHouse是个列存数据库，保存原始明细数据，通过MergeTree使得数据存储本地化来提高性能，是个单机版超高性能的数据库。

ClickHouse的优缺点如下：

1
2
3
4
5
6
7
8
9

优点：
1、性能高，列存压缩比高，通过索引实现秒级响应
2、实时性强，支持kafka导入
3、处理方式简单，无需预处理，保存明细数据

缺点：
1、数据规模一般
2、灵活性差，不支持任意的adhoc查询，join的支持不好。
3、易用性较弱，SQL语法不标准，不支持窗口函数等；维护成本高

因此，ClickHouse适合数据规模不大情况下的单机且单表的数据分析。实际场景有待检验。

SnappyData

SnappyData是个计算与存储引擎，全内存、行列混合存储且完全不需预处理，支持SQL与Spark SQL，兼顾MPP的特点且colocate特性使得数据本地化，支持join、列表的update以及窗口函数等任意的adhoc查询。

SnappyData的优缺点如下：

1
2
3
4
5
6
7
8
9
10

优点：
1、性能高，列存压缩+全内存，数据状态共享，秒级查询
2、实时性强，支持kafka的stream table以及实时导入
3、处理方式简单，无需预处理，保存明细数据，数据本地存储
4、灵活性高，是个sql数据库，支持任意字段的查询、update以及窗口函数和复杂的adhoc查询
5、易用性强，支持标准SQL和Spark SQL，精准去重，支持各种分许函数

缺点：
1、数据规模中等，由于全内存导致成本较高，且需要关注GC问题
2、维护成本高

因此，SnappyData适合那种数据规模中等(PB以下)，需求变化加多，实时性要求较高、响应时间较短且复杂的窗口函数类查询；同时适合查询明细数据以及探索式的adhoc查询。

如果数据规模不大，且希望找到一种简单易用且实时性要求高的多维OLAP引擎，最重要的是可供分析人员使用的SQL的引擎，那么SnappyData比较适合。前提是需要在成本与效率之间做个平衡，SQL固然能提高开发效率，但内存较大的服务器成本也确实相对较高。

引擎对比