GaussDB技术解读系列之HTAP方向的探索与发展
1 什么是 HTAP？
TP 和 AP 的特点
- TP 一般是做交易型的业务，
- 它的数据量通常来说比较小，在 GB~TB 的范围内，
- 它要求低时延、高吞吐，同时对高可用、故障恢复要求较高。
- AP 一般用于对历史数 据做分析，根据数据分析的结论为企业的商业决策提供一些支撑，因此
- AP 对时延和吞吐的要求没有 那么高，
- 主要面对数据量大、查询偏复杂的场景。
- TP 一般是做交易型的业务，
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 上，达成在性能、资源隔离、数据新鲜度方面有一个均衡的结果。