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系统怎么无缝衔接到整个体系里,把内部信息暴露出来提供给整个系统的能力,最终保证系统的稳定性,这是我们认为这个系统的最大挑战。

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

你可能感兴趣的:(数据库)