我主要负责腾讯内部某部门效能大数据OLAP系统搭建，曾经对业界OLAP引擎进行过调研，分享下调研结果和结论，更多OLAP系统搭建的架构方案和实际问题，可以持续关注我的文章分享。调研结果如下：

引擎概览

业界的OLAP引擎主要有：Impala，Presto, Apache Drill, Apache Doris, Clickhouse, Druid, Kylin等。按照架构和试下可以分为：离线批处理引擎、MPP架构引擎、预计算引擎以及搜索引擎。

离线批处理引擎

离线批处理引擎主要用于复杂的ETL、构建数仓、数据挖掘等对延时要求不高，但灵活性最大的处理引擎，典型的代表如Hive（ODPS）、Spark。这类引擎典型的优点就是吞吐量大，扩展性好，容错性好；缺点是低效，适合规模大、逻辑复杂任务。
它的逻辑不难理解，随着MapReduce的发表和衍生技术的出现，不论是Hadoop MapReduce还是Spark等工具，共同思想都是对数据文件切片成独立的Task做并行计算。其中一些算子通过shuffle实现，就要落地中间结果或者缓存数据集，通过HDFS备份以及计算的中间结果进行容错，再加上任务调度等问题使得系统整体效率慢。但是扩展性好，理论上的扩展瓶颈只在元数据节点，这也使得更大吞吐量的批处理成为可能，所以离线数仓构建、大型的ETL最适合不过。

MPP架构引擎

MPP即大规模并行处理（Presto/Impala/SparkSQL/Drill等 ），这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用hive+mapreduce架构，提高查询效率。

预计算引擎

预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，通过KV存储结果集。进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。

搜索引擎

搜索引擎架构的系统(es，solr等)，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。

引擎简介

Presto

Presto是一个分布式SQL查询引擎， 它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。Presto是一个OLAP的工具，擅长对海量数据进行复杂的分析；但是对于OLTP场景，并不是Presto所擅长，所以不要把Presto当做数据库来使用。

Impala

Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查询工具，它拥有和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 和统计函数查询数据，从而大大降低了延迟。

Clickhouse

Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse 日处理记录数”十亿级”。
特性:采用列式存储；数据压缩；基于磁盘的存储，大部分列式存储数据库为了追求速度，会将数据直接写入内存，按时内存的空间往往很小；CPU 利用率高，在计算时会使用机器上的所有 CPU 资源；支持分片，并且同一个计算任务会在不同分片上并行执行，计算完成后会将结果汇总；支持SQL，SQL 几乎成了大数据的标准工具，使用门槛较低；支持联表查询；支持实时更新；自动多副本同步；支持索引；分布式存储查询。

GreenPlum

Greenplum是一个开源的大规模并行数据分析引擎。借助MPP架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。
GPDB完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展；从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。支持分布式事务，支持ACID。保证数据的强一致性。做为分布式数据库，拥有良好的线性扩展能力。GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多种开源软件集成，譬如Pentaho,Talend 等。

Druid

Druid同kylin一样，是采用预计算的方式。主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。
他的特点为：

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

Kylin

kylin是一种OLAP数据引擎，支持大数据生态圈的数据分析业务，主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来，达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。
这种OLAP引擎，一般包括以下几部分：

• 数据构建存储：cube构建，元数据信息
• sql解析执行：Query引擎(sql解释器)，routing模块(sql执行)
• 上层接口服务；jdbc/odbc接口，rest服务

应用思路：将hive中的数据按照查询列构建成cube，存储到hbase中，数据轨迹连接kylin的jdbc接口实现快速查询。

引擎对比

有人对各个引擎进行了测试，测试的引擎包括：SparkSql、Presto、Impala、HAWQ、ClickHouse、Hive、GreenPlum；测试的场景主要为：多表关联查询性能情况，单表查询性能情况。测试结果如下。

多表关联查询对比测试

通过我们选取的15条sql语句查询测试，从表中可以看出，presto、impala和hawq查询时间快于SparkSql和ClickHouse，性能约是SparkSql的2-3倍，其中尤其以Presto和Impala性能要好一些。greenplum在多表查询上也有不错的表现；ClickHouse对于多表join效果相比较于Presto、Impala、HAWQ不是很好，并且很多复杂语法支持的不够好，可见并不是为关联分析而设置；而hive无疑是所有组件中耗时最多的，其中部分语句查询时间超出1h的总时间按1h计算。

单表查询对比测试

从结果中我们发现，对于单表测试ClickHouse要比其余几种组件查询速度表现突出，测试性能约是其余四种的3-6倍。而Presto相比于HAWQ、Impala、SparkSql、GreenPlum在单l表操作方面性能也稍好些。

测试结果分析

通过以上图表查询性能分析，这里采用5分为满分来比较，各组件情况如下表：

原文链接： https://www. analysysdata.com/forum/ topic/21

总结

上面给出了常用的一些OLAP引擎，它们各自有各自的特点，我们将其分组：

• Hive，Hawq，Impala - 基于SQL on Hadoop
• Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划
• Kylin - 用空间换时间，预计算
• Druid - 一个支持数据的实时摄入
• ClickHouse - OLAP领域的Hbase，单表查询性能优势巨大
• Greenpulm - OLAP领域的Postgresql

应用建议：OLAP领域，暂时没有one for all的引擎，根据自己的业务数据特点选择一个合适的吧。