![](/wp-content/uploads/2023/11/frc-cf0d92129138e2c138e143696168013a.png)
以“数智赋能 共筑未来”为主题的第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上,达成在性能、资源隔离、数据新鲜度方面有一个均衡的结果。
今天的分享就到这里了,谢谢大家,欢迎留言讨论交流~