OLAP计算引擎怎么选？

大家好，我是一哥，今天聊一聊OLAP技术，一哥认为好的OLAP引擎应该具备以下三个条件：易开发、易维护、易移植。今天给大家分享一下常见的几种OLAP计算引擎，他们的特性、适用场景，优缺点等，希望对大家在选型应用上有帮助。

Kylin

OLAP计算引擎怎么选？

简介

1、Kylin是ebay开发的一套MOLAP系统；

2、提供Hadoop之上的SQL查询接口及多维分析能力以支持超大规模数据；

3、提供与BI工具（如Tableau）的整合能力；

OLAP计算引擎怎么选？

适用范围

适用于：数据仓库，用户行为分析，流量（日志）分析，自助分析平台，电商分析，广告效果分析，实时分析，数据服务平台等各种场景

产品特性

1、Kylin是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现

2、Kylin为Hadoop提供标准SQL支持大部分查询功能

3、用户可以与Hadoop数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能

4、用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体

5、友好的web界面以管理，监控和使用立方体

6、支持额外功能和特性的插件

7、与调度系统，ETL，监控等生命周期管理系统的整合

8、通过预计算的方式缓存了所有需要查询的的数据结果，需要大量的存储空间（原数据量的10+倍）

Presto

OLAP计算引擎怎么选？

简介

1、Presto是一个开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。

2、Presto的设计和编写完全是为了解决像Facebook这样规模的商业数据仓库的交互式分析和处理速度的问题。

OLAP计算引擎怎么选？

适用范围

1、Presto 支持 SQL 并提供了一个标准数据库的语法特性，但其不是一个通常意义上的关系数据库。

2、Presto 是一个可选的工具，可以用来查询 HDFS

3、被设计为处理数据仓库和分析：分析数据，聚合大量的数据并产生报表，这些场景通常被定义为 OLAP

产品特性

1、Presto支持在线数据查询，包括Hive, Cassandra

2、一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析

3、完全基于内存的并行计算

4、流水线

5、本地化计算

6、动态编译执行计划

7、小心使用内存和数据结构

8、类BlinkDB的近似查询

9、GC控制

Impala

OLAP计算引擎怎么选？

简介

1、由cloudera公司主导开发的大数据实时查询分析工具。

2、是一个分布式，大规模并行处理（MPP）数据库引擎，包括运行在CDH集群主机上的不同后台进程。

3、Impala主要由Impalad， State Store和CLI组成。

OLAP计算引擎怎么选？

适用范围

Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。

产品特性

1.查询速度快。不同于hive底层执行使用的是MapReduce引擎，它仍然是一个批处理过程。impala中间结果不写入磁盘，即使及时通过网络以流的形式传递，大大降低的节点的IO开销。

2.灵活性高。可以直接查询存储在HDFS上的原生数据，也可以查询经过优化设计而存储的数据，只需要数据的格式能够兼容MapReduce、hive、Pig等等。

3.易整合。很容易和hadoop系统整合，并使用hadoop生态系统的资源和优势，不需要将数据迁移到特定的存储系统就能满足查询分析的要求。

4.可伸缩性。可以很好的与一些BI应用系统协同工作，如Microstrategy、Tableau、Qlikview等。

5、使用Impala比使用Hive能提高3-90的效率

Kudu

OLAP计算引擎怎么选？

简介

1、Cloudera带头开发的存储系统，其整体应用模式和HBase比较接近，即支持行级别的随机读写，并支持批量顺序检索功能。

2、Kudu管理的是类似关系型数据库的结构化的表。

3、Kudu底层核心代码使用C++开发，对外提供Java API接口。

OLAP计算引擎怎么选？

适用范围

1、Kudu的定位是提供fast analytics on fast data，也就是在快速更新的数据上进行快速的查询。

2、它定位OLAP和少量的OLTP工作流，如果有大量的random accesses，官方建议还是使用HBase最为合适。

产品特性

1、Kudu的集群架构基本和HBase类似，采用主从结构，Master节点管理元数据，Tablet节点负责分片管理数据。

2、Kudu采用了类似log-structured存储系统的方式，增删改操作都放在内存中的buffer，然后才merge到持久化的列式存储中。Kudu还是用了WALs来对内存中的buffer进行灾备。

对比分析

Kylin

Kylin 可以说是与市面上流行的RTOLAP走了一条完全不同的道路。Kylin在如何快速求得预计算结果，以及优化查询解析使得更多的查询能用上预计算结果方面在优化，后续Kylin的版本会优化预计算速度，使得Kylin可以变成一个近似实时的分析引擎。然而其缺点就是SQL支持方面可能在一定程度上会有所牺牲，存储开销也会比较大，而像Presto，SparkSQL，Hawq等是着重于优化查询数据的过程环节，像一些其它的数据仓库一样，使用列存、压缩、并行查询等技术，优化查询。这种方案的好处就在于扩展性强、能适配更广泛的查询，然而由于每次的聚合计算是 On Fly的，因此性能上相较Kylin还是有所不如。

Presto

轻量快速支持近实时交互查询
在Facebook得到广泛使用，扩展性和稳定性毋容置疑
使用分布式查询引擎，和传统的MapReduce相比消除了延迟和磁盘IO开销
后期支持UDF

Impala

优点：

支持SQL查询，快速查询大数据。
可以对已有数据进行查询，减少数据的加载，转换。
多种存储格式可以选择（Parquet,Text, Avro, RCFile, SequeenceFile）。
可以与Hive配合使用。

缺点：

不支持用户定义函数UDF。
不支持text域的全文搜索。
不支持Transforms。
不支持查询期的容错。
对内存要求高。

在实时性要求不高的应用场景中，比如，月度、季度、年度报表的生成。可以使用基于传统的HadoopMapreduce处理海量大数据。但是在一些实时性要求很高的场景中，一方面满足实时性要求，一方面提升用户体验。Impala因其快速的响应能力当之无愧作为首选查询分析工具。

Kudu

Kudu本质上是将性能的优化，寄托在以列式存储为核心的基础上，希望通过提高存储效率，加快字段投影过滤效率，降低查询时CPU开销等来提升性能。而其他绝大多数设计，都是为了解决在列式存储的基础上支持随机读写这样一个目的而存在的。比如类Sql的元数据结构，是提高列式存储效率的一个辅助手段，唯一主键的设定也是配合列式存储引入的定制策略，至于其他如Delta存储，compaction策略等都是在这个设定下为了支持随机读写，降低latency不确定性等引入的一些Tradeoff方案。

官方测试结果上，如果是存粹的随机读写，或者单行的检索请求这类场景，由于这些Tradeoff的存在，HBASE的性能吞吐率是要优于Kudu不少的（2倍到4倍），kudu的优势还是在支持类SQL检索这样经常需要进行投影操作的批量顺序检索分析场合。