[大数据]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

Apache Hive TM

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
HAWQ技术解析（一） —— HAWQ简介_wzy0623的专栏-CSDN博客_hawq
Apache HAWQ首页、文档和下载 - 大规模并行 SQL 分析处理引擎 - OSCHINA - 中文开源技术交流社区

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倍）。
原文链接：HAWQ与Hive查询性能对比测试_wzy0623的专栏-CSDN博客_hawq hive

Spark SQL

Spark SQL & DataFrames | Apache Spark

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 | Distributed SQL Query Engine for Big Data

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 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。

hive和presto的一些对比_机器学习、数据挖掘-CSDN博客
Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。Presto和Spark SQL有很大的相似性，这是它区别于Hive的最根本的区别。

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

Presto架构及原理 - 天戈朱 - 博客园

Kylin

Apache Kylin | 大数据分析型数据仓库
Apache Kylin在美团数十亿数据OLAP场景下的实践-InfoQ
提到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

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 | Interactive Analytics at Scale
druid简要介绍_罡斩-CSDN博客

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

Druid解决的问题包括：数据的快速摄入和数据的快速查询。
所以要理解Druid，需要将其理解为两个系统，即输入系统和查询系统。

Druid的架构如下：

Druid的特点包括：

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

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

Greeplum

Greenplum Database

GreenPlum 浅谈_yongshenghuang的博客-CSDN博客_greenplum
Greenplum企业应用实战（笔记）：第一章 greenplum简介 - 简书

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

ClickHouse - fast open-source OLAP DBMS
ClickHouse 架构概述 | ClickHouse文档
ClickHouse中文社区
clickhouse 基础知识 - 简书

官网对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系统能够满足各种场景的查询需求。
其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。