| 编辑推荐: |
本文主要讲解：为什么要构建实时数据仓库、菜鸟、知乎、美团、网易实时数仓方案、各个开源
OLAP 数据库的优缺点、我们该如何做技术选型。
本文来自知乎，由火龙果软件Anna编辑、推荐。 |
|
在开源盛世的今天，实时数仓的建设业界已经有了成熟的方案。技术选型上实时计算、消息队列都有最优解，唯独在
OLAP 领域，百家争鸣，各有所长。
大数据领域开源 OLAP 引擎包括不限于 Hive、Hawq、Presto、Kylin、Impala、SparkSQL、Druid、Clickhouse、Greeplum
等等。我们就各个常用开源 OLAP 引擎的优缺点和使用场景做出详细对比，让开发者进行技术选型时做到心中有数。
前言
今年有个现象，实时数仓建设突然就被大家所关注。我个人在公众号也写过和转载过几篇关于实时数据仓库的文章和方案。
但是对于实时数仓的狂热追求大可不必。
首先，在技术上几乎没有难点，基于强大的开源中间件实现实时数据仓库的需求已经变得没有那么困难。其次，实时数仓的建设一定是伴随着业务的发展而发展，武断的认为Kappa架构一定是最好的实时数仓架构是不对的。实际情况中随着业务的发展数仓的架构变得没有那么非此即彼。
在整个实时数仓的建设中，OLAP数据库的选型直接制约实时数仓的可用性和功能性。本文从业内几个典型的数仓建设和发展情况入手，从架构、技术选型和优缺点分别给大家分析现在市场上的开源OLAP引擎，旨在方便大家技术选型过程中能够根据实际业务进行选择。
管中窥豹-菜鸟/知乎/美团/网易严选实时数仓建设
为什么要构建实时数据仓库
传统的离线数据仓库将业务数据集中进行存储后，以固定的计算逻辑定时进行ETL和其它建模后产出报表等应用。离线数据仓库主要是构建T+1的离线数据，通过定时任务每天拉取增量数据，然后创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口。计算和数据的实时性均较差，业务人员无法根据自己的即时性需要获取几分钟之前的实时数据。数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快的达到用户的手中，实时数仓的构建需求也应运而生。
总之就是一句话：时效性的要求。
阿里菜鸟的实时数仓设计
菜鸟的实时数仓整体设计如上图，基于业务系统的数据，数据模型是传统的分层汇总设计（明细/轻度汇总/高度汇总）；计算引擎，选择的是阿里内部的Blink；数据访问用天工接入(天工是一个连接多种数据源的工具，目的是屏蔽大量的对各种数据库的直连)；数据应用对应的是菜鸟的各个业务。
菜鸟的实时数仓的架构设计是一个很典型很经得起考验的设计。实时数据接入部分通过消息中间件(开源大数据领域非Kafka莫属，Pulsar是后起之秀)，Hbase作为高度汇总的K-V查询辅助。
那么大量的对业务的直接支撑在哪里？在这里：ADS。
ADS（后更名为ADB，加入新特性）是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime
OLAP）云计算数据库。参考
经典的实时数据清洗场景
经典的实时数仓场景
在ADB的官方文档中给出了ADB的能力：
快ADB采用MPP+DAG融合引擎，采用行列混存技术、自动索引等技术，可以快速扩容至数千节点。
灵活随意调整节点数量和动态升降配实例规格。
易用全面兼容MySQL协议和SQL
超大规模全分布式结构，无任何单点设计，方便横向扩展增加SQL处理并发。
高并发写入小规模的10万TPS写入能力，通过横向扩容节点提升至200万+TPS的写入能力。实时写入数据后，约1秒左右即可查询分析。单个表最大支持2PB数据，十万亿记录。
知乎的实时数仓设计
知乎的实时数仓实践以及架构的演进分为三个阶段：
实时数仓 1.0 版本，主题： ETL 逻辑实时化，技术方案：Spark Streaming
实时数仓 2.0 版本，主题：数据分层，指标计算实时化，技术方案：Flink Streaming
实时数仓未来展望：Streaming SQL 平台化，元信息管理系统化，结果验收自动化
实时数仓 1.0 版本
实时数仓 2.0 版本
在技术架构上，增加了指标汇总层，指标汇总层是由明细层或者明细汇总层通过聚合计算得到，这一层产出了绝大部分的实时数仓指标，这也是与实时数仓
1.0 最大的区别。
技术选型上，知乎根据不同业务场景选择了HBase 和 Redis
作为实时指标的存储引擎，在OLAP选型上，知乎选择了Druid。
知乎实时多维分析平台
架构Druid 整体架构
Druid是一个高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。Druid采用的架构:
shared-nothing架构与lambda架构
Druid设计的三个原则:
快速查询：部分数据聚合（Partial Aggregate） + 内存化（In-Memory） +
索引（Index）
水平拓展能力：分布式数据（Distributed data）+并行化查询（Parallelizable
Query）
实时分析：Immutable Past , Append-Only Future
美团的实时数仓设计
美团实时数仓数据分层架构
美团的技术方案由以下四层构成：
ODS 层：Binlog 和流量日志以及各业务实时队列。
数据明细层：业务领域整合提取事实数据，离线全量和实时变化数据构建实时维度数据。
数据汇总层：使用宽表模型对明细数据补充维度数据，对共性指标进行汇总。
App 层：为了具体需求而构建的应用层，通过 RPC 框架对外提供服务。
根据不同业务场景，实时数仓各个模型层次使用的存储方案和OLAP引擎如下：
数据明细层 对于维度数据部分场景下关联的频率可达 10w+ TPS，我们选择 Cellar（美团内部分布式K-V存储系统，类似Redis）
作为存储，封装维度服务为实时数仓提供维度数据。
数据汇总层 对于通用的汇总指标，需要进行历史数据关联的数据，采用和维度数据一样的方案通过 Cellar
作为存储，用服务的方式进行关联操作。
数据应用层 应用层设计相对复杂，再对比了几种不同存储方案后。我们制定了以数据读写频率 1000 QPS
为分界的判断依据。对于读写平均频率高于 1000 QPS 但查询不太复杂的实时应用，比如商户实时的经营数据。采用
Cellar 为存储，提供实时数据服务。对于一些查询复杂的和需要明细列表的应用，使用 Elasticsearch
作为存储则更为合适。而一些查询频率低，比如一些内部运营的数据。 Druid 通过实时处理消息构建索引，并通过预聚合可以快速的提供实时数据
OLAP 分析功能。对于一些历史版本的数据产品进行实时化改造时，也可以使用 MySQL 存储便于产品迭代。
总之，在OLAP选型上同样以Druid为主。
网易严选的实时数仓设计
网易严选的实时数仓整体框架依据数据的流向分为不同的层次，接入层会依据各种数据接入工具
收集各个业务系统的数据。消息队列的数据既是离线数仓的原始数据，也是实时计算的原始数据，这样可以保证实时和离线的原始数据是统一的。
在计算层经过 Flink+实时计算引擎做一些加工处理，然后落地到存储层中不同存储介质当中。不同的存储介质是依据不同的应用场景来选择。框架中还有Flink和Kafka的交互，在数据上进行一个分层设计，计算引擎从Kafka中捞取数据做一些加工然后放回Kafka。在存储层加工好的数据会通过服务层的两个服务：统一查询、指标管理，统一查询是通过业务方调取数据接口的一个服务，指标管理是对数据指标的定义和管理工作。通过服务层应用到不同的数据应用，数据应用可能是我们的正式产品或者直接的业务系统。
基于以上的设计，技术选型如下：
对于存储层会依据不同的数据层的特点选择不同的存储介质，ODS层和DWD层都是存储的一些实时数据，选择的是Kafka进行存储，在DWD层会关联一些历史明细数据，会将其放到
Redis 里面。在DIM层主要做一些高并发维度的查询关联，一般将其存放在HBase里面，对于DIM层比价复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式。对于常见的指标汇总模型直接放在
MySQL 里面，维度比较多的、写入更新比较大的模型会放在HBase里面，还有明细数据需要做一些多维分析或者关联会将其存储在Greenplum里面，还有一种是维度比较多、需要做排序、查询要求比较高的，如活动期间用户的销售列表等大列表直接存储在Redis里面。
网易严选选择了GreenPulm、Hbase、Redis和MySQL作为数据的计算和透出层。
GreenPulm的技术特点如下：
支持海量数据存储和处理
支持Just In Time BI：通过准实时、实时的数据加载方式，实现数据仓库的实时更新，进而实现动态数据仓库（ADW），基于动态数据仓库，业务用户能对当前业务数据进行BI实时分析（Just
In Time BI）
支持主流的sql语法，使用起来十分方便，学习成本低
扩展性好，支持多语言的自定义函数和自定义类型等
提供了大量的维护工具，使用维护起来很方便
支持线性扩展：采用MPP并行处理架构。在MPP结构中增加节点就可以线性提供系统的存储容量和处理能力
较好的并发支持及高可用性支持除了提供硬件级的Raid技术外，还提供数据库层Mirror机制保护，提供Master/Stand
by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务
支持MapReduce：一种大规模数据分析技术
数据库内部压缩
总结
我们通过以上的分析可以看出，在整个实时数仓的建设中，业界已经有了成熟的方案。整体架构设计通过分层设计为OLAP查询分担压力，让出计算空间，复杂的计算统一在实时计算层做，避免给OLAP查询带来过大的压力。汇总计算教给OLAP数据库进行。我们可以这么说，在整个架构中实时计算一般是Spark+Flink配合，消息队列Kafka一家独大，整个大数据领域消息队列的应用中仍然处理垄断地位，后来者Pulsar想做出超越难度很大，Hbase、Redis和MySQL都在特定场景下有一席之地。唯独在OLAP领域，百家争鸣，各有所长。大数据领域开源OLAP引擎包括但是不限于Hive、Druid、Hawq、Presto、Impala、Sparksql、Clickhouse、Greenplum等等。下一篇我们就各个开源OLAP引擎的优缺点和使用场景做出详细对比，让开发者进行技术选型时做到心中有数。
OLAP百家争鸣
OLAP简介
OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫DSS决策支持系统，就是我们说的数据仓库。与此相对的是OLTP（on-line
transaction processing）联机事务处理系统。
联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的。OLAP的提出引起了很大的反响，OLAP作为一类产品同联机事务处理
(OLTP) 明显区分开来。
Codd认为联机事务处理（OLTP）已不能满足终端用户对数据库查询分析的要求，SQL对大数据库的简单查询也不能满足用户分析的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Codd提出了多维数据库和多维分析的概念，即OLAP。
OLAP委员会对联机分析处理的定义为：从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业多维特性的数据称为信息数据，使分析人员、管理人员或执行人员能够从多种角度对信息数据进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是"维"这个概念，因此OLAP也可以说是多维数据分析工具的集合。
OLAP的准则和特性
E.F.Codd提出了关于OLAP的12条准则：
准则1 OLAP模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力准则
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次
一言以蔽之：
OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性；OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。
OLAP开源引擎
目前市面上主流的开源OLAP引擎包含不限于：Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。
组件特点和简介
Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。其优点是学习成本低，可以通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
对于hive主要针对的是OLAP应用，其底层是hdfs分布式文件系统，hive一般只用于查询分析统计，而不能是常见的CUD操作，Hive需要从已有的数据库或日志进行同步最终入到hdfs文件系统中，当前要做到增量实时同步都相当困难。
Hive的优势是完善的SQL支持，极低的学习成本，自定义数据格式，极高的扩展性可轻松扩展到几千个节点等等。
但是Hive 在加载数据的过程中不会对数据进行任何处理，甚至不会对数据进行扫描，因此也没有对数据中的某些
Key 建立索引。Hive 要访问数据中满足条件的特定值时，需要暴力扫描整个数据库，因此访问延迟较高。
Hive真的太慢了。大数据量聚合计算或者联表查询，Hive的耗时动辄以小时计算，在某一个瞬间，我甚至想把它开除出OLAP"国籍"，但是不得不承认Hive仍然是基于Hadoop体系应用最广泛的OLAP引擎。
Hawq
Hawq是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用
MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。除了能高效处理本身的内部数据，还可通过
PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，能编写
SQL UDF，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ
都比较适用于构建 Hadoop 分析型数据仓库应用。
一个典型的Hawq集群组件如下：
网络上有人对Hawq与Hive查询性能进行了对比测试，总体来看，使用Hawq内部表比Hive快的多（4-50倍）。
Spark SQL
SparkSQL的前身是Shark，它将
SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。
Spark SQL在整个Spark体系中的位置如下：
SparkSQL的架构图如下：
Spark SQL对熟悉Spark的同学来说，很容易理解并上手使用：相比于Spark RDD API，Spark
SQL包含了对结构化数据和在其上运算的更多信息，Spark SQL使用这些信息进行了额外的优化，使对结构化数据的操作更加高效和方便。SQL提供了一个通用的方式来访问各式各样的数据源，包括Hive,
Avro, Parquet, ORC, JSON, and JDBC。Hive兼容性极好。
Presto
Presto is an open source distributed SQL query engine
for running interactive analytic queries against data
sources of all sizes ranging from gigabytes to petabytes.Presto
allows querying data where it lives, including Hive,
Cassandra, relational databases or even proprietary
data stores. A single Presto query can combine data
from multiple sources, allowing for analytics across
your entire organization. Presto is targeted at analysts
who expect response times ranging from sub-second to
minutes. Presto breaks the false choice between having
fast analytics using an expensive commercial solution
or using a slow "free" solution that requires
excessive hardware.
这是Presto官方的简介。Presto 是由 Facebook 开源的大数据分布式 SQL 查询引擎，适用于交互式分析查询，可支持众多的数据源，包括
HDFS，RDBMS，KAFKA 等，而且提供了非常友好的接口开发数据源连接器。
Presto支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window
functions)。作为Hive和Pig（Hive和Pig都是通过MapReduce的管道流来完成HDFS数据的查询）的替代者，Presto
本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。
Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark
SQL有很大的相似性，这是它区别于Hive的最根本的区别。
但Presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误。
Kylin
提到Kylin
就不得不说说ROLAP和MOLAP。
传统OLAP根据数据存储方式的不同分为ROLAP（relational olap）以及MOLAP（multi-dimension
olap）
ROLAP 以关系模型的方式存储用作多为分析用的数据，优点在于存储体积小，查询方式灵活，然而缺点也显而易见，每次查询都需要对数据进行聚合计算，为了改善短板，ROLAP使用了列存、并行查询、查询优化、位图索引等技术。
MOLAP 将分析用的数据物理上存储为多维数组的形式，形成CUBE结构。维度的属性值映射成多维数组的下标或者下标范围，事实以多维数组的值存储在数组单元中，优势是查询快速，缺点是数据量不容易控制，可能会出现维度爆炸的问题。
而Kylin自身就是一个MOLAP系统，多维立方体（MOLAP Cube）的设计使得用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体进行数据的预聚合。
Apache Kylin是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay
Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
Kylin的优势有：
提供ANSI-SQL接口
交互式查询能力
MOLAP Cube 的概念
与BI工具可无缝整合
所以适合Kylin的场景包括：
用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上
每天有数G甚至数十G的数据增量导入
有10个以内较为固定的分析维度
简单来说，Kylin中数据立方的思想就是以空间换时间，通过定义一系列的纬度，对每个纬度的组合进行预先计算并存储。有N个纬度，就会有2的N次种组合。所以最好控制好纬度的数量，因为存储量会随着纬度的增加爆炸式的增长，产生灾难性后果。
Impala
Impala也是一个SQL
on Hadoop的查询工具，底层采用MPP技术，支持快速交互式SQL查询。与Hive共享元数据存储。Impalad是核心进程，负责接收查询请求并向多个数据节点分发任务。statestored进程负责监控所有Impalad进程，并向集群中的节点报告各个Impalad进程的状态。catalogd进程负责广播通知元数据的最新信息。
Impala的架构图如下：
Impala的特性包括：
支持Parquet、Avro、Text、RCFile、SequenceFile等多种文件格式
支持存储在HDFS、HBase、Amazon S3上的数据操作
支持多种压缩编码方式：Snappy、Gzip、Deflate、Bzip2、LZO
支持UDF和UDAF
自动以最有效的顺序进行表连接
允许定义查询的优先级排队策略
支持多用户并发查询
支持数据缓存
提供计算统计信息（COMPUTE STATS）
提供窗口函数（聚合 OVER PARTITION, RANK, LEAD, LAG, NTILE等等）以支持高级分析功能
支持使用磁盘进行连接和聚合，当操作使用的内存溢出时转为磁盘操作
允许在where子句中使用子查询
允许增量统计——只在新数据或改变的数据上执行统计计算
支持maps、structs、arrays上的复杂嵌套查询
可以使用impala插入或更新HBase
同样，Impala经常会和Hive、Presto放在一起做比较，Impala的劣势也同样明显：
Impala不提供任何对序列化和反序列化的支持。
Impala只能读取文本文件，而不能读取自定义二进制文件。
每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。这个缺点会导致正在执行的查询sql遇到刷新会挂起，查询不动。
Druid
Druid
是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。
Druid解决的问题包括：数据的快速摄入和数据的快速查询。所以要理解Druid，需要将其理解为两个系统，即输入系统和查询系统。
Druid的架构如下：
Druid的特点包括：
Druid实时的数据消费，真正做到数据摄入实时、查询结果实时
Druid支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发
Druid的核心是时间序列，把数据按照时间序列分批存储，十分适合用于对按时间进行统计分析的场景
Druid把数据列分为三类：时间戳、维度列、指标列
Druid不支持多表连接
Druid中的数据一般是使用其他计算框架(Spark等)预计算好的低层次统计数据
Druid不适合用于处理透视维度复杂多变的查询场景
Druid擅长的查询类型比较单一，一些常用的SQL(groupby 等)语句在druid里运行速度一般
Druid支持低延时的数据插入、更新，但是比hbase、传统数据库要慢很多
与其他的时序数据库类似，Druid在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，灵活性和扩展性不够，比如缺乏Join、子查询等。
我个人对Druid的理解在于，Druid保证数据实时写入，但查询上对SQL支持的不够完善(不支持Join)，适合将清洗好的记录实时录入，然后迅速查询包含历史的结果，在我们目前的业务上没有实际应用。
Greeplum
Greenplum是一个开源的大规模并行数据分析引擎。借助MPP架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。
GPDB完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展；从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。支持分布式事务，支持ACID。保证数据的强一致性。做为分布式数据库，拥有良好的线性扩展能力。GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多种开源软件集成，譬如Pentaho,Talend
等。
GreenPulm的架构如下：
GreenPulm的技术特点如下：
支持海量数据存储和处理
支持Just In Time BI：通过准实时、实时的数据加载方式，实现数据仓库的实时更新，进而实现动态数据仓库（ADW），基于动态数据仓库，业务用户能对当前业务数据进行BI实时分析（Just
In Time BI）
支持主流的sql语法，使用起来十分方便，学习成本低
扩展性好，支持多语言的自定义函数和自定义类型等
提供了大量的维护工具，使用维护起来很方便
支持线性扩展：采用MPP并行处理架构。在MPP结构中增加节点就可以线性提供系统的存储容量和处理能力
较好的并发支持及高可用性支持除了提供硬件级的Raid技术外，还提供数据库层Mirror机制保护，提供Master/Stand
by机制进行主节点容错，当主节点发生错误时，可以切换到Stand by节点继续服务
支持MapReduce
数据库内部压缩
一个重要的信息：Greenplum基于Postgresql，也就是说GreenPulm和TiDB的定位类似，想要在OLTP和OLAP上进行统一。
ClickHouse
官网对XClickHouse的介绍：
ClickHouse is an open source column-oriented database
management system capable of real time generation
of analytical data reports using SQL queries.
Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse
日处理记录数"十亿级"。
特性:采用列式存储；数据压缩；支持分片，并且同一个计算任务会在不同分片上并行执行，计算完成后会将结果汇总；支持SQL；支持联表查询；支持实时更新；自动多副本同步；支持索引；分布式存储查询。
大家都Nginx不陌生吧，战斗民族开源的软件普遍的特点包括：轻量级，快。
ClickHouse最大的特点就是快，快，快，重要的话说三遍！与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点：
列式存储数据库，数据压缩
关系型、支持SQL
分布式并行计算，把单机性能压榨到极限
高可用
数据量级在PB级别
实时数据更新
索引
使用ClickHouse也有其本身的限制，包括：
缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据。
没有完整的事务支持
不支持二级索引
有限的SQL支持，join实现与众不同
不支持窗口功能
元数据管理需要人工干预维护
总结
上面给出了常用的一些OLAP引擎，它们各自有各自的特点，我们将其分组：
Hive，Hawq，Impala - 基于SQL on Hadoop
Presto和Spark SQL类似 - 基于内存解析SQL生成执行计划
Kylin - 用空间换时间，预计算
Druid - 一个支持数据的实时摄入
ClickHouse - OLAP领域的Hbase，单表查询性能优势巨大
Greenpulm - OLAP领域的Postgresql
如果你的场景是基于HDFS的离线计算任务，那么Hive，Hawq和Imapla就是你的调研目标；如果你的场景解决分布式查询问题，有一定的实时性要求，那么Presto和SparkSQL可能更符合你的期望；如果你的汇总维度比较固定，实时性要求较高，可以通过用户配置的维度+指标进行预计算，那么不妨尝试Kylin和Druid；ClickHouse则在单表查询性能上独领风骚，远超过其他的OLAP数据库；Greenpulm作为关系型数据库产品，性能可以随着集群的扩展线性增长，更加适合进行数据分析。
就像美团在调研Kylin的报告中所说的：
目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。
|
