谢灿扬
腾讯云数据库高级工程师、PG 中国社区顾问
专注多年 PostgreSQL 数据库，主导并设计 TDSQL-PG 核心架构能力。主要负责 TDSQL 数据库内核架构研发工作。
HTAP 数据库作为近年数据库领域的热门，在其技术探索中都有哪些值得参考的最佳实践？在 2022 年第五期 DBTalk 技术公开课中，腾讯云数据库高级工程师、PG 中国社区顾问谢灿扬带来了主题为《HTAP 数据库最佳实践》的分享，重点介绍了 TP 与 AP 的业务特点、目前 HTAP 的业务需求，以及 TDSQL-PG 在 HTAP 场景中的实践。
HTAP 概述
首先我们看一下 AP 和 TP 的业务特点。TP 是大家比较常接触到的，比如说健康码、淘宝账号、微信支付里面的金额都是用 TP 来服务的。它的特点是数据量相对比较小，每个用户就几条数据，另外它需要比较低的延迟。比如说一条语句要求几毫秒返回。因为它应用中可能有多次交互，如果几分钟返回的话整体页面就会卡死。另外由于用户特别多，它可能需要高吞吐量，比如说应用是面对全国人民的，有比较高的并发。它对容灾的能力要求比较高，比如说银行账号如果中间 50 分钟不能用了，会发生比较严重的社会问题。
AP 相比 TP 数据量大了很多，一般采取压缩技术降低成本。AP 大部分场景下不是直接面对用户，一般来说面向比如公司内部的数据分析师，或者里面的调度系统。比如滴滴打车，我们要看哪一块区域车比较多，这都是系统来实现的。或者是每天有报表，可以看一下昨天入账多少钱，消费了多少商品，还有多少库存，这些都是用 AP 做的。因为它数据量比较大，所以它的查询会越来越复杂。可能你要分析出比如说某年龄段在某时间段，消费某一样商品的年龄分布，或者金额分布，条件越复杂就跑得更慢，占用资源也更多。所以一般就要资源隔离的能力来减少用户之间互相影响。
技术实现方面，TP 必须是事务模型。比如说银行转账，两个人加起来金额是一样的，如果不是事务的话有个瞬间加起来钱就变多了，会有很多问题，相当于总账不一致了。因为它对低延时要求比较高，所以你需要把它的执行路径压缩，尽可能用少的 CPU 消耗执行这一块的查询，而且还要毫秒级、高并发，还要有内存缓存，这样跑起来更快。还要有容灾能力，银行客户肯定最重视容灾，一年宕机最多不能超过 5 秒，这都是非常高的企业级能力。
AP 这一块是有大数据量，所以我们用列存储。列存储的好处是容易分析，可以做向量化的执行引擎，另外 JIT 也可以减少开销。因为 AP 场景更复杂，优化器可以做专业的优化。还有因为 AP 用户会互相干扰，所以需要资源隔离，平衡不同优先级的任务。
之前传统的 TP、AP 混合方案中，因为 AP 和 TP 属于不同的组件系统，需要连接器连起来，需要把数据定时或者用一种 ETL 工具导过去。ETL 工具比较复杂，可能需要数据清理、数据转化，整体来看会有比较大的延时。
新时代对 HTAP 业务需求更高了，首先用户希望日间交易和夜间交易可以做资源复用，比如说白天写数据，晚上把查询统计跑出来。然后对实时分析的要求提升，越来越多严格的应用要求实时、半实时，几十毫秒就要查出来。另外分析精度要提升，因为大数据面临的需求越来越多样，可能需要更多更精确的计算，需要更好的优化器、更快的执行引擎。最后一点，某些业务场景是 AP 和 TP 混跑、同时运行的，需要做准实时的调度。
Gartner 关于 HTAP 趋势判断提到，整体来说 HTAP 可以带来新的行业机会，让普通的厂商做到更好的数据分析来提升生产力。HTAP 还可以摆脱冗余的 ETL 和 AP 工具，这样它的运维和人工成本会大大减少。
HTAP 计算模型可以认为是两者叠加，但又不只是两者叠加，如上图。
上图是业界常见的 HTAP 兼容方案。
TDSQL-PG 实践
第二部分看一下我们的 TDSQL-PG 产品对于 HTAP 的实践。这里我们主要是在 MPP 的层面上去实现的。第一我们采用了优化器融合设计，TP 和 AP 的优化器是一套，优化针对 AP 和 TP 都可以达到比较好的效果。它们共同的部分性能都是可以达到目标的。这里还可以做动态的资源调整，调整 TP、AP 的资源分配。另外是事务模型，是用一套引擎去实现 AP 和 TP。
我们是在一套存储引擎下面支持了行列混合，你可以自己任意按照业务的情况选择行存表或列存表，行存和列存都可以享受到上层 AP 优化器、TP 优化器带来的比较大的性能提升。
因为我们是 MPP 架构，支持最多 1024DN 扩展，随着业务扩展可以通过 MPP 扩展能力来满足要求。
事务这一块，在之前的老版本或 App 场景中，事务一般来说要找 GTM 拿快照。GTM 的全称是事务管理器，拿这个快照发送到各个节点上。这个快照比较大，随着并发数越多快照更大，于是会消耗网络资源，而且每个事务来或者是每个 Statement 来时，它对网络延迟的影响比较大，导致它不能有非常高的并发。
这里我们优化了方案，把它改成基于 Timestamp 的分布式提交协议，把 GTM 变成了 GTM 集群。它干的活非常简单，就是把时钟发出来，比之前轻了非常多。而且它的网络也不会成为瓶颈，如果发生容灾，它可以保证整体的高可用。它是单点分发，做的事情非常简单轻量，经过我们的实测它可以每秒处理 1200 万个事务，绝大部分用户都用不到这么高的性能。随着硬件提升这个数值可能还会更高。
GTS 会随着执行写入到底层的存储中，判断整体可见性。
行列存是用了一套事务模型，行存就是按照原有的模型，列存有另外的表。列存扫描的时候性能也是可以得到保证的，存储可以支持整体的 Snapshot，事务隔离级别都是可以支持的。
列存之前的比较大的痛点是，因为列存只能写不改，但数据库层面肯定要支持这一点，只写不改是在文件层面，这样小数据更新性能比较差。所以我们引入了 Stash，小数据量更新或插入都会掐到行存表中，大数据量的更新会直接在列存表中。这样的好处是小数据量可以享受到行存的性能，大数据量可以达到列存的性能。然后我们会定时触发机制，按需看整体的负载情况，定时把这个 Stash 表中的东西融合到列存。
行存和列存是一套查询优化器，我们做了很多优化，比如说自查询提升、索引优化、支持各种延迟物化或者 TPA 层面的快速剪辑、分区表。优化器对复杂和简单查询都可以给出比较好的优化，还支持优化项目智能推荐。
上面是 TP 层面的优化措施。
对 AP 场景来说向量化是非常重要的优化，如上图。这里的 Hash Agg 可以利用 CPU 并行计算的能力，可能就是几百倍的提升，对 AP 来说效率是非常高的。那么是不是只有列存才能享受到向量化优化呢，肯定不是的。行存也可以做向量化，把这些东西转换成内存和列存的方式，也可以享受向量化执行器带来的优势。
对 HTAP 非常重要的是资源隔离。AP、TP 查询肯定要保证优先级，不能因为有 AP 查询，比如说跑报表，所有的页面和所有的 App 客户就要停着等我，这样业务跑不起来。它需要机制保证 TP 查询都是 OK 的，不会受到 AP 任何影响。我们会通过 CN 做统一管控，然后在底层有不同的资源组整体把控 TP、AP 资源，整体保证 TP 的资源占有率。
另外一种隔离方法是主备平面做隔离，比如说 TP 业务只写入操作主平面，AP 可以操作另外一套集群，是完全不同的一套集群，部署在另外一套环境上。这样它们的资源完全不会有冲突，AP 查询可以用更好的机器，或者可以把这几个 DN 融在一起达到更高的利用率，或者把压缩打开，整体来看效能会更好。
之前我们做的一个重要的 HTAP 项目是第七次人口普查。14 亿人每个人都要在数据库捞一遍，每个人算一遍。这个场景有很多业务员，很多自主申报，都会采集完入库。白天大家都在工作，晚上因为没人，我们要去算省内或者是历史趋势变化，做很多计算。通过 HTAP 模式大大提升了人口普查的效率。
后续规划
最后讲一下我们后续的演进规划。
首先是资源组隔离，现在它需要人工配置，不是特别智能，实时性比较差。我们要做到自动伸缩，动态调整资源占比。
然后是场景优化器，现在上游还需要判断语句是 AP 还是 TP 场景，我们其实可以做到更进一步，由场景优化器根据 COB 做评估，客户端就不用管了，直接跑就行，这样可以减少业务负担。我们也可以支持更弹性的扩容，这些都是我们努力的方向。
存储这一块，现阶段很多数据库不能做到中间的版本清掉，也就是说 AP 跑越久数据会越膨胀，导致 TP 效率越低。业界也做了比较多的研究，后面我们计划把这一块做好。我们还会去看业界和友商的场景取长补短，衍生出不同的数据库。
