OLAP - 基础知识点汇总（起源、发展、分类、常见OLAP引擎介绍及应用场景）
作者：hangge | 2024-09-03 09:00
一、基本介绍
1，什么是 OLAP？
联机分析处理（Online Analytical Processing，OLAP）是一种数据分析技术，用于支持复杂的分析操作，侧重为决策人员和高层管理人员提供决策支持。
2，OLAP 的起源
（1）20 世纪 60 年代，关系数据库之父 Edgar F.Codd 提出了关系模型，促进了联机事务处理 OLTP（On-line Transaction Processing）的发展。
（2）随着数据量的增加，以及查询需求的变化，OLTP 已不能满足终端用户对数据库查询分析的需要，SQL 对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，Edgar F.Codd 提出了多维数据库和多维分析的概念，这就是我们现在所说的联机分析处理。
（3）1993 年，OLAP 由关系数据库之父 Edgar F.Codd 在他的白皮书《Providing OLAP to User-Analysts: An IT Mandate》中首次提出。他当时总结了 OLAP 产品的 12 条评估规则，如下图示。
3，OLAP 与 OLTP 的区别
（1）OLTP 侧重于事务，OLAP 侧重于数据分析，二者的主要区别见下表：
| 比较项 | OLTP | OLAP |
| 操作对象 | 数据库中的数据 | 数据仓库中的数据 |
| 数据规模 | 小 | 大 |
| 并发访问 | 大 | 小 |
| 数据模型 | ER（实体关系） | 星型模型\雪花模型 |
| 数据时效 | 当前数据 | 历史数据 |
| 数据操作 | 增加、删除、修改、查询 | 不支持修改和删除 |
| 执行延迟 | 低 | 高 |
| 可扩展性 | 低 | 高 |
（2）具体说明如下：
- 操作对象：OLTP 操作的是数据库（例如 MySQL 和 Oracle）中的数据。OLAP 操作的是数据仓库（例如 Hive 和 Impala）中的数据。
- 数据规模：OLTP 操作的数据规模是比较小的，基本在几十万条，多的话可能会达到几百万条。OLAP 操作的数据规模是比较大的，起步一般都在上千万条，甚至上亿条。
- 并发访问：OLTP 操作一般面向 C 端用户，需要同时处理海量用户的请求，对并发访问的能力要求比较高。OLAP 操作的基本上都是企业内部的数据分析系统，用户规模很小，所以对并发访问的能力要求不高。
- 数据模型：OLTP 操作的数据模型基本上都是基于 ER 实体模型构建的，满足数据库三范式。OLAP 操作的数据模型基本上都是星型模型或雪花模型，为了提高数据分析效率，大部分都采用降维的方式构建宽表，基本上都不满足数据库三范式。
- 数据时效：OLTP 操作的是实时数据，OLAP 操作的基本上都是历史数据。当然了，随着技术的发展，OLAP 操作的数据也可以是实时数据。
- 数据操作：OLTP 系统可以提供增加、删除、修改、查询功能。OLAP 系统侧重于查询，基本上不支持修改和删除。
- 执行延迟：OLTP 操作的延迟是比较低的，例如：在 MySQL 中执行一条 SQL 语句，基本上“毫秒”级别即可返回结果。OLAP 操作的延迟是比较高的，例如：在 Hive 中执行一条 SQL 语句，基本上需要“分钟”级别才会返回结果。
- 可扩展性：OLTP 系统的扩展性比较低。OLAP 系统基本上都支持分布式，扩展性比较高。
二、OLAP 的发展历史
1，传统 OLAP 技术的发展
（1）根据 Edgar F.Codd 提出的 OLAP 产品 12 条评估规则，OLAP 技术有了很大的发展，市场上各种 OLAP 产品层出不穷。虽然 OLAP 的概念是在 1993 年才被提出来的，但是支持 OLAP 相关产品的历史最早可追溯到 1975 年，如下图所示。
（2）1989 年，SQL 语言标准诞生，它可以从关系数据库中提取和处理业务数据，这是一个转折点。在 1980 年代，电子表格在 OLAP 应用中占绝对主导地位。1990 年代以后，越来越多基于数据库的 OLAP 应用开始出现，如下图所示。
2，大数据 OLAP 技术的发展
随着大数据行业的兴起，基于大数据的 OLAP 技术也迎来了蓬勃发展。
三、OLAP 引擎的分类
对于大数据中的 OLAP 引擎，可以从数据建模方式和数据处理时效这两个维度进行划分。
1，从数据建模方式分类
（1）从数据建模方式（也可以称之为数据存储方式）这个维度进行划分，可以将 OLAP 引擎划分为以下 3 类：
- MOLAP：多维在线分析处理。它是基于多维数组的存储模型，也是 OLAP 最初的形态。其特点是，需要对数据进行预计算，以空间换效率，明细数据和聚合数据都被保存在 Cube（数据立方体）中，但生成 Cube 需要大量的时间和空间。
- ROLAP：关系在线分析处理。它完全基于关系模型存储数据，不需要预计算，按需即时查询，明细数据和汇总数据都被保存在关系型数据库的事实表中。
- HOLAP：混合在线分析处理。它属于 MOLAP 和 ROLAP 的混合模型，细节数据以 ROLAP 形式被存放，聚合数据以 MOLAP 形式被存放。这种方式相对灵活，且更加高效。
（2）目前业内已经有很多 MOLAP 和 ROLAP 类型的开源 OLAP 引擎，暂时还没有 HOLAP 类型的开源 OLAP 引擎。MOLAP 和 ROLAP 类型的对比如下：
| 比较项 | MOLAP | ROLAP |
| 存储模型 | 多维数组模型 | 关系模型 |
| 预计算 | 需要 | 不需要 |
| 查询读度 | 快 | 慢 |
| 扩展性 | 低 | 高 |
| 大数据领域典型代表工具 | Kyin、Druid | Hive、Impala、ClickHouse、Doris |
具体说明如下：
- 存储模型：MOLAP 类型支持数据的多维视图，使用的是多维数组模型。它把“维”映射到多维数组的下标或下标的范围中，而将事实数据存储在数组单元中，从而实现了多维视图到数组的映射，形成了立方体的结构。ROLAP 类型使用的是关系模型，以关系表存储多维数据，有比较强的可伸缩性。其中，维数据被存储在维表中，而事实数据和维 ID 则被存储在事实表中，维表和事实表通过主外键关联。
- 预计算：MOLAP 类型需要提前对数据做预计算；ROLAP 类型不需要。MOLAP 类型由于需要提前对数据做预计算，所以适合一些需求较固定的数据分析场景；ROLAP 类型则适合灵活多变的数据分析场景。
- 查询速度：MOLAP 类型是直接查询预计算之后的数据，所以查询速度比较快；ROLAP 类型查询的是原始明细数据，所以查询速度比较慢。
- 扩展性：MOLAP 类型的扩展性低于 ROLAP 类型。因为 MOLAP 类型需要进行预计算，空间占用大，所以不适合维度多的模型。ROLAP 类型由于是即时计算，所以比较适合于维度多的模型，但是计算速度慢一些。
2，从数据处理时效分类
（1）从数据处理时效这个维度进行划分，可以将 OLAP 引擎划分为离线 OLAP、实时 OLAP 两类。它们最大的区别在于数据计算的延迟度。
提示：对于目前企业中大部分的报表类统计分析需求，离线 OLAP 引擎是可以满足的。如果要进一步提升数据统计分析的时效性，则需要考虑使用实时 OLAP 引擎。
（2）离线 OLAP 在企业中应用得很广泛，常见的场景是对前一天的数据进行统计分析。离线 OLAP 的缺点是：无法对当天实时产生的数据进行统计。
- 离线 OLAP 的典型代表工具为：Hive、Impala 和 Kylin。这些离线 OLAP 工具无法实现实时数据统计分析，常见的是按照“天”级别进行数据统计分析，如果再细化也可以达到“小时”级别的数据延迟。
- 实时 OLAP 的典型代表工具为：Druid、Doris 和 ClickHouse。这些实时 OLAP 工具可以实现“秒”级别或者“分”级别的实时数据统计分析。
四、常见的 OLAP 引擎以及应用场景
1，典型的离线 OLAP 数据分析引擎
- Hive：主要提供通过 SQL 分析 HDFS 中海量数据的能力。HDFS 中存储的都是离线数据，所以 Hive 适合做海量数据的离线统计分析。Hive 的 SQL 语句在底层会被转化为 MapReduce 任务去执行，MapReduce 任务的特点是稳定和可靠。不过由于 MapReduce 是基于磁盘的，计算效率相对较低，所以如果你对计算速度要求不是特别高，但是对计算的稳定性要求比较高，那 Hive 是非常合适的。企业在构建离线数据仓库时，Hive 是首选的工具。在离线 OLAP 分析领域，Hive 是必不可少的。
- Impala：功能类似于 Hive，可以直接兼容 Hive 的元数据，即在 Hive 中创建的表可以在 Impala 中直接使用，两者可以无缝集成。
- Impala 的优点是：底层不需要经过 MapReduce，它自己实现了底层的计算引擎，主要是以内存的代价换取查询效率的提高。如果要在 Web 页面中提供一个海量数据统计分析功能，肯定希望在输入 SQL 语句后很快看到返回的结果，那对计算的效率要求就比较高了，使用 Hive 就不太合适了，比较适合使用 Impala 这种基于内存的计算引擎。
- Impala 也有缺点：因为它是基于内存的，所以稳定性相对比较差，如果查询的数据量比较大，则内存可能扛不住，最终导数内存溢出，无法计算出结果。
- Kylin：主要是为了解决 TB 级别数据的 SQL 分析需求。其核心是预计算，需要我们提前配置好计算规则，每天定时将计算结果存储在 HBase 中。在使用时，直接查询聚合后的结果数据，这样速度会很快(因为聚合后的数据量没有那么大了)。所以，Kylin 适合用于一些需求固定的报表类分析需求。如果需求灵活多变，则 Kylin 就无法发挥最优性能了。
说明：
- 计算引擎：Hive 的计算引擎默认是 MapReduce，也支持 Tez 或者 Spark。Impala 的计算引擎是通过 C++ 自研的 MPP 引擎。Kylin 的计算引擎可以使用 MapReduce 或者 Spark。
- 计算性能：Hive 底层会使用 MapReduce，所以计算性能相对一般，不过可以考虑使用 Tez 或者 Spark 引擎来提高性能。Impala 是基于内存计算的，计算性能比较好。Kylin 底层可以使用 MapReduce 或者 Spark 引擎，使用 Spark 引擎时计算性能也比较好。
- 稳定性：Impala 是全部基于内存的，所以稳定性较差。Hive 和 Kylin 底层都可以使用 MapReduce，所以稳定性相对较高。
- 数据规模：Hive 比较适合 TB 级别的数据分析，数据规模太大会导致计算时间过长。Impala 也比较适合 TB 级别的数据分析，如果数据规模太大则内存会出现瓶颈。Kylin 比较适合 TB 和 PB 级别的数据分析，因为它会提前对数据进行预计算，在海量数据下也可以提供较好的性能。
- SQL 支持程度：在 Hive 中定义了简单的类 SQL 查询语言（QL）。Impala 可以兼用 HQL。Kylin 支持标准 SQL。
2，典型的实时 OLAP 数据分析引擎
- Druid：主要针对时间序列数据提供低延时的数据写入及快速交互式 SQL 查询，适合被应用在海量实时数据的交互式分析场景中。其可以基于时间维度对实时产生的明细数据自动实时聚合，提高查询效率。它有一个比较明显的缺点——对 SQL 支持有限。在 Druid 0.18 版本之前它是不支持 JOIN 操作的，从 0.18 版本开始它有限支持 JOIN 操作，目前主要支持 INNER JOIN、LEFT JOIN 和 CROSS JOIN。
- ClickHouse：可以提供海量实时数据的快速写入，以及基于 SQL 的快速实时查询，适合应用在海量实时数据的交互式分析场景中。其支持非标准 SQL，有限支持 JOIN 操作，目前在实时数据仓库领域应用得比较广泛。
- Doris：可以通过 SQL 实现实时数据分析，适合应用在海量实时数据的交互式分析场景中。其对 SQL 支持比较好，支持 JOIN 操作。Doris 和 ClickHouse 是比较类似的，但是 Doris 目前的成熟度暂时还不如 ClickHouse。
说明：
- 查询性能：这 3 个组件的查询性能都比较高。
- 高并发：Druid 和 Doris 可以支持高并发，ClickHouse 的并发能力有限。
- 实时数据摄入：因为都属于实时 OLAP 引擎，所以它们都支持实时数据摄入。
- 实时数据更新：Druid 是不支持实时更新的，只能通过后台批处理任务实现覆盖更新。ClickHouse 支持实时更新，只是功能比较弱。Doris 可以正常支持实时更新。
- 支持 JOIN 操作：在基于 SQL 实现统计分析时，是否支持 JOIN 操作是一个比较重要的指标。Druid 和 ClickHouse 都支持 JOIN 操作，但是支持度有限。Doris 可以正常支持 JOIN 操作。
- SQL 支持程度：Druid 对 SQL 的支持度是有限的，ClickHouse 支持非标准 SQL，Doris 支持标准 SQL（相对较好)。
- 成熟程度：Druid 和 ClickHouse 的成熟程度比较高，Doris 目前正处于快速发展阶段。运维复杂度：ClickHouse 运维比较复杂，Druid 运维难度中等，Doris 运维最简单。
全部评论（0）