TDSQL | 在整个技术解决方案中 HTAP 对应的混合交易以及分析系统应该如何实现？

从主交易到传输，到插件式解决方案，每个厂商对 HTAP 的理解和实验方式都有自己的独到解法，在未来整个数据解决方案当中都会往 HTAP 中去牵引。那么在整个技术解决方案中 HTAP 对应的混合交易以及分析系统应该如何实现？

本文是腾讯云数据库总经理林晓斌先生在《DTCC 2021 中国数据库技术大会》演讲实录，将详细解读 HTAP 数据库应用时间场景和未来发展趋势，带大家共同探讨 HTAP 数据库解决方案。

数据分析其实一直都在，只是现在对实时性要求越来越高，之前相关报表统计，第二天早上上班之前得到结果就可以，现在要求分钟级得到结果。 同时随着数据量变大，这对计算的要求就更高，客户需求也随之越来越严苛。

去年第七次全国人口普查中，给应用后台分析时间非常短暂，整个数据量非常大，我们也深刻感觉到 HTAP 这种系统解决方案的必要性。腾讯也一直致力于这个系统构建，今天想跟大家分享一下我们对 HTAP 系统的理解。

**为什么需要 HTAP？**一个生态内需要支持 TP 和 AP 的工作负载，这几乎是要求实时性同时了，看上去好像是两个系统，实际上我们对系统要求更希望看上去是一个。系统需求有哪些呢？第一个是低延迟，通常所说的延迟是一个请求写下去就有反馈给客户端，这种都是毫秒级的。而现在提到的延迟是指一个数据写进去之后，多久能从分析系统里体现出分析系统的结果，目前已经达到了分钟级别。如果你告诉客户数据写下去以后，2 个小时可以构建到分析系统里，这是不可行的。

同时在性能吞吐方面，我们知道 AP 系统存储、尤其是在查询能力或单点并发方面比较具有优势。那 TP 系统怎么跟上 AP 吞吐能力和一致性？我们看到业界在做解决方案时，无论是构建同一个系统架构，还是传输服务内部做数据传输重建，模型都是差不多的，都是在解决数据的一致性，但是数据的强一致性是个非常大的挑战。

一个基本的 HTAP 架构应该是什么样的呢？借用腾讯自己的内部解决方案来举例，我们第一代架构是比较传统 TP 和 AP 做比较明显的分开，对应用来说可以统一成一个入口。能够在 TP 侧写入，通过 DTS 打通。如果做两个同步数据库之间传输，做数据校验和稳定性，AP、TP 数据往往结构是异构的，所以要做存储格式转换。这个点其实是如何做到通用性对系统的考验，比方说针对一个具体应用很好做，但是如果做成通用的云上服务就很难了。

**那怎么做到云上服务？**可以灵活定制，甚至可以用拖拽来进行业务定制。当数据传输到这，后台就由 AP 列出来做数据分析的能力，目前已基本实现了主流 MySQL 和 TDSQL 等解决方案。这么一套系统比单独一个挑战更大，它不只是在检查每一个组件是否健康、数据是否保持一致性，还要检查同步服务延迟以及预测延迟风险，预测多久可以做到，我们当然希望实现分钟级、秒级的延迟，但是 TP 端业务量突然增大，就需要分析出当前主要延迟在哪个位置，同时还要预估出多久可以恢复，这个对系统诊断的要求很高。

现在诊断系统构建还是比较方便的，这是一个比较常见的架构。可以看到国内有很多把 HTAP 做到整个系统的数据库，基本上都是把组件扩展外延搭积木，整体流程变化不大。我们之前也看到过一些解决方案，比如直接在 TP 系统上做分析，或是直接在 AP 系统上 TP 能力，目前来看也没有很成功的案例。在开始做大规模数据分析的时候，如果没有做数据重建其实是很难呈现的，我们跑下来之后，也加深了我们这方面的认知，专业事件还需要有专业模块去做。

**那么我们说的这个架构痛点是什么？**如果导入太快，会造成 AP 系统负载高，会影响查询性。如果导入慢一点，会有延时，影响到实时性。不同业务有不同的容忍时间，可以给我们系统提供一些参数调整。

在数据一致性这块，尤其是实时一致性方面会有更强烈的挑战，比方说有些数据要求马上能用，当然不是所有的，这时候就需要做一些跨组件语句，不同数据就通过普通传输，要求严苛数据就需要提供一致性的语句。过一段时间数据再需要同步的要求，我们就要做跨系统的同步，包括一致性。

水平扩容方面，基本可以做到自动化，考虑到这个数据还有人去消费，外部系统的强耦合，当一个 TP 系统有标准的流程，需要考虑到这个系统跟 AP 系统联动，它的日志合并逻辑，日志的持续逻辑都需要访问进去，这是目前系统遇到的一些挑战。

这些问题并不是百分之百能解决，但是我们可以有一些改进方法，基本思路用一句话来讲怎么解决这个痛点？提供源到端的全链路闭环。从用户视角来说就是一个入口，一个出口，甚至入口和出口做到同一个，降低接入难度。一个系统复杂度就在那里，降低用户使用的难度，就是把难度在系统内部消化，我们思路就是提供一整套解决方案，让用户感觉到他使用一个系统，把数据同步、延迟、一致性校验等工作在系统内部去实现，用户不用关心这些细节。

基本实现细节，在云端通过无锁迁移，通过 binlog 订阅从 P 同步数据，降低 TP 节点的影响。在 AP 侧，这套系统能跑得比较顺畅，但是在 AP 侧的改动是非常大的。传统引擎接进去能不能运作？真正实现联动，也需要对 AP 系统做很多改造，把自己主动接入进去做同步，以及提供信息，主动把信息暴露出来，给整个诊断系统去诊断，去发现问题。

同时通过 DTS 批量写入，AP 系统单独写入是很慢的，可能一秒写两三万，一般解法是通过批量写入，通过这种方式去导入，提高 AP 系统的吞吐量。但是需要内核暴露关键指标，自动调节批量大小和写入频率，实现写入自动拥塞控制。固定频率或者拿到一些反馈，通过 RT，通过数量等方式来调整写入的速度。现在整个思路会反过来，AP 系统自己写的时候，一边把信息暴露给外面，了解这个系统接下来能接受多大写入量，用这种方式来调节窗口。经过我们的实践，这种方式是比较简单的，一方面能够保证 AP 系统能写进去，另外也不会导致浪费。

我们也可以通过不同数据类型去做区分，有些数据是实时的，这一行数据强同步，超过 80%数据应用是可以接受 TP 写完，在通过 AP 旁路方式写进去，保证最终一致性，让 DTS 和 AP、TP 系统形成联动，避免出现黑盒，这样调整能力会比较高，通过这样方式实现系统稳定性。

除了保证系统的稳定性和一致性，还有系统的实时性，实时性往往可以调节，所以稳定性是非常重要的，最担忧的问题是写进去以后过 5 分钟查不出来，却不知道原因，所以稳定性是比较重要的，需要对系统内部信息有非常明确了解。

数据一致性在这里的要求，要求自动映射。在生产系统里常规数据写入，数据库里面有逻辑日志，这些日志可以环节数据的内化，同步到系统当中。另外 DDL 同步要求更高，有两个原因，一个是 DDL 里面没有全部信息，如果想加一个、减一个列，但是你只有一个列的信息，没有整个表的信息，这样对就需要有模块对整个系统的元信息进行管理。另外就是实时性，一旦 DDL 出现延迟，可能会影响后续更改数据的同步，所以 DDL 语句同步也很重要。我们想让系统放在公有云上，大家都知道用 MySQL，但是用 TDSQL，创建完之后就可以了，如果我们希望整个系统可以自治好用，实际上 DDL 同步是非常关键的。

binlog 改写也非常重要，让后续 UPDATE/DELETE 同步的一致性和实施性的完整方案得以保证，日志变更改写怎么做到让 AP 系统也能够理解，这一块设定是非常重要的，是属于比较好接入的，我们也积累了很多专家工程师，对日志做充分补充，让这三类数据得以保证。

另外在数据一致性方面，TP 系统的几类挑战包括数据类型挑战，第二是 TP 系统做迁移的挑战，另外 AP 系统本身也有扩容的需求。AP 系统做水平扩容也是一样，保证这个系统从闭环推动，整个过程做 ReSharding，这个过程怎么做到业务写入和读取数据能够实现无感知，现在比较常见的做法是先有一个 AP，设置节点，然后再进行扩展，做数据同步和拆分，拆完以后再切过去，但是这个成本比较高。我们目前正再探索一些本地扩容的方法，这样成本会更低，另外扩容速度也会更高一些，在这里面有很多挑战。

后续我们认为 HTAP 的服务可能需要增加 Controller 的角色，管理所有节点，包括对整个集群信息结构的控制，做到统一管理。第二个是加入节点和水平过载过程中，集群统一管理，目前每个组件单独管理，也是比较大的挑战。因为对目前实现来说是架构上比较大的改变，我们相信当我们要实现最终的，从源到端闭环，要有统一入口，对语序做自动识别，所有查询都要做分析、解析，去判断往哪一个系统接入，做到这一步我们才认为是构建完整的 HTAP 架构。

目前腾讯云服务已经能满足较高的生产需求，包括公有云项目已经验证过我们有这个能力构建一套 HTAP 系统服务整个业务，当然我们的挑战还有很多，可能十几年前硬件有瓶颈，之后是网络访问的瓶颈，到慢慢我们发现一个新的挑战，这个挑战我们并不能提前做准备，很可能这个需求一直存在，只是受限于各个系统发展。现在分钟级已经不能够满足用户的要求了，目前我们看这个路线有可能实现秒级数据构建完成，但是需要更多的细节的把握和优化，核心的点还是 AP 系统怎么无缝衔接到整个体系里，把内部信息暴露出来提供给整个系统的能力，最终保证系统的稳定性，这是我们认为这个系统的最大挑战。

目前来看是锦上添花的工作，可能再过一两年又会变成新的景象，我们做数据库行业的同学们还是很兴奋的，因为我们发现了一个可以让我们深耕，又可以明确感知到在生产或者生活领域的系统当中，这是我今天的分享，感谢大家。