首先，在技术上几乎没有难点，基于强大的开源中间件实现实时数据仓库的需求已经变得没有那么困难。其次，实时数仓的建设一定是伴随着业务的发展而发展，武断的认为Kappa架构一定是最好的实时数仓架构是不对的。实际情况中随着业务的发展数仓的架构变得没有那么非此即彼。

在整个实时数仓的建设中，OLAP数据库的选型直接制约实时数仓的可用性和功能性。接着我将从业内几个典型的数仓建设和发展情况入手，从架构、技术选型和优缺点分别给大家分析现在市场上的开源OLAP引擎，旨在方便大家技术选型过程中能够根据实际业务进行选择。

传统的离线数据仓库将业务数据集中进行存储后，以固定的计算逻辑定时进行ETL和其它建模后产出报表等应用。离线数据仓库主要是构建T+1的离线数据，通过定时任务每天拉取增量数据，然后创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口。计算和数据的实时性均较差，业务人员无法根据自己的即时性需要获取几分钟之前的实时数据。数据本身的价值随着时间的流逝会逐步减弱，因此数据发生后必须尽快的达到用户的手中，实时数仓的构建需求也应运而生。

总之就是一句话：时效性的要求。

菜鸟的实时数仓整体设计如上图，基于业务系统的数据，数据模型是传统的分层汇总设计（明细/轻度汇总/高度汇总）；计算引擎，选择的是阿里内部的Blink；数据访问用天工接入(天工是一个连接多种数据源的工具，目的是屏蔽大量的对各种数据库的直连)；数据应用对应的是菜鸟的各个业务。

菜鸟的实时数仓的架构设计是一个很典型很经得起考验的设计。实时数据接入部分通过消息中间件(开源大数据领域非Kafka莫属，Pulsar是后起之秀)，Hbase作为高度汇总的K-V查询辅助。

那么大量的对业务的直接支撑在哪里？在这里：ADS。

ADS（后更名为ADB，加入新特性）是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算数据库。

参考：https://help.aliyun.com/document_detail/93838.html

经典的实时数据清洗场景

经典的实时数仓场景

在ADB的官方文档中给出了ADB的能力：

知乎的实时数仓实践以及架构的演进分为三个阶段：

2.0在技术架构上，增加了指标汇总层，指标汇总层是由明细层或者明细汇总层通过聚合计算得到，这一层产出了绝大部分的实时数仓指标，这也是与实时数仓 1.0 最大的区别。

技术选型上，知乎根据不同业务场景选择了HBase 和 Redis 作为实时指标的存储引擎，在OLAP选型上，知乎选择了Druid。

知乎实时多维分析平台架构

Druid 整体架构

Druid是一个高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。

Druid采用的架构:

Druid设计的三个原则:

如果你对Druid不了解，请参考这里：https://zhuanlan.zhihu.com/p/35146892

美团实时数仓数据分层架构

美团的技术方案由以下四层构成：

根据不同业务场景，实时数仓各个模型层次使用的存储方案和OLAP引擎如下：

总之，在OLAP选型上同样以Druid为主。

网易严选的实时数仓整体框架依据数据的流向分为不同的层次，接入层会依据各种数据接入工具收集各个业务系统的数据。消息队列的数据既是离线数仓的原始数据，也是实时计算的原始数据，这样可以保证实时和离线的原始数据是统一的。

在计算层经过 Flink+实时计算引擎做一些加工处理，然后落地到存储层中不同存储介质当中。不同的存储介质是依据不同的应用场景来选择。框架中还有Flink和Kafka的交互，在数据上进行一个分层设计，计算引擎从Kafka中捞取数据做一些加工然后放回Kafka。在存储层加工好的数据会通过服务层的两个服务：统一查询、指标管理，统一查询是通过业务方调取数据接口的一个服务，指标管理是对数据指标的定义和管理工作。通过服务层应用到不同的数据应用，数据应用可能是我们的正式产品或者直接的业务系统。

基于以上的设计，技术选型如下：

对于存储层会依据不同的数据层的特点选择不同的存储介质，ODS层和DWD层都是存储的一些实时数据，选择的是Kafka进行存储，在DWD层会关联一些历史明细数据，会将其放到 Redis 里面。在DIM层主要做一些高并发维度的查询关联，一般将其存放在HBase里面，对于DIM层比较复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式。对于常见的指标汇总模型直接放在 MySQL 里面，维度比较多的、写入更新比较大的模型会放在HBase里面，还有明细数据需要做一些多维分析或者关联会将其存储在Greenplum里面，还有一种是维度比较多、需要做排序、查询要求比较高的，如活动期间用户的销售列表等大列表直接存储在Redis里面。

网易严选选择了GreenPulm、Hbase、Redis和MySQL作为数据的计算和透出层。

GreenPulm的技术特点如下：

如果你对GreenPulm不熟悉可以参考这里：https://www.cnblogs.com/wujin/p/6781264.html

我们通过以上的分析可以看出，在整个实时数仓的建设中，业界已经有了成熟的方案。

整体架构设计通过分层设计为OLAP查询分担压力，让出计算空间，复杂的计算统一在实时计算层处理掉，避免给OLAP查询带来过大的压力。汇总计算交给OLAP数据库进行。

由此可见，在整个架构中实时计算一般是Spark+Flink配合，消息队列Kafka一家独大，在整个大数据领域消息队列的应用中仍然处理垄断地位，后来者Pulsar想要做出超越难度很大，Hbase、Redis和MySQL都在特定场景下有一席之地。

唯独在OLAP领域，百家争鸣，各有所长。

上面我们讲到实时数仓的建设，互联网大数据技术发展到今天，各个领域基本已经成熟，有各式各样的解决方案可以供我们选择。

在实时数仓建设中，解决方案成熟，消息队列Kafka、Redis、Hbase鲜有敌手，几乎已成垄断之势。而OLAP的选择则制约整个实时数仓的能力。

开源盛世的今天，可以供我们选择和使用的OLAP数据库令人眼花缭乱，下面我们选取了几个最常用的OLAP开源数据引擎进行分析，希望能给正在做技术选型和未来架构升级的你提供一些帮助。

本文给出了常用的开源OLAP引擎的性能测评：https://blog.csdn.net/oDaiLiDong/article/details/8657021

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也可以说是多维数据分析工具的集合。

E.F.Codd提出了关于OLAP的12条准则：

一言以蔽之：

• OLTP系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，强调事务性；

• OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区。

目前市面上主流的开源OLAP引擎包含不限于：Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等，可以说目前没有一个引擎能在数据量，灵活程度和性能上做到完美，用户需要根据自己的需求进行选型。

组件特点和简介：

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是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，能编写 SQL UDF，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。

一个典型的Hawq集群组件如下：

网络上有人对Hawq与Hive查询性能进行了对比测试，总体来看，使用Hawq内部表比Hive快的多（4-50倍）。

SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成,可以将结构化数据作为 Spark 的 RDD 进行查询。SparkSQL作为Spark生态的一员继续发展，而不再受限于Hive，只是兼容Hive。

Spark SQL在整个Spark体系中的位置如下：

SparkSQL的架构图如下：

Spark SQL对熟悉Spark的同学来说，很容易理解并上手使用：

这是Presto官方的简介：

Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark SQL有很大的相似性，这是它区别于Hive的最根本的区别。

但Presto由于是基于内存的，而hive是在磁盘上读写的，因此presto比hive快很多，但是由于是基于内存的计算当多张大表关联操作时易引起内存溢出错误。

提到Kylin就不得不说说ROLAP和MOLAP：

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

Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

Kylin的优势有：

所以适合Kylin的场景包括：

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

Impala也是一个SQL on Hadoop的查询工具，底层采用MPP技术，支持快速交互式SQL查询。与Hive共享元数据存储。Impalad是核心进程，负责接收查询请求并向多个数据节点分发任务。statestored进程负责监控所有Impalad进程，并向集群中的节点报告各个Impalad进程的状态。catalogd进程负责广播通知元数据的最新信息。

Impala的架构图如下：

Impala的特性包括：

同样，Impala经常会和Hive、Presto放在一起做比较。

Impala的劣势也同样明显：

Druid 是一种能对历史和实时数据提供亚秒级别的查询的数据存储。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。

Druid解决的问题包括：数据的快速摄入和数据的快速查询。

所以要理解Druid，需要将其理解为两个系统，即输入系统和查询系统。

Druid的架构如下：

Druid的特点包括：

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

我个人对Druid的理解在于，Druid保证数据实时写入，但查询上对SQL支持的不够完善(不支持Join)，适合将清洗好的记录实时录入，然后迅速查询包含历史的结果，在我们目前的业务上没有实际应用。

Druid的应用可以参考：

Greenplum是一个开源的大规模并行数据分析引擎。借助MPP架构，在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。

GPDB完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展；从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。支持分布式事务，支持ACID。保证数据的强一致性。做为分布式数据库，拥有良好的线性扩展能力。GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，Cognos，Informatic，Tableau等；也可以很多种开源软件集成，譬如Pentaho,Talend 等。

GreenPulm的架构如下：

GreenPulm的技术特点如下：

一个重要的信息：Greenplum基于Postgresql，也就是说GreenPulm和TiDB的定位类似，想要在OLTP和OLAP上进行统一。

官网对ClickHouse的介绍：

Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。Yandex是俄罗斯搜索引擎公司。官方提供的文档表名，ClickHouse 日处理记录数"十亿级"。

特性：

大家对Nginx不陌生吧，战斗民族开源的软件普遍的特点：轻量级，快快快。

ClickHouse最大的特点就是快，快，快，重要的话说三遍！

与Hadoop、Spark这些巨无霸组件相比，ClickHouse很轻量级，其特点：

使用ClickHouse也有其本身的限制，包括：

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

如果你的场景是基于HDFS的离线计算任务，那么Hive，Hawq和Imapla就是你的调研目标；

如果你的场景解决分布式查询问题，有一定的实时性要求，那么Presto和SparkSQL可能更符合你的期望；

如果你的汇总维度比较固定，实时性要求较高，可以通过用户配置的维度+指标进行预计算，那么不妨尝试Kylin和Druid；

ClickHouse则在单表查询性能上独领风骚，远超其他的OLAP数据库；

Greenpulm作为关系型数据库产品，性能可以随着集群的扩展线性增长，更加适合进行数据分析。

就像美团在调研Kylin的报告中所说的：

目前还没有一个OLAP系统能够满足各种场景的查询需求。

其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。