Olap（On-line Analytical Processing，联机分析处理）：是在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。可以比较下其与传统的OLTP（On-line Transaction Processing，联机事务处理）的区别来看一下它的特点：

OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储，以及多维模型多视角多层次的数据组织形式。

常见的OLAP介绍：

Hive、SparkSql、FlinkSql、ClickHouse、ES、Druid、Kylin、Impala、Doris。

以上列举的引擎各有优缺点，需要根据自己的实际需求进行选择。

Hive：

Hive是一个分布式SQL on Hadoop方案，底层依赖MapReduce计算模型执行分布式计算。Hive擅长执行长时间运行的离线批处理，数据量越大，优势越明显。Hive在数据量大、数据驱动需求强烈的互联网大厂比较流行。近2年，随着clickhouse的逐渐流行，对于一些总数据量不超过百PB级别的互联网数据仓库需求，已经有多家公司改为了clickhouse的方案。clickhouse的优势是单个查询执行速度更快，不依赖hadoop，架构和运维更简单。

SparkSql和FlinkSql：

在大部分场景下，Hive计算还是太慢了，别说不能满足那些要求高QPS、低查询延迟的的对外在线服务的需求，就连企业内部的产品、运营、数据分析师也会经常抱怨Hive执行ad-hoc查询太慢。这些痛点，推动了MPP内存迭代和DAG计算模型的诞生和发展，诸如Spark SQL、Flink SQL、Presto这些技术，目前在企业中也非常流行。Spark SQL、Flink SQL的执行速度更快，编程API丰富，同时支持流式计算与批处理，并且有流批统一的趋势，使大数据应用更简单。（QPS低）

Clickhouse：

ClickHouse部署架构简单，易用，不依赖Hadoop体系（HDFS+YARN）。它比较擅长的地方是对一个大数据量的单表进行聚合查询。Clickhouse用C++实现，底层实现具备向量化执行（Vectorized Execution）、减枝等优化能力，具备强劲的查询性能。目前在互联网企业均有广泛使用，比较适合内部BI报表型应用，可以提供低延迟（ms级别）的响应速度，也就是说单个查询非常快。但是Clickhouse也有它的局限性，在OLAP技术选型的时候，应该避免把它作为多表关联查询(JOIN)的引擎，也应该避免把它用在期望支撑高并发数据查询的场景，OLAP分析场景中，一般认为QPS达到1000+就算高并发，而不是像电商、抢红包等业务场景中，10W以上才算高并发，毕竟数据分析场景，数据海量，计算复杂，QPS能够达到1000已经非常不容易。例如Clickhouse，如果如数据量是TB级别，聚合计算稍复杂一点，单集群QPS一般达到100已经很困难了，所以它更适合企业内部BI报表应用，而不适合如数十万的广告主报表或者数百万的淘宝店主相关报表应用。Clickhouse的执行模型决定了它会尽全力来执行一个Query，而不是同时执行很多Query。

ES:

用Elasticsearch作为OLAP引擎，有几项优势：（1）擅长高QPS（QPS > 1K）、低延迟、过滤条件多、查询模式简单（如点查、简单聚合）的查询场景。（2）集群自动化管理能力（shard allocation，recovery）能力非常强。集群、索引管理和查看的API非常丰富。

用Elasticsearch作为OLAP引擎，有几项劣势：多维度分组排序、分页。不支持Join。在做aggregation后，由于返回的数据嵌套层次太多，数据量会过于膨胀。

Impala：

Impala 是 Cloudera 在受到 Google 的 Dremel 启发下开发的实时交互SQL大数据查询工具，是CDH 平台首选的 PB 级大数据实时查询分析引擎。它拥有和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 和统计函数查询数据，从而大大降低了延迟。Impala经常搭配存储引擎Kudu一起提供服务，这么做最大的优势是点查比较快，并且支持数据的Update和Delete。

Doris：

现代化MPP架构

支持大规模数据集、集群灵活扩展

支持高并发小查询

强悍的SQL执行引擎、全新的预聚合技术

支持亚秒级OLAP多维分析

现代化MPP架构

一支持大规模数据集、集群灵活扩展一支持高并发小查询

强悍的SQL执行引擎、全新的预聚合技术一支持亚秒级OLAP多维分析

支持高效快速的多表关联分析

基于LSM的列式存储引擎、MVCC事务隔离机制

支持数据高效的实时导入

支持数据批量、实时更新

Druid：

Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。Druid支持更大的数据规模，具备一定的预聚合能力，通过倒排索引和位图索引进一步优化查询性能，在广告分析场景、监控报警等时序类应用均有广泛使用。

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

与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等。

Kylin:

Kylin自身就是一个MOLAP系统，多维立方体（MOLAP Cube）的设计使得用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。

适合Kylin的场景包括：

• 用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上
• 每天有数G甚至数十G的数据增量导入
• 有10个以内较为固定的分析维度

简单来说，Kylin中数据立方的思想就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有N个纬度，就会有2的N次种组合。所以最好控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。

	Hive	Spark/FlinkSQL	ClickHouse	Impala	Kylin	Doris	Druid	ES
延迟	分钟	秒	明细查询较低，单表查询性能 高，Join在一些情况下性能不佳 物化视图查询延迟非常低	秒	亚秒	毫秒	亚秒	秒
SQL	较完善	较完善	有限	有限	有限	较完善	较完善	有限
发展定位	Mpp On hadoop	mpp	明细动态聚合查询 物化视图	Mpp On hadoop	完全预聚合立方体	MPP 整合Google Mesa（数据模型），Apache Impala（MPPQuery Engine) 和 Apache ORCFile (存储格式，编码和压缩) 的技术	位图索引查询、编码。预聚合技术，但是只聚合最细的维度组合，在此基础进行聚合	主要是搜索引擎
Join	支持	支持	部分支持	支持	支持	支持	不成熟	不支持
优点	可靠性高	较hive快	单表性能极佳	多表关联性能不错	超大数据集	使用成本低	超大数据集	QPS高
缺点	慢	性能不突出	多表关联性能不佳，使用成本高	占内存	灵活性差，数据膨胀	单表性能较CK差	不适合复杂查询	不适合关联查询

 参考：实际应用中如果作为报表工具，如果依赖hadoop，对时间敏感可选择impala，kylin等，如果对时间不敏感可选择spark，hive等。如果不依赖hadoop，可从clickhouse和doris中进行选择，clickhouse相对来说功能更强大，对应的也是运维和开发成本高，单机性能更优秀，但性能较依赖服务器的核数，且与单台服务器的内存有关；doris与clickhouse对比，单表性能ck更好，多表或者复杂的sql场景，diris性能更好，doris使用和运维成本低，与MySQL协议兼容，支持直接使用MySQL客户端连接，非常易用的数据应用对接。。