2个月前，小编受邀参加 2024 Oceanbase 开发者大会，发布了年度V4.3 版本，该版本一大新特性是HTAP，当时写了一篇现场参会的第一感受，见链接。数据库的 HTAP 概念最先是国外提出的，现在却是"墙外开花墙内香"，国外数据库产品更多的是关注多 Cloud 、多 Region发展，比如 YugabyteDB、Snowflake；而国内数据库对 HTAP 情有独钟。本文将深入剖析 HTAP 架构类型、关键技术以及国内主流HTAP产品。

文章分成三大部分：第一部分，简单介绍HTAP数据库、传统的 OLTP&OLAP 区别联系；第二部分，本文将以清华大学的李国良和张超两位老师，在2022年国际数据库顶级会议 ACM SIGMOD 发表的论文和报告为基础，详细介绍 HTAP 的四种架构和五大关键技术；第三部分，简单介绍国内主流 HTAP 产品以及挑战。

全文大约7000字，阅读完大约需要20分钟，需要一定数据库基础，适合于资深开发者、架构师、数据库行业从业者等阅读。阅读完你将会了解 HTAP 数据库架构类型、关键技术以及国内主流HTAP产品的发展状况。

最后，由于个人能力有限，如有不当之处，请各位读者大佬不吝赐教。

01 HTAP 定义

传统数据库分为两大类，一类是在线事务处理，又称OLTP（On-Line Transaction Processing ）；另一类是在线分析处理，又称OLAP（On-Line Analytical Processing）。前者侧重于交易的处理过程，特点是数据量小、并发高、低延迟，比如金融交易、互联网等业务场景；后者侧重于数据分析，特点是数据量大、并发低、延迟较高（两者特点刚好相反），比如商业智能、数据挖掘、企业决策支持等场景。

传统的解决方案中，这两类业务场景通常使用独立的数据库产品来满足，以MySQL、Oracle、SQLServer 等产品满足OLTP系统需求；而Teradata、Greeplumn、Hbase 等产品满足OLAP系统需求，它们之间通过ETL来实现数据的流转。从90年代初Codd博士提出OLAP概念来，两者一直分工明确互不干涉。

传统OLTP、OLAP系统是不同数据库，通过ETL实现数据流转的解决方案。这方案下，数据一致性、新鲜度问题，TP、AP数据库以及ETL组件运维等问题都存在挑战和风险。而另一方面，一个业务同时拥有TP、AP需求是客观存在的。因此，数据库工程师们孜孜不倦的追求着，能不能提供一款同时支持OLTP、OLAP的数据库？？

于是2014年，Gatner 提出了 HTAP ¹（Hybrid Transaction and Analytical Process）混合事务和分析处理，既能支持在线事务处理 OLTP，又能支持在线分析处理 OLAP。

Hybrid transaction/analytical processing (HTAP) is an emerging application architecture,that "breaks the wall" between transaction processing and analytics. It enables more informed and "in business real time" decision making.

—— Gartner

02 HTAP架构和关键技术

2022年，清华大学的李国良和张超两位老师在国际数据库顶级会议 ACM SIGMOD 发表了论文《HTAP Database: What is New and What is Next》 ² ，并做了《HTAP Database：A Tutorial》报告。李张两位老师对业界 HTAP 数据库架构和关键技术做了详细的研究，并提出 HTAP 数据库的四大架构类型、五大关键技术的观点。

四大架构：

Primary Row Store + InMemory Column Store
Distributed Row Store + Column Store Replica
Disk Row Store + Distributed Column Store
Primary Column Store + Delta Row Store

五大技术：

Transaction Processing
Analytical Processing
Data Synchronization
Query Optimization
Resource Scheduling

本章内容主要是对两位老师论文解读，有兴趣的同学建议阅读英文版原文。另外，本章图表均出自两位老师的论文《HTAP Database: What is New and What is Next》及《HTAP Database：A Tutorial》报告中。

架构类型

主行存储、内存中列存储

这类架构的 HTAP 数据库，主行存储作为实现 OLTP ，并使用内存中的列存来满足 OLAP 的负载。所有数据都持久化存储到主行存储中。行存储也经过了内存优化，以便有效处理数据更新。更新也附加到增量存储（delta store），随后将与列存储合并。

例如，Oracle的内存双格式数据库结合了基于行的缓冲区和基于列的内存压缩单元（IMCU），以共同处理OLTP和OLAP工作负载。IMCU从缓冲区中填充数据，变更被缓存在快照元数据单元（SMU）中。另一个例子是SQL Server，在Hekaton 行引擎上开发了列存储索引（CSI）以启用实时分析处理。这类HTAP数据库具有高吞吐量，因为所有工作负载都是在内存中处理的。

分布式行存储、列存储副本

这一类依赖于分布式架构来支持 HTAP。在处理事务请求时，主节点会异步地将日志复制到从节点。主存储是行存储，一些从节点将被选为列存储服务器以加速查询。为了高可扩展性，事务以分布式方式处理；复杂查询在具有列存储的服务器节点上执行。

例如，TiDB它是一个基于 Raft 的分布式 HTAP 数据库，从 leader 节点异步复制 Raft 日志到存储数据的基于行的副本的 follower 节点。日志还会发送到 learner 节点，这些节点以列式格式存储数据。因此，由于事务在具有行存储的节点上处理，分析查询在具有列存储的节点上执行，工作负载隔离级别很高。但是，这种架构下存在数据新鲜度较低。

磁盘行存储、分布式列存储

这类数据库使用基于磁盘的关系数据库管理系统（RDBMS）和分布式内存列存储（IMCS）来支持HTAP。RDBMS保留了OLTP工作负载的全部容量，并且深度集成了IMCS集群以加速查询处理。列数据从行存储中提取，热数据驻留在IMCS中，冷数据将被逐出到磁盘。

例如，MySQL Heatwave 将MySQL数据库与称为 Heatwave 的分布式IMCS集群相结合，以实现实时分析。事务完全在MySQL数据库中执行。频繁访问的列将被加载到Heatwave中。当复杂查询到来时，它可以被下推到IMCS引擎进行查询加速。

主列存储、增量行存储

这类数据库使用主列存储作为OLAP的基础，并使用增量行存储处理OLTP。内存增量主HTAP数据库将整个数据存储在主列存储中。数据更新被追加到基于行的增量存储中。由于列存储高度优化了读取操作，因此OLAP性能很高。然而，由于只有用于OLTP工作负载的增量行存储，OLTP的可扩展性较低。

一个代表性的例子是SAP HANA。它将内存数据存储分为三层：L1-delta、L2-delta 和 Main。L1-delta 以行格式保持数据更新。当达到阈值时，L1-delta 中的数据被追加到 L2-delta。L2-delta 将数据转换为列数据，然后将数据合并到主列存储中。最后，列数据被持久化存储到磁盘上。

四种架构图HTAP数据库对比

最后两位老师的论文中，还将该四种架构的 HTAP 产品，根据 OLTP吞吐量、OLAP吞吐量、OLTP可扩展性、OLAP可扩展性、资源隔离、数据新鲜度 6个维度做了一个表格。

关键技术

事务处理技术

HTAP数据库中的OLTP工作负载是通过行存储处理的，主要有两种类型。第一种是依赖于MVCC、logging来处理事务。具体来说，每次插入操作首先写入日志和行存储，然后追加到内存增量存储中。更新操作会创建一个新的行版本，并赋予一个新的开始时间戳和结束时间戳的生命周期，旧版本在删除位图中被标记为删除行。这样DML操作是在内存中执行的，事务处理很高效。相关数据库产品：Oracle、SQL Server、SAP HANA。

第二种是依赖2PC、Raft、logging，它依赖于【架构类型】中的第二类架构。通过分布式事务处理提供了高可扩展性。ACID事务在分布式节点上通过2pc协议、基于Raft的算法和 WAL 技术进行处理。主节点接收请求，然后在本地追加日志并向从节点异步发送日志。如果大多数节点成功写日志，主节点就会向应用返回。与第一种相比，分布式事务处效率较低。相关数据库产品：F1 Lightning、TiDB

分析处理技术

对于HTAP数据库，OLAP工作负载是使用列式技术执行的，例如对压缩数据的聚合操作和单指令多数据（SIMD）指令。它们可以分为三种类型。

第一种类型是内存增量和独立列存扫描。这种方法将内存增量和独立列数据一起扫描，因为增量存储可能包含尚未合并到列存储的更新记录。好处是OLAP的数据新鲜度很高，坏处是需要更多的内存资源。

第二种类型是基于日志的增量和分布式列扫描，它将基于日志的增量数据和分布式列数据一起扫描，以处理OLAP查询。由于需要读取可能尚未合并的增量文件，这样的过程成本更高。

第三种类型是仅列扫描，它只扫描列数据以实现高效率，因为没有读取任何增量数据的开销。但是，这种技术当行存储中的数据频繁更新时，会导致OLAP中的数据新鲜度降低。

数据同步技术

由于在查询时读取增量数据成本较高，因此需要定期将增量数据合并到主列存储中。在HTAP数据库中，有三种不同的数据同步（Data Synchronization）技术，即：内存增量合并、基于磁盘的增量合并以及从主行存储重建。（in-memory delta merge、disk-based delta merge 、rebuild from primary row store ）。

第一类技术定期将新插入的内存增量数据合并到主列存储中。为了优化合并过程，引入了几种技术，包括基于两阶段事务的数据迁移、基于字典编码的排序合并，以及基于阈值的变更传播。相关产品有Oracle、SQL Server、SAP HANA。

第二类技术将基于磁盘的增量文件合并到主列存储中。为了加速合并过程，增量数据可以通过B+树进行索引，从而可以通过键值查找高效地定位增量项。相关产品有TiDB、F1 Lightning。

第三类技术从主行存储重建内存列存储。这在增量更新超过某个阈值的情况下很常见，因此重建列存储比合并这些具有较大内存占用的更新更有效。

查询优化技术

介绍了三种查询优化技术，包括：内存列选择、混合行/列扫描以及 HTAP的CPU/GPU加速。

第一种类型依赖于历史工作负载和统计数据来选择频繁访问的列，这些列从主存储中提取到内存中。查询下推到内存列存储中以加速处理。

第二种类型利用混合行/列扫描来加速查询。这种技术，复杂查询可以分解为在行存储或列存储上执行，然后将结果组合起来。

第三种类型的利用硬件 CPU/GPU 来加速 HTAP ，利用 CPU 的任务并行性、GPU 的数据并行性，分别处理OLTP和OLAP。适用于高OLAP吞吐量、低OLTP吞吐量。相关数据库RateupDB、Caldera。

资源调度技术

对于HTAP数据库，资源调度指的是为OLTP和OLAP工作负载分配资源，动态控制OLTP和OLAP工作负载的执行模式，更好的资源利用。有两种类型的调度技术，即基于工作负载和基于新鲜度的方法。

前者根据执行工作负载的性能调整OLTP和OLAP任务的并行线程数。例如，当CPU资源被OLAP线程饱和时，任务调度器可以减少OLAP的并行性，同时增加OLTP线程。

后者在资源分配和数据交换，动态切换OLTP和OLAP的执行模式。例如，调度器控制OLTP和OLAP的独立执行以实现高吞吐量，然后定期同步数据。一旦数据新鲜度降低，它就切换到共享CPU、内存和数据的执行模式。

03 国内主流HTAP产品介绍

根据墨天轮数据，目前国内数据库产品有200多个，其中按数据模型分 HTAP 有39个。因为众所周知的原因，市场上真正能打的HTAP产品并不多，本文选择了主要的TiDB、Oceanbase、PolarDB-X、TDSQL、GaussDB、GreatSQL等产品进行一个简单的介绍与总结。

图片来自墨天轮

图片来自墨天轮

TiDB

TiDB 早期是一款OLTP分布式数据库，主打scale-out，它也是国内较早拥有 HTAP 能力的数据库产品。早在2017年 V1.0 版本，就引进 TiSpark 组件 ³ 实现 HTAP 能力。在2020年 V3.1 版本发布 TiFlash 组件，具备完全的 HTAP 数据库 ⁴。

从PingCAP 公司产品文档介绍中我们知道，TiDB 通过提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，分别实现TP和AP业务场景。TiKV是 TiFlash 的特殊副本，它们之间通过 Raft 协议复制，列存的副本单独作为 AP 的使用，以此实现OLTP和OLAP的资源隔离。AP的数据新鲜度，通过TiFlash 节点校对实现。当TiFlash 收到OLAP请求时，列存并不会马上提供服务，而是先向行存主节点或者说主副本发起一个校对请求，整个复制是线性的 log 复制，这个请求本身仅仅包含很短的一段信息——在收到这个请求的同时，需要告知最新的复制进度，行存的主副本收到这份校对请求之后才返回 ⁵ 。

从以下架构图和相关产品介绍文章可以看出，TiDB 的架构类型属于分布式行存储、列存储副本架构类型；关键技术中，事务处理技术采用了使用日志回放的分布式事务处理、分析处理技术采用了日志文件和分布式列扫描、数据同步技术采用了基于日志增量的合并、查询优化技术采用了混合行列扫描等技术。

图片来自TiDB官方文档

Oceanbase

OceanBase 诞生于阿里浩浩荡荡的“去IOE”运动，根据相关介绍，其开始于2010年，最早是淘宝内部的一个项目，在解决淘宝收藏夹功能的需求。

2021年，OceanBase V3.2.0 版本中，开始发布 HTAP 能力。根据相关介绍，OB 从该版本开始定位为 HTAP ，支持不限大小的超大事务，引入向量化引擎、并行 DML、复杂查询优化，并在 V3.2 版本中进一步完善向量化引擎，以 1526 万 QphH@30000GB 的性能成绩，创造 TPC-H 分析型基准测试新的世界纪录，目前排名第二 ⁶。

2024年4月，OceanBase 发布 V4.3，该版本在原有能力的基础上，补齐纯 OLAP 所必须的能力，如列存、物化视图、数据导入、数据加工等 ⁷，使 OceanBase 成为真正 HTAP 数据库。

PolarDB-X

PolarDB-X 是阿里云一款云原生分布式数据，同时支持OLTP & OLAP 的融合型分布式数据库产品。早在2021年，PolarDB-X 就发布了面向 HTAP 的 CBO 优化器，分析出的OLAP请求将会通过MPP并行优化阶段，生成多机分布式的执行计划，下发至只读计算集群计算，访问只读副本，提供物理隔离，同时可以利用只读副本一致性读能力，保证强一致读。通过智能路由，用户可以非常透明地使用PolarDB-X同时处理OLTP及OLAP的诉求 ⁸ 。

2024年4月，PolarDB-X 发布 2.4.0 版本，推出列存节点 Columnar，提供持久化列存索引（Clustered Columnar Index，CCI）。PolarDB-X 的行存表默认有主键索引和全局二级索引，新增列存索引是一份额外基于列式结构的二级索引，实现了一个表同时有行存和列存数据，行存数据实现OLTP需求，列存数据实现OLAP需求，结合计算节点CN的向量化计算，实现 HTAP 一体化的体验和效果 ⁹。

列存索引是由Columnar 引擎节点来构造的，数据结构基于Delta+Main(类LSM结构)二层模型，实时更新采用了标记删除的技术(update转化为delete标记 + insert)，确保了行存和列存之间实现低延时的数据同步，可以保证秒级的实时更新。数据实时写入到MemTable，在一个group commit的周期内，会将数据存储到一个本地csv文件，并追加到OSS上对应csv文件的尾部，这个文件称为delta文件。

TDSQL

TDSQL 是腾讯云一款云原生分布式数据，目前也具备HTAP能力。从TDSQL的架构图看，TDSQL的 OLTP基于 SQL引擎实现，从而满足腾讯高并发、高扩展性的在线交易需求，扩展一个列存分析引擎实现OLAP。因为，TDSQL存储层是MPP架构，当接收到复杂SQL时，MPP SQL Engine 组件解析用户的复杂 SQL，并生成 MPP 计划下推到各列存节点中执行，从而提高TDSQL的AP能力。另外，TDSQL分析引擎还引入了向量化的执行引擎、基于代价的优化器优化、数据压缩等各类关于分析型查询的能力加持 ¹⁰。

TDSQL的列式存储是基于类 LSM-Tree（Log Structured Merge Tree）数据结构实现 ¹¹，支持高压缩比的数据存储。数据的更新在LSM 数据结构中是使用 append 方式进行，定期进行 compaction。从而支持在HTAP 场景中，TDSQL的超高写入性能，以及在高并发写入的负载下，查询性能依然波动较低。

GaussDB

GaussDB For MySQL 是华为自研的最新一代企业级高扩展高性能云原生数据库，采用计算存储分离、日志即数据架构。根据官方文档介绍 ¹²，GaussDB 的HTAP能力是基于开源Clickhouse进行深度二次开发的版本。采用列式存储引擎，利用单指令多数据(Single Instrnction Multiple Data，SIMD)并行计算技术，针对海量数据的分析场景，尤其是大宽表的场景下，查询性能提升尤为显著。

GaussDB 传统节点引擎的事务日志数据同步到HTAP节点，包括表增删改查操作和表结构变更类操作。数据同步到HTAP节点后，可以通过HTAP节点的读写内网地址或读写公网地址访问HTAP节点，满足OLAP需求。

GreatSQL

GreatSQL 是万里数据库维护的一款免费数据库，据官网（https://greatsql.cn）介绍，它可在普通硬件上满足金融级应用场景，具有高可用、高性能、高兼容、高安全等特性，可作为 MySQL 或 Percona Server for MySQL 的理想可选替换。近期发布的 V8.0.32-25 新增了HTAP能力。

GreatSQL的 HTAP 实现方式，简单说就是在 InnoDB 基础上，增加 secondary engine Rapid ，InnoDB 提供TP，Rapid 提供AP，并且还能基于主从复制或MGR进一步实现读写分离 ¹³。

图片来自官方介绍

其他

在互联网行业以及国家信创的孕育和支持下，国内数据库涌现出一批具有HTAP能力的产品。除了上述外，还有石原子StoneDB、亚信AntDB、星环KunDB、中兴GoldenDB、达梦DM8等产品，限于篇幅不再赘述，想要深入了解这些产品的同学，可以通过搜索相关文章、技术文档和用户案例，获取更多详细信息。也可以关注这些数据库厂商的官方网站和社区，获取最新的产品动态和技术分享。

04 特点和挑战

通过前文的介绍，可知HTAP数据库有这几个特点：

从HTAP的产品路径看，大部分数据库产品的HTAP产品是迭代出来的，并不是最开始就具备这能力，早期更多的是聚焦于 OLTP 场景，这类产品有TiDB、Oceanbase、TDSQL等。
从HTAP的能力实现方式看，无独有偶国内外相关产品均通过行存 + 列存来实现 TP + AP能力，这应该是行业共识，毕竟行存和列存特点非常明显。
从HTAP的资源隔离看， OceanBase 是行列混合存储，其他大部分产品均是行存和列存物理隔离。
从HTAP的新鲜度看，TiDB是基于 Raft 一致性协议的复制；TDSQL/PolarDB-X/GreatSQL 都是基于事务日志进行复制；OceanBase 由于是LSM数据结构，直接在压缩时生成两份数据。而国外产品，比如Oracle、SQL Server、SAP HANA ，则是在内存中将增量数据合并到主列存储中
从HTAP的发展和现状来看，HTAP也存在一些挑战：
TP业务要路由到行存引擎，AP业务路由到列存引擎，目前大部分产品架构还需要通过 Hint 来实现业务分流。如果借助优化器的代价系统、以及当前的 AI4DB & DB4AI 技术，能够更大程度的提供业务分流的准确性，从而对用户透明，提高系统的易用性。
从数据新鲜度看，HTAP 产品 AP 引擎的数据是由 TP 事务日志同步实现，如果是强同步，则响应是一大问题；而如果是异步，那么AP场景的数据新鲜度又是一大挑战。
从资源隔离看，大部分 HTAP 产品首先满足的还是OLTP场景，系统如何能够保证 AP 负载对 TP 负载无影响或者使得两种类型负载间的影响最小化，也是HTAP一大挑战。

参考

1.https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing

2.https://dl.acm.org/doi/abs/10.1145/3514221.3522565

3.https://docs.pingcap.com/zh/tidb/stable/release-1.0-ga

4.https://docs.pingcap.com/zh/tidb/stable/release-3.1.0-beta.2

5.https://www.vldb.org/pvldb/vol13/p3072-huang.pdf

6.https://mp.weixin.qq.com/s/r5AkjazqEs7MnqFJwGnykg

7.https://mp.weixin.qq.com/s/ccYkMoQ_QWuCA2lVzaicpw

8.https://mp.weixin.qq.com/s/KMF2WuZ5iGTD-gASBxya_A

9.https://mp.weixin.qq.com/s/sUttYeHBbeGhcDQXXFxhsw

10.https://mp.weixin.qq.com/s/ozjaonM6C43WceXNzSBpZg

11.https://mp.weixin.qq.com/s/mh5NZl_npvVxqBq9DJ6HKw

12.https://support.huaweicloud.com/usermanual-gaussdbformysql/gaussdbformysql_03_0080.html

13.https://greatsql.cn/docs/8.0.32-25/5-enhance/5-1-highperf-rapid-engine.html

作者介绍

司马辽太杰，目前就职于一家国有企业，主要负责数据库连续性保障、性能优化、架构选型和设计。10余年数据库架构和管理经验，专注于数据库运维、架构和行业发展，擅长常见关系型、NoSQL、MPP 等类型数据库性能优化、架构设计和故障排查。杭州乡下桐庐人，业余热爱历史、足球，偶尔读点闲书。欢迎关注个人公众号“程序猿读历史”,有需要在公众号上加我好友。

本文来自公众号：程序员读历史