以“数智赋能 共筑未来”为主题的第14届中国数据库技术大会（DTCC 2023）在北京举行，华为云数据库技术专家张树杰分享了《GaussDB在HTAP上的探索与发展》主题演讲，介绍了华为云GaussDB在HTAP方向的思考与最新成果。

什么是HTAP？

本篇为大家分享《GaussDB在HTAP上的探索和发展》。

首先，我们看一下TP和AP的特点。TP一般是做交易型的业务，它的数据量通常来说比较小，在GB~TB的范围内，它要求低时延、高吞吐，同时对高可用、故障恢复要求较高。AP一般用于对历史数据做分析，根据数据分析的结论为企业的商业决策提供一些支撑，因此AP对时延和吞吐的要求没有那么高，主要面对数据量大、查询偏复杂的场景。

早期数据库对TP、AP区分没有那么明显，所有业务都放在同一个数据库上。随着时间的发展，数据量越来越大，人们倾向于把TP放在数据库层面上，AP由数据仓库解决，中间通过ETL工具把TP的数据传输到AP数仓上。这种模式兴起和盛行于20世纪90年代并持续到现在，我们一直还在使用着TP、AP混合的架构。

随着CPU算力、内存容量、磁盘IO效率发生变化，一些老的软件体系结构随着新硬件、新算法的发展都在发生改变。所以在2010年左右，业内开始考虑把TP和AP同时融合到同一个数据库里，通过这种方式提升数据库处理数据的能力。

关于HTAP，目前还没有一个明确的定义，即使有一些公司或者个人给出了定义，但实际上也不是特别精确。我们总结了HTAP有两个关键特点：

一个是采用In-Memory的架构。我们可以看到，无论是老牌的数据库厂商，还是新兴的数据库厂商，都不约而同采用In-Memory的架构来实现HTAP。

另外一个是实时。我们当前的架构主要是，交易型的业务在行存的数据库上，分析型的业务在列存的数仓上，中间通过ETL工具传输数据。这个架构的问题是，它的数据新鲜度不够好，比如说先前在互联网应用方面，我们经常做一些个性化的用户推荐，在给用户推荐感兴趣的商品时，会在登录时对它进行一个用户画像，根据用户画像的结果推荐产品，这是一种实时分析的能力。另外就是防诈骗系统，需要实时的响应，实时分析这笔交易是否为诈骗交易。这种实时性的特点，对HTAP方案提出了新的要求。我们当前的HTAP架构主要应对实时AP分析的能力，实时AP对性能上有一些影响，它随着数据新鲜度，也就是实时性要求变高，数据库的性能会有一些下降。

HTAP架构模式有哪些？

我们在设计HTAP架构时要考虑更多的维度，比如说硬件、资源隔离，从这些维度考虑，HTAP的架构会多种多样，加上应对的用户场景不同，会催化出不同的HTAP架构模式。我们对当前主流的HTAP架构进行了以下分类：

1. IN-Memory Store模式

这种模式在同一个集群内对行存引擎做了增强，用空间换时间，在内存里保存一份列存数据，我们可以把他看成是一个列存索引，这种架构下的数据新鲜度比较好，行存和列存的数据完全同步，在行存和列存中间，会有一个Delta表记录增删改操作带来的增量数据，后台有进程定期将Delta表里的数据Merge到列存引擎。但是这种架构的扩展性一般，资源的隔离性不佳，能够支撑的列存的数据量也是有限度的，因此这种架构适用于TP为主，实时AP为辅的业务模型。

2. 主备架构模式

这种模式下主机上是行存模式，应对TP业务负载，在只读的备机上是列存模式，应对AP的业务负载，主备之间通过物理复制或逻辑复制的方式实现数据同步。这种方式的扩展性、资源隔离性都比较好，但是数据的新鲜度取决于主备之间的数据传输模式，如果采用同步复制，则主备的数据新鲜度较好，但是对主机的事务吞吐量会有所影响；如果采用异步复制模式，则主备的数据新鲜度取决于数据的延迟。

3. IN-Memory Computing模式

这种模式将列式内存引擎和数据库对接，由数据库负责TP业务，列式内存引擎负责AP业务。由于其部署在云上，因此有很好的计算弹性，数据库和列式内存引擎之间通过逻辑复制同步数据，数据的延迟小于100ms，能够较好的兼顾数据新鲜度和性能之间的平衡。

4. 主列存+增量行存模式

通过主列存+增量行存的方式既能够较好的支撑TP业务，也能够应对AP业务，在TP/AP性能上做了一些均衡。其中增量行存可以看做是delta表，应对TP中的增删改操作，保证增删改操作的性能和TP系统基本一致，同时通过主列存引擎对AP业务进行加速，当然在做AP业务时，会同时访问增量数据和列存数据，达成数据的一致性。

我们有了这么多模式之后，可以思考两个问题。一个是到底什么样的架构才是真正的HTAP架构？我个人的观点是没有适合的定义，因为在不同的业务场景下，TP和AP的占比不一样，包括周边各种环境，各种因素都不同，每个用户的选择也会不一样。包括我们在HTAP研发过程中接触到很多用户，每个用户都提出很多要求，像Orcale这种架构更适合重TP、轻AP的场景，而HANA这种架构更多是做偏AP分析型的应用。如果我们以TP、AP业务占比做一个横轴的话，每个架构在上面都有一个独立的坐标点。

另外一个问题，我们当前这些HTAP的主流架构能不能取代以前的那种TP+ETL+AP的架构？从目前看，如果我们把HTAP定义为实时TP+实时AP，实际上是不能取代的，因为TP+ETL+AP这种架构，AP的数据量远远大于当前HTAP的主流架构所能支撑的AP数据量。

GaussDB对HTAP的思考

在GaussDB HTAP开发过程中，我们总结了以下实现HTAP架构需要关注的核心技术：

第一，透明路由。它之所以成为关键的原因是因为增加了客户的易用性，提升了HTAP产品的商用价值。这里面有两个观点，一个是如果HTAP基于行存和冗余列存这种方式，需要判断哪些数据被冗余到列存里面来，因此提供一种自动化的方法根据业务特点来选择加载列存数据，并对用户透明就非常有意义。另外，TP业务要路由到行存引擎，AP业务路由到列存引擎，目前大部分架构还需要通过Hint的方式来实现业务分流，如果借助优化器的代价系统、以及当前的AI4DB技术，能够更大程度的提供业务分流的准确性，从而对用户透明，提高系统的易用性。

第二，性能提升。我们把TP和AP融合起来比较困难的关键原因，主要是因为AP查询的复杂度比较高。如果是一个纯TP数据库，一些常规执行优化技术，比如说并行、编译执行、向量化执行，TP上虽然也有，但实际上很难有大的作为，因为TP要求的是低时延、高吞吐，这种情况下这些技术都有自己的启动代价，这些启动代价会对TP的性能产生很大的影响。在TP上，如果我们把HTAP里面的AP融入进来，这些技术就能大有可为，我们在这些技术的基础上对复杂查询进行加速，可以很好地支撑我们现在的性能，支撑我们的HTAP。

第三，数据新鲜度。我们多次讨论实时性的问题，不同的数据新鲜度最后带来的就是我们不同的架构，有In-Memory的，有主备的，也有基于增量表技术的，都会带来不同的数据新鲜度。在这种数据新鲜度下，我们怎么保证数据新鲜度高，而且性能又好。在这些方面我们需要更多的思考，来保证我们HTAP架构能够具备更多应对用户的能力。

第四，资源隔离。我们看到有的架构，比如说用户对TP性能要求比较高，要求你在引入实时AP的同时，不能影响TP的能力和性能。也有用户提出对整体的能力要求，对硬件没有什么诉求，如果有需要可以增加硬件。不同的用户有不同的要求，我们在面对这样的用户时，需要在资源隔离和数据新鲜度，以及性能的提升方面做好权衡。

GaussDB在HTAP上的创新

GaussDB在现有基础上对HTAP进行改造，并实现以下几个方面的提升：

• 性能提升数十倍。GaussDB已经实现向量化、并行、编译技术，性能提升10+倍，一些场景下还有更高的性能提升。最近我们基于HTAP做了更深度的挖掘和优化，比如基于降低内存拷贝、延迟读等技术，向量化的扫描算子最新的数据又提升了大概30倍左右。

• 100%的透明路由。我们既有基于Hint手工指定的方式，还有基于规则、基于代价、基于AI的透明路由技术。我们在基于代价的透明度路由方面，做了向量化优化技术；基于AI的透明路由方面，我们通过轻量的AI技术可以真正应用到商业版中，通过这些技术，TP、AP分流的准确率目前表现还是不错的。

• 100%的数据新鲜度。我们实现了在同Server内的列式的内存引擎，数据同步方面支持实时同步、在线同步、定期同步，保证了TP上的数据和IUD操作带来的数据修改及时同步到引擎上，可以实现100%的数据新鲜度。

• 100%的资源隔离。如果用户更关注的是100%的资源隔离，我们也提供了基于主备复制HTAP模式，通过读写分离，把TP业务放到主机上，AP业务放到备机上，实现资源的隔离。

目前，GaussDB既有基于同Server的实时的HTAP，也有基于主备技术的准实时的HTAP，同时在透明路由的加持下，能够准确的把业务分流同步分到实时的HTAP上，达成在性能、资源隔离、数据新鲜度方面有一个均衡的结果。

今天的分享就到这里了，谢谢大家，欢迎留言讨论交流~