几种OLAP引擎简单对比

Kudu VS Clickhouse

kudu 2015年9月28号出现第一个测试版本0.5.0，2016年2月26第一个正式版0.7.发布。clickhouse 2018年3月开源正式版出现。两者都是列式存储，都可以针对数据进行实时OLAP分析，两者的区别如下：

方面	Kudu	ClickHouse
架构设计	Kudu是Master-slave的架构，Master挂掉不能工作。	Clickhouse每台Server的地位都是等价的，是multi-master模式。解决单点故障。
元数据管理	Kudu使用Master Server管理元数据。	ClickHouse使用Zookeeper管理元数据。
SQL支持	Kudu不支持标准SQL,有put，get等api代码操作；与Impala整合后支持SQL操作。	ClickHouse对于标准SQL的支持相对完好。
应用场景	Kudu应用主要是随机读写且兼容大批量读取操作场景，生产中经常与Impala集成，也可做OLAP分析。	Clickhouse应用场景主要是实时OLAP分析。不是太擅长随机读数据。
数据CRUD	Kudu支持数据更新，删除操作，可以通过api代码实现，也可以通过与impala整合SQL实现；仅支持单条数据的事务。Kudu对数据快速读取和快速插入数据的场景支持比较好，原子数据查询延迟低，与Impala整合可以做OLAP操作。	ClickHouse是分析型列式数据库，处理的数据一般不变化，变化一般也不会更新，对于update,delete的支持比较脆弱，实际上clickhouse不支持标准的update和delete操作，通过alter操作实现；不支持事务。ClickHouse最好大批量插入数据，对数据原子行大量读取，效率不高，延迟大，主要做OLAP分析操作。
扩展性	Kudu由于Tablet Server的特殊结构，扩展性差，支持300个节点。	ClickHouse集群节点无上限。

ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为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。

OLAP执行模型

Scatter-Gather执行模型：相当于MapReduce中的一趟Map和Reduce，没有多轮的迭代，而且中间计算结果往往存储在内存中，通过网络直接交换。Elasticsearch、Druid、Kylin都是此模型。
MapReduce：Hive是此模型
MPP：MPP学名是大规模并行计算，其实很难给它一个准确的定义。如果说的宽泛一点，Presto、Impala、Doris、Clickhouse、Spark SQL、Flink SQL这些都算。有人说Spark SQL和Flink SQL属于DAG模型，我们思考后认为，DAG并不算一种单独的模型，它只是生成执行计划的一种方式。

Presto

Presto、Impala、GreenPlum均基于MPP架构，相比Elasticsearch、Druid、Kylin这样的简单Scatter-Gather模型，在支持的SQL计算上更加通用，更适合ad-hoc查询场景，然而这些通用系统往往比专用系统更难做性能优化，所以不太适合做对查询QPS(参考值QPS > 1000)、延迟要求比较高(参考值search latency < 500ms)的在线服务，更适合做公司内部的查询服务和加速Hive查询的服务。Presto还有一个优秀的特性是使用了ANSI标准SQL，并且支持超过30+的数据源Connector。这里我们给读者留下一个思考题：以Presto为代表的MPP模型与Hive为代表的MapReduce模型的性能差异比较大的原因是什么？

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。