你须要的不是实时数仓 | 你须要的是一款强大的OLAP数据库(下)

在上一章节中，咱们讲到实时数仓的建设，互联网大数据技术发展到今天，各个领域基本已经成熟，有各式各样的解决方案能够供咱们选择。

在实时数仓建设中，解决方案成熟，消息队列Kafka、Redis、Hbase鲜有敌手，几乎已成垄断之势。而OLAP的选择则制约整个实时数仓的能力。开源盛世的今天，能够供咱们选择和使用的OLAP数据库使人眼花缭乱，这章咱们选取了几个最经常使用的OLAP开源数据引擎进行分析，但愿能给正在作技术选型和将来架构升级的你提供一些帮助。

本文给出了经常使用的开源OLAP引擎的性能测评：
https://blog.csdn.net/oDaiLiD...

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

https://hive.apache.org/

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

http://hawq.apache.org
https://blog.csdn.net/wzy0623...
https://www.oschina.net/p/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倍）。
原文连接：https://blog.csdn.net/wzy0623...

Spark SQL

https://spark.apache.org/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

https://prestodb.github.io/

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 自己并不存储数据，可是能够接入多种数据源，而且支持跨数据源的级联查询。

https://blog.csdn.net/u012535...
Presto没有使用MapReduce，它是经过一个定制的查询和执行引擎来完成的。它的全部的查询处理是在内存中，这也是它的性能很高的一个主要缘由。Presto和Spark SQL有很大的类似性，这是它区别于Hive的最根本的区别。

但Presto因为是基于内存的，而hive是在磁盘上读写的，所以presto比hive快不少，可是因为是基于内存的计算当多张大表关联操做时易引发内存溢出错误。

https://www.cnblogs.com/tgzhu...

Kylin

http://kylin.apache.org/cn/
https://www.infoq.cn/article/...
提到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

https://impala.apache.org/

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、Bzip二、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

https://druid.apache.org/
https://blog.csdn.net/warren2...

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)，适合将清洗好的记录实时录入，而后迅速查询包含历史的结果，在咱们目前的业务上没有实际应用。

Druid的应用能够参考：
《Druid 在有赞的使用场景及应用实践》https://blog.csdn.net/weixin_...

Greeplum

https://greenplum.org/

https://blog.csdn.net/yongshe...
https://www.jianshu.com/p/b5c...

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

https://clickhouse.yandex/
https://clickhouse.yandex/doc...
http://www.clickhouse.com.cn/
https://www.jianshu.com/p/a5b...

官网对ClickHouse的介绍：

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系统可以知足各类场景的查询需求。
其本质缘由是，没有一个系统能同时在数据量、性能、和灵活性三个方面作到完美，每一个系统在设计时都须要在这三者间作出取舍。

欢迎扫码关注个人公众号，回复【JAVAPDF】能够得到一份200页秋招面试题！