开源的OLAP引擎，按照查询类型划分，OLAP一般分为即席查询和固化查询。
即席查询: 通过手写sql完成一些临时的数据分析需求，这类sql形式多变、逻辑复杂，对查询时间没有严格要求
固化查询: 指的是一些固化下来的取数、看数需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类的sql固定模式，对响应时间有较高要求。
按照架构实现划分，主流的OLAP引擎主要有下面三点：
MPP架构系统(Presto/Impala/SparkSQL/Drill等)。这种架构主要还是从查询引擎入手，使用分布式查询引擎，而不是使用hive+mapreduce架构，提高查询效率。
搜索引擎架构的系统(es，solr等)，在入库时将数据转换为倒排索引，采用Scatter-Gather计算模型，牺牲了灵活性换取很好的性能，在搜索类查询上能做到亚秒级响应。但是对于扫描聚合为主的查询，随着处理数据量的增加，响应时间也会退化到分钟级。
预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
这几个框架都是OLAP大数据分析比较常见的框架，各自特点如下：
presto：facebook开源的一个java写的分布式数据查询框架，原生集成了Hive、Hbase和关系型数据库，Presto背后所使用的执行模式与Hive有根本的不同，它没有使用MapReduce，大部分场景下比hive快一个数量级，其中的关键是所有的处理都在内存中完成。
Druid：是一个实时处理时序数据的Olap数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。
spark SQL：基于spark平台上的一个olap框架，本质上也是基于DAG的MPP， 基本思路是增加机器来并行计算，从而提高查询速度。
kylin：核心是Cube，cube是一种预计算技术，基本思路是预先对数据作多维索引，查询时只扫描索引而不访问原始数据从而提速。
这几种框架各有优缺点，存在就是合理，如何选型个人看法如下：
从成熟度来讲：kylin>spark sql>Druid>presto
从超大数据的查询效率来看：Druid>kylin>presto>spark sql
从支持的数据源种类来讲：presto>spark sql>kylin>Druid
大数据查询目前来讲可以大体分为三类：
1.基于hbase预聚合的，比如Opentsdb,Kylin,Druid等,需要指定预聚合的指标，在数据接入的时候根据指定的指标进行聚合运算，适合相对固定的业务报表类需求，只需要统计少量维度即可满足业务报表需求
2.基于Parquet列式存储的，比如Presto, Drill，Impala等，基本是完全基于内存的并行计算，Parquet系能降低存储空间，提高IO效率，以离线处理为主，很难提高数据写的实时性，超大表的join支持可能不够好。spark sql也算类似，但它在内存不足时可以spill disk来支持超大数据查询和join
3.基于lucene外部索引的，比如ElasticSearch和Solr,能够满足的的查询场景远多于传统的数据库存储，但对于日志、行为类时序数据，所有的搜索请求都也必须搜索所有的分片，另外，对于聚合分析场景的支持也是软肋
其中presto和spark sql都是解决分布式查询问题，提供SQL查询能力，但数据加载不一定能保证实时。
Druid是保证数据实时写入，但查询上不支持SQL，或者说目前只支持部分SQL，我个人觉得适合用于工业大数据，比如一堆传感器实时写数据的场景。Kylin是MOLAP，就是将数据先进行预聚合，然后把多维查询变成了key-value查询。这里要看你实际要应用于什么场景了。
简单说几句。
1. kylin 预计算。用户指定dimensions和要计算的metric，kylin通过MR将结果保存在HBase中，后续读取直接读HBase。适合那种业务清楚的知道自己要分析什么的场景。查询模式比较固定，只不过所查看的时间不同的场景。注意的点是要避免维度灾难。
2. presto java8写的，代码质量非常高。设计：纯内存，没有容错，一个task失败就整个query fail。需要注意调整内存相关，线程数等参数，容易OOM。benchmark还行。支持标准SQL
3. spark sql 个人觉得支持查询Hive的数据，支持HQL非常重要，因为很多公司以前的数据都是放在Hive上的。
重点：没有一个OLAP引擎能同时在数据量，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。
来源：CSDN
作者：秦岭熊猫
链接：https://blog.csdn.net/tianshan2010/article/details/103484830