目录

GaussDB技术解读系列之HTAP方向的探索与发展

本文为摘录(或转载),侵删,原文为: https://mp.weixin.qq.com/s?__biz=MzU2MDcxODEyOA==&mid=2247516317&idx=1&sn=1ce041534c61c34cd1ab12d90df7c1d6&chksm=fc0108c2cb7681d4be8d3c1fdb3a10662ad10562288d149c964e8a3f99b3d8cbeb804039be2a&mpshare=1&scene=1&srcid=0822kXJqkOrYaspzxxbWHkai&sharer_sharetime=1692699939078&sharer_shareid=9e76a16cd9cee4d8b92e9f0cc7b3921c#rd

1 什么是 HTAP?

  • TP 和 AP 的特点

    • TP 一般是做交易型的业务,
      • 它的数据量通常来说比较小,在 GB~TB 的范围内,
      • 它要求低时延、高吞吐,同时对高可用、故障恢复要求较高。
    • AP 一般用于对历史数 据做分析,根据数据分析的结论为企业的商业决策提供一些支撑,因此
      • AP 对时延和吞吐的要求没有 那么高,
      • 主要面对数据量大、查询偏复杂的场景。
  • 2010 年左右,业内开始考虑把 TP 和 AP 同时融合到同一个数据库里,通过这种 方式提升数据库处理数据的能力

  • 总结了 HTAP 有两个关键特点:

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

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

2 HTAP 架构模式有哪些?

2.1 IN-Memory Store 模式

这种模式在同一个集群内对行存引擎做了增强,用空间换时间,在内存里保存一份列存数据,我们可以把他看成是一个列存索引,这种架构下的数据新鲜度比较好,行存和列存的数据完全同步,在行存和列存中间,会有一个 Delta 表记录增删改操作带来的增量数据,后台有进程定期将 Delta 表里的数据 Merge 到列存引擎。

但是这种架构的扩展性一般,资源的隔离性不佳,能够支撑的列存的数据量也是有限度的,

因此这种架构适用于 TP 为主,实时 AP 为辅的业务模型。

2.2 主备架构模式

这种模式下主机上是行存模式,应对 TP 业务负载,在只读的备机上是列存模式,应对 AP 的业务负载,主备之间通过物理复制或逻辑复制的方式实现数据同步。

这种方式的扩展性、资源隔离性都比较好,

但是数据的新鲜度取决于主备之间的数据传输模式,如果采用同步复制,则主备的数据新鲜度较好,但是对主机的事务吞吐量会有所影响;如果采用异步复制模式,则主备的数据新鲜度取决于数据的延迟。

2.3 IN-Memory Computing 模式

这种模式将列式内存引擎和数据库对接,由数据库负责 TP 业务,列式内存引擎负责 AP 业务。

由于其部署在云上,因此有很好的计算弹性,数据库和列式内存引擎之间通过逻辑复制同步数据,数据的延迟小于 100ms,能够较好的兼顾数据新鲜度和性能之间的平衡。

2.4 主列存+增量行存模式

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

3 思考

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

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

3.1 GaussDB 对 HTAP 的思考

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

3.1.1 第一,透明路由。

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

3.1.2 第二,性能提升。

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

3.1.3 第三,数据新鲜度。

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

3.1.4 第四,资源隔离。

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

4 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 上,达成在性能、资源隔离、数据新鲜度方面有一个均衡的结果。