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（Hybrid Transactional/Analytical Processing）系统，例如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层分析后的业务化的结果。

国产数仓

近期，就在2月15日，国内IT界有搞出个大瓜，Teradata以对中国当前及未来商业环境的不确定性，慎重考虑后决定退出中国运营，后续将进入中国公司关闭程序。Teradata是一家有着40多年历史的数据仓库企业，被业界专业人事称为“数仓人才的黄埔军校”， 在大数据领域一直保持全球领先的地位。它在1997年正式进入中国，并率先在金融、电信领域推出自己的数仓产品，由于当时国内软硬件基础不太好，信息化行业又面临着迅速数据膨胀等因素，使Tearadata很快在中国铺开市场，直到近期的退出，在国内还保留着众多的使用单位及市场。下面谈谈对这一事件的看法及国产数据仓库产品的机会。

1. Teradata 退出，个中缘由

卖的好好的，为啥退？笔者不是啥国际局势专家，感觉无外乎几个原因：一是国家间的国际关系影响；二是某些国家的做法令人不爽，如监听门事件等；三是国内众多替代产品慢慢趋向成熟稳定并蚕食Teradata的市场。个人感觉最大的原因还是第三点国产数据库的崛起萎缩了海外厂商的市场，国内数仓产品很多，与Teradata等同的有南大通用的GBase 8a、华为的GaussDB 200、阿里的ADB等等。此外，Teradata是以一体机的形式对外销售，最大的特点就是昂贵，但不缺钱的企业多了去了，仍在中国赚得盆满钵满。但随着持续发展，国内的客户发现Teradata也存在很多的问题，就算没有国际局势、没有监听门事件也萌发换掉它的想法。试探着找出可以替代Teradata架构、使用相似的产品，下文也将从几个方面对比国内数仓产品与Teradata的异同。

2. Teradata 退出，如何填补

1).Teradata 技术架构

Teradata是Shared Nothing的MPP架构，主要包括解析引擎、BYNET和访问控制处理器（AMP），Teradata以节点为系统的基本单元，一体机中每台服务器都称为节点，高级架构图如下：

2).主流数仓架构

当前主流国产数仓产品主要有三种架构。

❖ 有Master

第一种有Master的架构，主要产品是PG系的产品，比如GreenPlum等通过PostgreSQL改过来的产品，其典型架构图如下

❖ 无Master

第二种是无Master的计算、存储、管理一体化的架构，其架构图如下

❖ 多Master

第三种架构是联邦架构，也可叫多Master。跟第一种非常相似，唯一差别就是原来的Master-Slave模式变成了集群模式，架构图如下

该架构使集群对外服务能力更强，因其连接应用的管理节点是集群模式，可实现多管理节点的高可用、不像Master-Slave模式，在掉了Master后，到Slave切换的RTO过大及数据丢失的风险。目前这个架构国内唯一家数据库支持，就是GBase 8a MPP V9，国外有HDP 2.0。

3).数仓全球概况

Gartner作为全球最具权威的IT市场研究与顾问咨询公司，定期会推出IT行业的各种报告以及著名的Gartner魔力象限。Gartner魔力象限通常从两个方面来评价供应商：前瞻性和执行能力。涵盖的公司包括：领导者、挑战者、有远见者、细分领域主导者。前者考量该厂商提供产品底层技术基础的能力、市场领导能力、创新能力、外部投资等， 后者考量产品的易用程度和价格、服务的完善程度和技 术支持能力、管理团队的经验和能力等。象限图的横轴表示前瞻性，纵轴表示执行能力。国产数仓也在Gartner中进行过评估，过去几年中曾经出现两个国内厂家进入了该魔力象限，比如2017年，共有22家厂商被选入魔力象限。其中，亚太地区入围的三家全部来自中国，包括GBase、阿里云和华为，这也是该象限首次有三家中国厂商进入。除了Micro Focus和SAP两家欧洲公司外，其余17家均为美国公司。

华为的GaussDB产品与南大通用的GBase产品在全球排上了名，与Oracle、Teradata知名数据库同时出现在一幅图中。虽然不在同一象限，但也代表了这些厂商在全球的认可度。从这一角度来看，Teradata退出后原有市场填补及新市场空间可从上述受到权威认可的厂商中选择，如上面的南大的GBase 8a和华为的GaussDB为主。

4).国内典型产品

❖ GBase 8a

GBase 8a是南大通用公司自主研发的一款分析型数据库，而南大通用本身也是一家专注做数据库的公司，其产品覆盖分析型、事务型、另一维度，分集中式和分布式，有8a分析型数据，8s集中式事务库，8c分布式多模数据库。而对应Teradata数仓产品的则是南大通用8a产品，产品名字GBase 8a MPP Cluster，最新版本是V953，据说性能在OLAP场景下非常强劲，且该产品在2010年就研发并投入市场，在国内的OLAP领域可以说资格最老、最稳定、市场占有最大的一家公司产品。

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章

验证码：

请关注本站微信公众号，回复“小麦苗博客”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。