OLAP 系统-526互联

1 诞生背景

受益于 IT 技术的发展，ERP、CRM 这类 IT 系统在电力、金融等多个行业均得以实施。这些系统提供了协助企业完成日常流程办公的功能，例如流程审批、数据录入和填报等，其应用可以看作线下工作线上化的过程。
—— 通常将这类系统称为联机事务处理 (OLTP) 系统

企业在生产经营过程中，除了日常流程的办公内容，还需一种监管和决策层面的分析视角，如分析报表、分析决策等。而早期的IT系统建设过程中，数据散落在各个独立的系统内，相互割裂、互不相通。—— 数据孤岛问题

为解决数据孤岛问题，数据仓库的概念被提出，即通过引入一个专门用于分析类场景的数据库，将分散的数据统一汇聚到一处。借助数据仓库的概念，用户第一次拥有了站在企业全局鸟瞰一切数据的视角。一类统一面向数据仓库，专注于提供数据分析、决策类功能的系统与解决方案应运而生。最终于20世纪90年代，有人第一次提出了 BI (商业智能) 系统的概念。此后，人们通常用BI一词指代这类分析系统。

相比于联机事务处理 (OLTP) 系统，将这类BI系统称为联机分析 (OLAP) 系统。

OLAP：联机分析、又称多维分析，由关系型数据库之父埃德加·科德 (Edgar Frank Codd) 于1993年提出。指的是通过多种不同的维度审视数据，进行深层次分析。维度是观察数据的一种视角，好比是一张数据表的字段，而多维分析则是基于这些字段进行聚合查询。

❗️一句话概括：除了日常业务处理涉及的 OLTP 系统外，还需有一种系统能专门用于数据分析。早期的数据分析存在数据孤岛问题，因此提出了数据仓库的概念，基于数据仓库进行数据分析的系统被称为 BI 系统。BI 系统主要运用 OLAP 技术。

1.1 BI 系统的演变

传统 BI 系统体系的背后，仍是传统的关系型数据库技术 (OLTP 技术)。因此，为了解决海量数据下分析查询的性能问题，在数据仓库的基础上衍生出非常多概念：

对数据进行分层，通过层层递进形成数据集市，从而减少最终查询的数据体量
提出数据立方体的概念，通过对数据进行预先处理，以空间换时间，提升查询性能

但是 OLTP 技术由诞生的那一刻起就注定不是为数据分析而生的，因此设计的局限始终是无法突破的瓶颈。

Google于 2003 ~ 2006 年相继发表了三篇论文 “Google File System”，“Google MapReduce”，“Google Bigtable”，将大数据的处理技术带进了大众视野。2006 年开源项目 Hadoop 的出现，标志着大数据技术普及的开始，大数据技术真正开始走向普罗大众。

Hadoop 最初指代的是分布式文件系统 HDFS 和计算框架 MapReduce，但它一路高歌猛进，在此基础之上快速发展成一个庞大的生态（包括 Yarn、Hive、HBase、Spark等数十种）。在大量数据分析场景的解决方案中，传统关系型数据库很快就被 Hadoop 生态所取代。

以使用 Hadoop 生态为代表的这类非传统关系型数据技术所实现的 BI 系统，称为现代 BI 系统。

优点：现代 BI 系统在面对海量数据分析场景时，更游刃有余。Hadoop 生态带来诸多便利，例如分布式文件系统 HDFS 可以直接作为其他组件的底层存储（如 HBase、Hive 等），生态内部的组件之间不用重复造轮子，只需相互借力、组合就能形成新的方案。
缺陷：Hadoop 生态带来的另一面就是臃肿和复杂，Hadoop 生态下的每种组件都自成一体、相互独立，这种强强组合的技术组件有些时候显得过于笨重。与此同时，随着现代化终端系统对时效性的要求越来越高，Hadoop 在海量数据和高时效性的双重压力下（即在海量数据下实现多维分析的实时应答），也显得力不从心。

2 OLAP 技术

OLAP：联机分析、又称多维分析，由关系型数据库之父埃德加·科德 (Edgar Frank Codd) 于1993年提出。指的是通过多种不同的维度审视数据，进行深层次分析。

它主要用于支持企业决策管理分析，是许多商务智能（BI）应用程序背后的技术。 OLAP使最终用户可以对多个维度的数据进行即席分析，从而获取他们所需知识，以便更好地制定决策。OLAP技术已被定义为实现“快速访问共享的多维信息”的能力。

2.1 相关概念

维度 (Dimension)：描述与业务主题相关的一组属性，单个属性或属性集合可以构成一个维。?时间、地理位置、年龄和性别等都是维度。

维的层次 (Level of Dimension)：一个维往往可以具有多个层次，?时间维度分为年、季度、月和日等层次，地区维可以是国家、地区、省、市等层次。这里的层次表示数据细化程度，对应概念分层。后面介绍的上卷操作就是由低层概念映射到高层概念。概念分层除了可以根据概念的全序和偏序关系确定外，还可以通过对数据进行离散化和分组实现。

维的成员 (Member of Dimension)：若维是多层次的，则不同的层次的取值构成一个维成员。部分维层次同样可以构成维成员，例如“某年某季度”、“某季某月”等都可以是时间维的成员。

度量 (Measure)：表示事实在某一个维成员上的取值。例如开发部门汉族男性有39人，就表示在部门、民族、性别三个维度上，企业人数的事实度量。

2.2 基本操作

OLA P的操作是以查询——也即数据库的 SELECT 操作为主，但是查询可以很复杂，比如基于关系数据库的查询可以多表关联，可以使用 COUNT、SUM、AVG 等聚合函数。OLAP 正是基于多维模型定义了一些常见的面向分析的操作类型，使得这些操作显得更加直观。

OLAP的多维分析操作包括：

下钻 (Drill-down)：在维度的不同层次间变化，从高层次向低层次明细数据穿透。
?从“省”下钻到“市”，从“湖北省”穿透到“武汉”和“宜昌”。
上卷 (Roll-up)：和下钻相反，从低层次向高层次汇聚。
?从“市”汇聚成“省”，将“武汉”“宜昌”汇聚成“湖北”。
切片 (Slice)：观察立方体的一层，即将一个或多个维度设为单个固定值，然后观察剩余的维度。
?将商品维度固定为“足球”。
切块 (Dice)：与切片类似，只是将单个固定值变成多个值。
?将商品维度固定成“足球”“篮球”和“乒乓球”。
旋转 (Pivot)：旋转立方体的一面，即互换维的位置。
?互换市维度和商品维度。

2.3 OLAP 架构分类

按数据存储方式，可将 OLAP 架构分为三类：ROLAP、MOLAP、HOLAP。

2.3.1 ROLAP

ROLAP (Relational OLAP, 关系型 OLAP) 直接使用关系模型构建，数据模型常使用星型模型或者雪花模型。

这是最先能够想到，也是最为直接的实现方法。因为 OLAP 概念在最初提出的时候，就是建立在关系型数据库之上的。不使用预先计算的多维数据集，多维分析的操作可直接转换成 SQL 查询。ROLAP 工具具有询问任何问题的能力，因为该方法 (SQL) 不仅限于多维数据集的内容。

?通过上卷操作查看省份的销售额，就可以转换成类似下面的SQL语句:

SELECT SUM(价格) FROM 销售数据表 GROUP BY 省

尽管 ROLAP 使用关系数据库作为底层存储，但这些数据库一般要针对 ROLAP 进行相应优化，如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL 的 OLAP 扩展 (cube, rollup) 等。专为 OLTP 设计的数据库不能像 ROLAP 数据库一样正常工作。

2.3.2 MOLAP

MOLAP (Multidimensional OLAP, 多维型 OLAP) 的出现是为了缓解 ROLAP 性能问题。MOLAP 将数据存储在优化的多维数组中，而不是关系数据库中。其核心思想是借助预先聚合结果，使用空间换取时间的形式最终提升查询性能。其具体的实现方式是依托“数据立方体”模型的概念，对数据进行预计算和存储，构建预计算的“数据立方体”数据集。维的属性值被映射成多维数组的下标值或下标的范围，而度量数据作为多维数组的值存储在数组的单元中。

首先，对需要分析的数据进行建模，框定需要分析的维度字段；然后，通过预处理的形式，对各种维度进行组合并事先聚合；最后，将聚合结果以某种索引或者缓存的形式保存起来（通常只保留聚合后的结果，不存储明细数据）这样在随后的查询过程中，就可以直接利用结果返回数据。

优点：数据立方体包含给定范围的问题的所有可能答案。因此，它们对查询的响应非常快。

缺点：维度数据基数较高时 (高基数意味着重复相同的数据少)，立方体预聚合的数据量会膨胀爆炸。?若数据立方体包含了5个维度 (字段)，则维度组合的方式有\(2^5\) (\(2^n,n=维度个数\)) 个。虽然也实现了一些能够降低膨胀率的优化手段，但并不能完全避免。另外，由于使用了预处理的形式，数据立方体的更新会有一定的滞后性，不能实时进行数据分析。而且，立方体只保留了聚合后的结果数据，导致无法查询明细数据。

2.3.3 HOLAP

由于 MOLAP 和 ROLAP 有着各自的优点和缺点，且它们的结构迥然不同，这给分析人员设计 OLAP 结构提出了难题。为此一个新的 OLAP 结构——HOLAP (Hybrid OLAP, 混合架构的 OLAP) 被提出。

这种工具通过允许同时使用多维数据库 (MDDB) 和关系数据库 (RDBMS) 作为数据存储来弥合这两种产品的技术差距。它允许模型设计者决定将哪些数据存储在 MDDB 中，哪些存储在 RDBMS 中。?将大量详单数据存储在关系表中，而预先计算的聚合数据存储在多维数据集中。

目前整个行业对于 HOLAP 的还没有达成明确的共识。

对比项	MOLAP	ROLAP
存储方式	专为 OLAP 设计和优化的存储，支持多维索引和缓存	沿用现有的关系数据库的技术
查询性能	具有较高的查询性能，响应速度快	响应速度一般比 MOLAP 慢
数据装载	数据装载速度慢	加载速度通常比 MOLAP 加载要快得多
维数限制	需要进行预计算，可能导致数据爆炸，维数有限制	存储空间耗费小，维数没有限制
访问接口	缺乏数据模型和数据访问的标准接口	可通过 SQL 实现详细数据与汇总数据的查询，且可以由任何 SQL 报告工具访问
冗余存储	MOLAP 方法引入了数据冗余	没有冗余数据，可与数据仓库共享同一份数据
计算支撑	支持高性能的决策支持计算	由于依赖数据库来执行计算，因此专用功能上有更多限制
操作维护	维护困难	管理简便

2.4 OLAP 实现技术的演进

在介绍了OLAP几种主要的架构之后，再来看看它们背后技术的演进过程。

2.4.1 传统关系型数据库阶段

在这个阶段中，OLAP主要基于以 Oracle、 MySQL 为代表的一众关系型数据库实现。在 ROLAP 架构下，直接使用这些关系型数据库作为存储与计算的载体；在 MOLAP 架构下，则借助物化视图的形式实现数据立方体。

在这个时期，不论是 ROLAP 还是 MOLAP，在数据体量大、维度数目多的情况下都存在严重的性能问题，甚至存在根本查询不出结果的情况。

2.4.2 大数据技术阶段

在这个阶段中，由于大数据处理技术的普及，人们开始使用大数据技术重构 ROLAP 和 MOLAP。

以 ROLAP 架构为例，传统关系型数据库就被 Hive 和 SparkSQL 这类新兴技术所取代。虽然，以 Spark 为代表的分布式计算系统，相比 Oracle 这类传统数据库而言，在面向海量数据的处理性能方面已经优秀很多，但是直接把它们作为面向终端用户的在线查询系统还是太慢了。我们的用户普遍缺乏耐心，如果一个查询响应需要几十秒甚至数分钟才能返回，那么这套方案就完全行不通。

再看 MOLAP 架构， MOLAP 背后也转为依托 MapReduce 或 Spark 这类新兴技术，将其作为立方体的计算引擎，加速立方体的构建过程。其预聚合结果的存储载体也转向 HBase 这类高性能分布式数据库。大数据技术阶段，主流 MOLAP 架构已经能够在亿万级数据的体量下，实现毫秒级的查询响应时间。尽管如此，MOLAP架构依然存在维度爆炸、数据同步实时性不高的问题。

如果单纯从模型角度考虑，很明显 ROLAP 架构优于 MOLAP。因为关系模型拥有最好的“群众基础”，也更简单且容易理解。它直接面向明细数据查询，由于不需要预处理，也就自然没有预处理带来的负面影响 (维度组合爆炸、数据实时性、更新问题)。

除了上述两类方案之外，也有一种另辟蹊径的选择，即摒弃 ROLAP 和 MOALP 转而使用搜索引擎来实现 OLAP 查询，ElasticSearch 是这类方案的代表。 ElasticSearch支持实时更新，在百万级别数据的场景下可以做到实时聚合查询，但是随着数据体量的继续增大，它的查询性能也将捉襟见肘。

各方案的痛点：

新一代 ROLAP 方案：可以一站式处理海量数据；但无法真正做到实时应答和高并发。更适合作为一个后端的查询系统。

新一代 MOLAP 方案：解决了大部分查询性能的瓶颈问题，能够做到实时应答；但仍有数据膨胀和需预处理、数据更新实时性不高的问题。

摒弃 ROLAP 和 MOALP，使用搜索引擎来实现 OLAP 查询：支持实时更新，在百万级别数据的场景下可以做到实时聚合查询；但数据体量再增大，查询性能会下降。

3 OLAP 开源组件

开源大数据 OLAP 组件可分为两类：MOLAP、ROLAP。

ROLAP 又可细分为两类：MPP 数据库、SQL 引擎。

对于 SQL 引擎又可以再细分为：基于 MPP 架构的 SQL 引擎、基于通用计算框架的 SQL 引擎。

MOLAP 一般对数据存储有优化，且会进行部分预计算。因此查询性能最高，但通常对查询灵活性有限制。
MPP 数据库是个完整的数据库，通常需要将数据导入其中才能完成 OLAP 功能。MPP 数据库可以在数据入库时优化数据的分布，虽然一定程度上会降低入库效率，但是会极大地提高后期的查询性能。MPP 数据库可以提供灵活的即席查询能力，但一般对查询数据量有一定限制，无法支撑特别大的数据量的查询。
SQL 引擎只提供 SQL 执行的能力，本身一般不负责数据存储，通常可以对接多种数据储存，如 HDFS、HBase、MySQL 等。有的还支持联邦查询能力，可以对多个异构数据源进行联合分析。SQL引擎中，基于MPP 架构的 SQL 引擎，一般对在线查询场景有特殊优化，所以端到端查询性能一般要高于基于通用计算框架的SQL引擎，但是在容错性和数据量方面又会逊于基于通用计算框架的SQL引擎。

总之，可以说没有一个 OLAP 系统能同时在处理规模，灵活性和性能这三个方面做到完美，用户需要基于自己的需求进行取舍和选型。

OceanBase 和 TiDB 都为 HTAP 数据库。

4 概念对比

OLTP ? OLAP

OLTP 和 OLAP 是针对不同的数据处理需求的两种技术。

OLTP (Online Transaction Processing)：一般用于业务系统，支持日常的业务事务处理。
- 特点：设计为处理大量短期的交易，支持实时的数据录入、更新和删除。追求快速的事务处理能力、并发操作和事务的 ACID 属性。
- 数据库设计：主要基于传统的关系型数据库。其上的应用，一般以小的事务以及小的查询为主。
- OLTP 数据库用途：适用于需要频繁读写、高并发的业务应用，比如银行交易、在线购物等。
- OLTP 数据库评估标准：一般看其每秒执行 Transaction 以及 SQL 的数量。单个数据库每秒处理的Transaction (增、删、改) 往往达到几百上千个，Select 查询语句的执行量每秒几千甚至几万个。
OLAP (Online Analytical Processing)：一般用于分析系统，侧重于对大量数据进行查询、分析和汇总，修改和删除的操作较少。
- 特点：设计为支持多维数据分析，支持复杂的分析操作，如切片、切块、钻取等，目标是为用户提供高性能的数据查询和汇总，以便以不同的角度和维度对数据进行分析。
- 数据库设计：通常采用多维数据结构，以便于高效的数据分析和洞察获取。
- OLAP 数据库用途：适用于数据仓库、BI系统等，支持决策者对数据进行深入的交互式分析。
- OLAP 数据库评估标准：SQL 语句的执行量不是考核指标，因为一条语句的执行时间可能会很长，读取的数据也非常多。所以，评估时往往是看系统的吞吐量、复杂查询响应时间、数据装载性能等。

通常，OLTP 数据库通常被设计用于支持 OLTP 处理，OLAP 数据库更针对分析和决策支持。也有数据库可支持这两种处理类型，如一个数据库可以同时包含 OLTP 和 OLAP 系统，或者使用不同的部分来支持不同的业务需求。

OLAP ? 数据仓库/数据集市

数据仓库：是一个用于存储大量结构化数据的集合，通常来自多个不同的数据源。它用于支持企业的决策制定和分析需求。

特点：是存储数据的地方，经过整合、清洗和转换以支持决策制定。通常包含历史数据，用于分析和报告。
目的：提供一个统一的数据视图，支持企业对数据的分析、报告和决策。

数仓建模的方式：ER 模型 (实体-关系模型)、Data Vault 模型、Anchor 模型、维度模型。

前面三种模型主要致力：将各个业务系统中的数据整合到统一的数据仓库中，并进行一致性处理，提供满足第三范式或更高范式的数据模型和原子数据。这种数据仓库被称为 CIF (Corporate Information Factory，企业信息工厂) 架构下的企业数据仓库。这种数据仓库架构为数据仓库之父 Inmon 所推崇。

由于使用了规范化模型，这种架构使原子数据的查询变得很困难，且不能很好地直接用于支撑分析决策。为了更好的支持分析，这种架构通常需要在数据仓库的基础上，按主题建立一些数据子集，也即数据集市。这些数据集市通常采用维度模型，OLAP 工具就可基于数据集市工作。数据集市通常就是为 OLAP 系统而构建。

第四种模型 (维度模型) 由另一位数据仓库领域的大师 Kimball 提出，是目前数据仓库领域最流行的建模方式。

维度模型可以很好地支撑分析决策需求，同时还有较好的大规模复杂查询的响应性能。Kimball 所推崇的数据仓库架构如下，基于这种架构建立的数据仓库本身成为了一个 OLAP 系统，可以直接提供 OLAP 能力。

OLAP ? BI

BI 系统：是一组工具、应用程序和技术，用于将数据转化为有用的信息、洞察和报告，以支持业务决策。
- 特点：BI系统利用数据仓库中的数据，并通过可视化、报表、仪表板等方式呈现数据，以便用户能够理解和利用数据做出决策。
- 目的：帮助企业用户从数据中获取价值，并支持实时或批处理的分析需求。
OLAP：是一种用于多维数据分析的技术，允许用户以多个维度（如时间、地理位置、产品等）对数据进行交互式分析。

OLAP 和 BI 常常在一起出现，OLAP 是 BI 工具的一种底层技术。BI 工具通常可以对接 OLAP 系统，但不限于此，也可以直接与其他数据库、存储系统对接。