OLTP、OLAP和HTAP的区别

OLTP、OLAP、HTAP简介

现代工程界普遍认为，数据库系统可以在广义上分为联机事务处理（Online Transaction Process，OLTP）和联机分析处理（Online Analyze Process，OLAP）两种面向不同领域的数据库，OLAP数据库也被称为数据仓库。从产品上看，有专门面向OLTP的数据库，例如MySQL、PostgreSQL、Oracle等，也有专门面向OLAP的数据库，例如Hive、Greenplum、HBase、ClickHouse等。还有一种尝试统一两大类型的HATP（Hybird Analyze Transaction Process）系统，例如TiDB、OceanBase等。

OLTP

OLTP是传统的关系型数据库的主要应用，即记录实时的增、删、改，主要是执行基本的、日常的事务处理，例如，在银行存取一笔款，就是一个事务交易。OLTP系统强调数据库处理效率，强调内存各种指标的命中率，强调绑定变量，强调并发操作。一般情况下，OLTP系统数据量少，DML操作比较频繁，并行事务处理多，但是一般都比较短。OLTP表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主。评估其系统的时候，一般看其每秒执行的事务数以及SQL执行的数量。在OLTP系统中，单个数据库每秒处理的事务数往往超过几百个，或者是几千个，SELECT语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，例如，美国eBay的业务数据库，就是很典型的OLTP数据库。在Oracle中创建OLTP系统时，使用一般用途或事务处理（General Purpose or Transaction Processing）模板。

具体而言，OLTP的特点一般有以下几点：

（1）实时性要求高。

（2）数据量不是很大。

（3）交易一般是确定的，所以，OLTP是对确定性的数据进行存取，例如存取款都有一个特定的金额。

（4）并发性要求高，并且有严格的事务完整性、安全性。例如，有可能你和你的家人同时在不同的银行取同一个帐号的存款。

OLAP

OLAP的概念最早是由关系型数据库之父E.F.Codd于1993年提出的，他认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。OLAP是DSS（Decision Support System，决策支持系统）的一部分，是数据仓库的核心部分。DSS是辅助决策者通过数据、模型和知识，以人机交互方式进行半结构化或非结构化决策的计算机应用系统。DSS是管理信息系统（Management Information System，MIS）向更高一级发展而产生的先进信息管理系统，它为决策者提供分析问题、建立模型、模拟决策过程和方案的环境，调用各种信息资源和分析工具，帮助决策者提高决策水平和质量。所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。数据量大，DML少。典型的应用就是复杂的动态报表系统。在Oracle中创建OLAP系统时，使用数据仓库（Data Warehouse）模板。

具体而言，OLAP的特点一般有以下几点：

（1）实时性要求不是很高，很多应用都是每天晚上更新一次数据。

（2）数据量大，因为OLAP支持的是动态查询，所以，用户需要统计很多数据以后才能得到想要知道的信息，所以，OLAP处理的数据量很大。

（3）因为重点在于决策支持，所以，OLAP查询一般是动态的，也就是说允许用户随时提出查询的要求。于是在OLAP中通过一个重要概念“维”来搭建一个动态查询的平台（或技术），供用户自己去决定需要知道什么信息。

HTAP

同时维护 OLTP 和 OLAP 两套系统，不仅会造成数据冗余存储，而且成倍增加了系统的运维成本。同时，由于 OLAP 系统的数据依赖于 ETL 通过数据复制功能从 OLTP 系统同步数据，因此时效性受到了很大的影响。于是业界提出了在线事务处理 / 在线分析处理（Hybrid Transactional/Analytical Processing，HTAP）的概念。从单个数据库的能力上看，HTAP 确实是未来的趋势，即 OLTP 和 OLAP 需要在一定程度上进行融合。早期的 Oracle、DB2 数据库都是同时具有 OLTP 和 OLAP 功能的。

从Hadoop时代开始，为了提高OLAP的性能，衍生出了MapReduce和Hive。为了提高OLTP的性能，衍生出了HBase，从此OLTP和OLAP分道扬镳。从实际应用的角度看，Hive广泛用于数据仓库的批处理平台，但是完全不支持OLTP功能，在某些场景下也是很不方便的，而HBase则无法满足批量查询要求。从OLTP和OLAP的能力维度评价各主流数据库如图1-9所示。

近年来，虽然实时数仓非常火热，但是实现起来只是差强人意。如果有一款用于批处理的OLAP数据平台，同时又具备较好的OLTP性能，可以满足当日数据通过Kafka源源不断地写入，并且高效地被前端应用查询到，那么我们是不是就能很好地实现流批一体、流批结合了呢。从实际情况来看，还没有这样一款成熟并且广泛应用的数据库出现。这种应用场景要求数据平台以OLAP为主，兼顾OLTP的需求，目前做得比较好的有Doris、Greenplum、Impala+Kudu组合。大型交易数据也会有一些批量查询需求，从目前的情况看，这类需求并没有被很好地满足，也是一个需要技术突破的地方。目前大多数号称已经是HTAP数据库的厂商都是在满足OLTP性能的基础上，增强OLAP查询能力。例如腾讯的TBase、PingCAP的TiDB、SAP的HANA、阿里的OceanBase等。

OceanBase是由蚂蚁金服、阿里巴巴完全自主研发的金融级分布式关系型数据库，始创于2010年。OceanBase具有数据强一致、高可用、高性能、在线扩展、高度兼容SQL标准和主流关系数据库、低成本等特点。OceanBase至今已成功应用于支付宝全部核心业务：交易、支付、会员、账务等系统以及阿里巴巴淘宝收藏夹、P4P广告报表等。除在蚂蚁金服和阿里巴巴业务系统中广泛应用外，从2017年开始，OceanBase开始服务外部客户。值得称赞的是，2020年5月，OceanBase以7.07亿的TPM-C评测成绩再次夺冠，将自己之前创造的纪录提升了近11倍。2021年5月，OceanBase再次以1526万QphH的性能总分夺冠数据分析型基准测试（TPC-H）30000GB级。这意味着，OceanBase成为唯一在OLTP和OLAP两个领域性能测试中都获得第一的中国自研数据库。

OLAP和OLTP的区别对比表

表 OLAP和OLTP的区别

上表列出了OLAP和OLTP的一些对比。

近年来，随着技术的发展，OLAP和OLTP之间的界限也在不断模糊，几年前OLAP数据库都不支持事务，近几年已经出现了一些支持简单事务的OLAP引擎，ClickHouse也将简单的事务支持列入Roadmap。另外，随着分布式技术的发展，部分OLTP数据库也能处理更大的数据，甚至厂商推出的HATP数据库，从而直接打破了两者的界限。

OLAP和OLTP在功能上越来越趋于一致，使得在有些场景下OLAP和OLTP可以相互取代，这是否意味着原有分类方法失效了呢？是否未来就不再需要数仓或者不再需要事务数据库？ClickHouse的极致性能优化能否推动OLAP和OLTP融合？回答这些问题需要理清OLAP和OLTP分类的本质。

OLTP和OLAP的底层数据模型

OLAP和OLTP的本质区别在于底层数据模型的不同。OLAP更适合使用低范式的数据表，而OLTP则更适合使用高范式的数据表。无论它们之间的功能是否越来越相似，只要其底层数据模型不同，那么它们之间的区别就永远存在，结构决定功能。

ClickHouse是一个面向OLAP的数仓，很多的优化都是面向低范式数据模型的，并没有对高范式数据模型进行很好的优化。甚至在有些场景下，ClickHouse的join能力会成为整个系统的瓶颈。

ClickHouse更适合处理低范式数据集，特别是第零范式的数据集。ClickHouse对第零范式的数据集进行了比较多的优化。

数据三范式

OLTP数据库在进行数据库设计时使用实体-关系模型（Entity-Relationship Model，E-R Model，简称ER模型）。在ER模型的建模过程中有一个非常重要的规范化过程。规范化的目的在于通过一系列手段使得数据库设计符合数据规范化（Normal Form，NF）的原则。简单地说，规范化是将数据表从低范式变成高范式的过程。一般情况下，在OLTP中通常将数据规范化为第三范式（3NF）。

在规范化的过程中经常使用范式的概念，在数据库理论中共有6种范式，下面挑选3种常用的范式做简单介绍以方便读者理解后续内容。

1、第一范式

第一范式指表中的每个属性都不可分割，满足上述条件即满足第一范式。表1-2展示了一个不满足第一范式的例子，由于本例中的标签字还可以细分为性别、年龄、是否为VIP用户等多个属性，因此不满足第一范式。

▼表1-2 不满足第一范式的用户标签表

2、第二范式

第二范式是在第一范式的基础上，当表中的所有属性都被主键的所有部分唯一确定，即为满足第二范式。表1-3展示了一个不满足第二范式的例子，本例中用户ID和标签ID组成了主键，标签名称这两个属性只依赖于标签ID，用户所在地只依赖于用户ID，这两个属性都不依赖由用户ID和标签ID组成的主键。从而不满足第二范式。删除标签名称和用户所在地即可使得表格满足第二范式。

▼表1-3 不满足第二范式的用户标签表

3、第三范式

第三范式是在第二范式的基础上，当表中的属性不依赖除主键外的其他属性，即为满足第三范式。表1-3中，来源名称是不满足第三范式的，因为来源名称依赖于来源ID，所以需要将来源ID删除。表1-3经过规范化之后的合格数据表应该是如表1-4、表1-5所示。

▼表1-4 合格的用户标签表

▼表1-5 合格的用户信息表

4、第零范式

不满足第一范式的所有情况都被称为第零范式。表1-2所示的是其中一种情况。数据库理论中并没有对第零范式的严格定义，由于作者在本书写作过程中会经常使用第零范式的模型设计，因此在本书中，如果没有特别说明，第零范式特指存在Map或数组结构的一类表。这类“第零范式”的表设计具备一定的实际意义，在作者的工作中，经常会用到这类设计。灵活应用这类第零范式，可能会收获意想不到效果。

规范化的意义

一般要求在设计业务数据表时，需要至少设计到第三范式，避免出现数据冗余。从表1-3中不难发现出现了标签名称和来源名称的冗余。冗余不仅增加了数据大小，更重要的是，冗余的存在会影响数据库事务，降低数据库事务性能。

表1-6展示了一个不合格的表设计，请读者关注最后两列，很明显这是不满足第三范式的一种设计。表中的最后一列“需要权限”用于设置数据权限，表格中的数据意味着第一行和第三行需要admin权限才能查看。正常情况下没有问题，如果随着业务的变化，需要将授权级别为“2 – 非公开”的权限改为admin和manager都有权限查看。对于这种需求，如果使用表1-5的设计，就需要进行全表扫描，将数据表中所有的授权级别为2的数据全部进行修改，这会严重降低数据库性能。

▼表1-6 影响事务性能的表结构

数据库规范化的意义在于通过规范化降低冗余，提高数据库事务性能。正是基于这个考虑，在数据库表设计中，会要求将对数据表进行规范化。

规范化的局限

任何架构在有优势的情况下，一定也会有其局限。对于规范化的数据表，这句话也同样适用。规范化的数据表能够降低冗余，进而提高事务性能。同时，规范化的数据表无法支撑分析。

以表1-3～表1-5为例，表1-4和表1-5为表1-3进行规范化后的合格用户标签表。如果需要按照用户所在城市来统计年龄分布，是无法单独使用表1-4完成的。必须对表1-4和表1-5进行连接（join）操作，得到的新表才能用于分析。而在绝大多数数据库系统中，join操作的过程相对于查询来说比较慢。

数仓建模的本质

通过前文的分析，我们可以得出一个推论：高范式的表适合事务处理，而低范式的表适合分析处理。从中我们可以得出数仓建模的本质：逆规范化。数仓建模本质上就是一个逆规范化的过程，将来自原始业务数据库的规范化数据还原为低范式的过程，从而用于快速分析。

在实际建模过程中，数仓经常提到的宽表本质上就是一个低范式的表。宽表将所有相关联的列全部都整合到一张表中，用于未来的分析，这样做的好处就是所有相关信息都在这张宽表中，理论上在进行分析时就不需要进行任何join操作了，因为可以直接进行相关的分析，所以提高了分析速度。这样做的缺点就是数据冗余，从而难以支持事务能力。

大部分数据仓库都是基于低范式数据集进行优化的，读者在使用OLAP引擎时一定要时刻记住这一点，避免将OLTP数据库中的原始高范式数据直接用于OLAP分析，否则分析效果可能会差强人意。而应该通过逆规范化的过程将高范式数据集还原为低范式数据集，再由OLAP进行分析。

维度建模

在使用OLAP进行数据分析时，需要对原始数据进行维度建模，之后再进行分析。维度建模理论中，基于事实表和维度表构建数据仓库。在实际操作中，一般会使用ODS（Operational Data Store，运营数据存储）层、DW（Data Warehouse，数据仓库）层、ADS（Application Data Service，应用数据服务）层三级结构。

1、ODS层

ODS层一般作为业务数据库的镜像。在项目中，数仓工程师通常通过数据抽取工具（例如Sqoop、DataX等）将业务库的数据复制到数仓的ODS层，供后续建模使用。ODS层的数据结构和业务数据库保持一致，建立ODS的原因在于，通过复制一份数据到ODS层，可以避免建模过程直接访问业务数据库，从而对业务数据库带来影响，避免影响线上业务。

2、 DW层

将数据导入ODS层后，即可对ODS层的数据进行清洗、建模，最终生成DW层的数据。其中生成DW层的本质即为本章提到的逆规范化的过程。由于ODS中的数据本质上是业务数据库的副本，因此ODS中的数据是高范式的数据，不适合进行OLAP分析。这也导致了在进行OLAP分析前需要将高范式的ODS数据通过一些手段逆规范化到低范式的数据。低范式的数据作为DW层的数据，对外提供分析服务。

在逆规范化时，可能会产生一些中间结果，这些中间结果也可以存储于DW层中，因此在DW中有时会再次进行细分，划分成DWD（Data Warehouse Details，数据仓库明细）层、DWM（Data Warehouse Middle，数据仓库中间）层、DWS（Data Warehouse Service，数据仓库服务）层三个更细分的层次。

ODS层的数据通过清洗后存储到DWD层，DWD层本质上是一个去除了脏数据的高质量的低范式的数据层。DWD层的数据通过聚合，形成宽表并保存到DWM层中。DWM层已经是低范式的数据层了，可以用于OLAP分析。在某些场景中，可以对DWM层的数据进行业务重新聚合，以支持更复杂的业务，此时需要生成的数据保存到DWS层中。

在这3个细分的DW层中，并不是所有场景下都需要齐备的。DW层的本质就是对高范式的数据进行逆规范化，生成低范式数据的过程。读者只需要把握住这个核心即可，在实际的维度建模过程中，根据业务的实际需求进行建模，不需要在所有的场景下都机械地遵循DWD层、DWM层、DWS层的三层架构。

3、ADS层

ADS层保存供业务使用的数据的结果，DW层的数据可以用于OLAP分析，但分析过程通常比较慢，无法支撑实时的业务需求，因此需要引入ADS层作为缓存，向上支撑业务。同样的，ADS层也不是必须的，需要根据业务实际来选择，ClickHouse的高性能计算引擎可以在一定程度上取代ADS层。

ADS层数据本质上面向业务的，高度业务化的数据。可以认为是基于DW层分析的结果，很多情况下是指标、标签等计算结果。本书在后续内容中使用ADS名词时，如无特殊说明，均指基于DW层分析后的业务化的结果。

参考

https://mp.weixin.qq.com/s/BogT4n81UVySSfjHEGMitg