一、 TDSQL 概述

TDSQL 是一个稳定运行了十年之久的分布式数据库，不仅支撑了腾讯公司的计费业务，而且还在微众银行等金融单位的核心业务系统稳定、高效地运行了四年之久。这几年，TDSQL 在技术层面不断进步，研发了很多新特性，诸如多级分区、热点更新、隐含主键、分布式事务等，不仅有力的支撑了事务型的数据库应用，而且在体系结构上也朝 Spanner 架构上迈进，是一个名副其实的 NewSQL 系统。

TDSQL 分布式事务处理技术，有了长足进步，不仅表现在基于 XA 实现了 2PC 以支持分布式事务的原子提交，而且在 MVCC 技术的基础上，做了创新，使得 TDSQL 的事务处理技术基于原创技术而不断发展。

二、原创技术的出发点

TDSQL 的原创技术，不是为技术而技术，而是基于业务的需求，为解决业务问题而进行的创新。

腾讯公司的计费业务系统，是世界上领先的金融云计费业务系统。这个系统包括 SAAS、PAAS、IAAS 三个层面。在 SAAS 层面，包括米大师、云商店、TDSQL 等系统。

TDSQL 托管账户近 280 亿，米大师依托 TDSQL 进行金融交易,腾讯充值及其相关合作伙伴的日流水量超过 150 亿条，每天处理的交易量超过 100 亿笔。金融数据在 TDSQL 数据库中进行结算、对账、审计、风控数据分析、构建用户画像等业务。如王者荣耀游戏点券的对账业务、用户账户消费充值变化审计与风控业务等。

要进行诸如对账、审计等业务，数据来源有两部分。一部分数据来源是从不同系统（关系数据库或 NoSQL 系统）的日志数据中来，称为流水日志。但某个这样的系统每天的日志流水数据近百 G 且从趋势看增量数据递增很快。另外，有些数据是在 TDSQL 中按时间分表，需在一段时间结束后对按时间分表的数据利用流水日志进行对账计算。

对账主要是解决几种异常情况：

1. 系统存在 BUG，或者在故障时，未表现出预期的情况。这可能导致发货成功扣款不成功，或者扣款成功未发货的情况。如腾讯视频 VIP 管理系统的充值、发货。

2. 规避黑客/内部风险。例如不法人员绕过业务系统去给自己充值等舞弊行为。

这样的对账业务种类很多，不同的应用其日志流水格式不完全相同，TDSQL 托管的账户需要定时对多级数千种业务和账户做数据一致性对账检验。

从技术的角度看，存在四个问题：

1. 应用开发复杂：使用业务日志，需要业务系统不断产生日志信息，然后耗费计算资源对不同的日志格式进行解析，把日志信息存储到分析系统。由此带来了开发的负担和资源的浪费。

2. 数据逻辑割裂：TDSQL 中按时间分表，只能按确定的时间段进行结算，不能灵活、方便的计算。如计算任意时间段内的数据，按时间段的分表在物理上割裂了数据按时间的逻辑连续特性，需要指定若干个特定的分表才能进行计算。

3. 实时特性丢失：如上两个问题，隐含地，意味着进行计算的数据需要导入到一个新的分析系统进行计算，导出/导入数据的过程也带来了资源和时间的消耗、使得分析系统难以具备实时计算特性。

4. 数据管理复杂：另外，日志等信息，是历史态数据，需要长期保存。在腾讯公司每日对不同格式的、超过 150 亿条流水日志进行生成、存储、解析与管理等，这成为一个巨大的挑战。

现代的数据库系统只保留有数据的当前值，而因存储成本等原因，历史态数据被丢弃。而数据作为重要的资产，不管是当前数据，还是历史上曾经存在过的数据，都具有重要价值。因此，历史态数据存储、被分析、被挖掘、被反复使用，是当前互联网等企业的需求。尤其是金融类历史态数据，因为安全、需要被多次计算的原因，在腾讯公司的计费业务中，带有时态属性的数据被管理的需求日益旺盛。

业务痛点的解决，是基于数据库的特点和业务场景进行深入分析和思考而得以解决的。

因为数据有价值，所以 TDSQL 团队认为：历史数据富有价值。这是 TDSQL 时态数据库 T-TDSQL 的核心价值观。因此，我们给出了 TDSQL 对于数据的新的认识。

TDSQL 认为：

数据的状态属性，标识数据的生命周期轨迹。数据的生命周期分为三个阶段，每个阶段刻画数据的不同状态属性，以标识数据的生命周期轨迹中所处的状态。

1. 当前态（Current State）：数据项的最新版本的数据，是处于当前阶段的数据。处于当前阶段的数据的状态，称为当前态。

2. 历史态（Historical state）：数据项在历史上的一个状态，其值是旧值，不是当前值。处于历史阶段的数据的状态，称为历史态。一个数据项的历史态，可以有多个，反映了数据的状态变迁的过程。处于历史态的数据，只能被读取不能再被修改或删除。

3. 过渡态（Transitional State）：不是数据项的最新的版本也不是历史态版本，处于从当前态向历史态转变的过程中。处于过渡态的数据，称为半衰数据。

这三个状态，涵盖了一个数据项的生命周期，合称为数据全态（full-state），或称为全态数据。在 MVCC 机制下，数据的三种状态均存在；在非 MVCC 机制下，数据只存在历史态和当前态。

1. 当前态：MVCC 或封锁并发访问控制机制下，事务提交后的数据的新值处于当前态。

2. 历史态：MVCC 机制下，当前活跃事务列表中最小的事务之前的事务生成的数据，其状态处于历史态。在封锁并发访问控制机制下，事务提交后，提交前的数据的值变为历史态的值，即数据项的旧值处于历史态。

3. 过渡态：MVCC 机制下，被读取的版本上尚有活跃事务（非最新相关事务）在使用，因最新相关事务修改了数据项的值，其最新值已经处于一个当前态，被读取到的值相对当前态已经处于一个历史状态，故其数据状态介于当前态和历史态之间，所以称为过渡态。

数据的双时态属性，分别为有效时间属性、事务时间属性。

有效时间属性表示数据表示的对象在时间属性上的情况。如 Kate 中学起止时间是 2000-09-01 到 2003-07-30，而大学起止时间是 2003-09-01 到 2007-07-30，这里的时间就是有效时间。

事务时间属性表示数据的某个状态的时间发生时刻。数据具有其时态属性，即在何时数据库系统进行了什么样的操作。某项操作在数据库系统内被封装为事务，而事务具有原子性。因此，我们采用了事务标志来标识一个数据的事务时态属性。

从形式上看，有效时间属性和事务时间属性，在数据模型中用普通的用户自定义字段进行表示，只是用特定的关键字加以描述，供数据库引擎进行约束检查和赋值。

TDSQL 团队期望，构建一个数据库系统，解决如上问题，新系统应该提供的特性如下：

因此，基于 TDSQL 的 T-TDSQL 时态数据库，有了如下的特性，这些特性，能够涵盖双时态的数据应用、数据安全、数据分析、简化应用开发等四大方面的问题：

三、T-TDSQL 的核心技术

T-TDSQL 的核心技术之一，是数据模型的定义，全态数据模型和双时态数据模型的结合，造就了 T-TDSQL。

1.T-TDSQL 的核心技术一，数据模型

在这个模型中，全态数据体现在了数据项的历史版本上；时态数据不仅有事务时态、还有有效时间时态。而全态数据的历史态数据，不仅可以追溯数据库系统的操作发生时间，还可以追溯发生的操作类型，如下图中的“Operation”列，可以知道在数据项上曾经发生的 DML 操作是 UPDATE 还是 INSERT 还是 DELETE。这是一个非常酷的特性，这使得用户在 T-TDSQL 系统中可以实现“一切过往兼可追溯”的梦想。

2.T-TDSQL 的核心技术二，历史数据转储时机

历史数据的存储时机，是 T-TDSQL 的另外一个核心技术。

T-TDSQL 用全态的数据概念，巧妙地利用 MySQL 的回滚段和 Purge 机制，实现了历史态数据的转储。

3.T-TDSQL 的核心技术二，一致性快照点

在 PostgreSQL 中，如果实现本技术，可以考虑结合多版本的存储特点，实现当前态数据与历史态、过渡态的存储分离，这需要修改已有的数据可见性判断算法、页面存储格式、数据的合并时机、缓冲区的读写和 heap 的构造方式等，更重要的是要实现新的数据一致性快照点。

而 T-TDSQL 基于 MySQL 实现了新的数据一致性快照点的构建，因而可以获取任何时间段（包括历史发生过的时间）上的任何状态的数据。

作为原创技术，T-TDSQL 的核心技术点及其思路，相关论文已经在 World Wide Web journal 上以题为《Efficienttime-interval data extraction in MVCC-based RDBMS》发表，详情可参见：

https://link.springer.com/article/10.1007/s11280-018-0552-7

四、T-TDSQL 的典型应用

时态信息处理已经成为许多新一代数据库与信息系统的关键技术，特别是在金融领域 、电子商务、数据仓库、地籍管理系统、土地利用规划系统、地理信息系统中扮演着日益重要的角色。

电子商务、金融业务系统中，存在大量的收入、支出、余额等数据，并且随着业务的推进，新数据源源不断地产生，这些数据将在对账、审计、用户画像等业务中发挥重要作用。通过实现事务时态功能，T-TDSQL 能快速、精细、实时地获取这些数据。

在互联网金融业务中，对账业务是一个经典的业务。

T-TDSQL 为腾讯的计费对账业务提供了完美的解决方案。

1.对账业务

互联网金融行业对数据的准确性要求极高，而在互联网环境中，数据不一致或数据错误时有发生，因此，通过对账来降低账户余额等数据错误造成的风险十分重要。

在腾讯计费业务中，采用将账户余额表(user)和账户流水表(water)按小时/天为周期进行比对的方式，来发现账户余额与交易流水的不一致现象，从而及时对错误交易进行修正。

传统的对账采用按固定时间段（如分钟/小时/天）为单位进行对账。如现对 2018 年 4 月 11 日的交易进行对账，首先需要得到 4 月 11 日期初账户余额表和期末账户余额表，以及当天的交易流水表；然后对账户表通过按用户 ID 分组，并计算每个用户的期末余额减去期初余额，记为结果 A，对流水表按用户 ID 分组，并将交易金额分组求和，记为结果 B；最后将每个用户的结果 A 和结果 B 进行比对，如果 A=B，则交易没有问题，否则该用户在当天的交易存在错误。

对于按固定时间段对账，主要存在以下三个问题：

1. 时效性差：对于错误交易，不能立即发现并反馈，延迟了以固定时间段为单位的一段时间后才能发现错误。

2. 对账不精准：定位错误交易较复杂。例如：如果用户在一天内发生的多笔交易，其中一笔出现了错误，通过按天对账的方式不能直接定位到具体的哪条交易出现错误，而只能定位到用户级别，即仍然需要人工参与，将该错误用户的当天交易都确认一遍，才能找到具体的错误交易。

3. 对账不灵活：按固定时间段对账，如以天为单位，则只能等这一天内的增量数据沉淀下来，才能进行对账，如果有跨天对账需求（如昨天下午至今天上午），对账所用数据需要跨多个表才能执行，这可能改变对账业务的流程。

2.对账优化

基于本文提出的数据模型和增量计算方法，可以很好的解决按天对账所存在的问题。结合 3.1.2 中的示例，我们给出在互联网金融的对账业务中，增量计算的实际应用。

T-TDSQL 可以基于增量计算的功能将账户余额表(user)和账户流水表(water)进行精准比对，进行流水级别的细粒度对账，从而即时发现交易错误，并可以立即定位到错误的那一条交易，省去繁杂的错误交易定位过程。

优化后的对账的核心思想是：总账算摘要、细账笔笔精。

优化后的对账的效果是：总账快对、细账精确、不受时限、任意对账[1]。

对账步骤 1—总账对账：首先读取给出对账时间段[s_start,s_stop]内的所有账户表数据块，对每个数据块内数据采用与传统对账方式类似的公式来确认账户情况，即进行“总期末余额-总期初余额=总交易变动”试算[2]，总期初余额代表 s_start 时的总余额，总期末余额代表 s_stop 时的总余额，总交易变动代表每块内账户对应产生的流水，如果有数据块内的总账不平，意味着有细账错误，因此要进行步骤 2、3 所描述的精准对账。

3.有效时间的时态类应用基于 T-TDSQL 的全时态核心技术，本次分享还从双时态的角度对典型应用做了介绍。如下图所示。

4.数据安全类应用

基于历史状态查询这一特性，T-TDSQL 系统在数据订正、历史追踪等方面，提供灵活强大的数据安全保障功能，可以大大简化和加快审计、对账等业务。

查询时间段内插入的数据，用于数据统计和追踪，如统计新开账户、异常记录何时被添加等。

查询时间段内删除的数据，在安全保障和数据统计等方面作用显著，如恢复误删的数据、统计销户人数等。

查询时间段内更新的数据，能够追踪数据异常的发生时间和发生异常前的数据，用于数据异常的修复。

综合查询所有状态的历史态数据，在数据重演方面，可以辅助灾后恢复，或用于线下演练；数据统计方面，因支持任意时空节点的数据计算，对对账等业务大有裨益；安全保障方面，简化了错误数据、误删数据的追踪和恢复。

除此之外，基于全时态态数据，实现数据重演、更有价值的数据分析和挖掘、使用 AI 技术对系统自动调优等成为可能。

五、T-TDSQL 的核心理念，为数据赋能

为什么 T-TDSQL 要去实现全时态数据库？

原创技术的背后，是什么在驱动着 T-TDSQL 团队做出这样的一个全时态数据库系统？

这些问题，其实更为重要。挖掘这些问题的原因，为倡导原创而努力，当是 TDSQL 团队致力于技术分享时更看重的价值因素。

在 TDSQL 团队看来，“数据富有价值，历史数据富有价值”。在业务当中，挖掘数据的价值是非常重要的一环，这也是很多人在思考的内容，认为任何数据都有价值是很有意义的。

因此，T-TDSQL 项目的思考之后的观点是“Historical data are valuable. Business is a sword, Technology is only ashield.”。那么，什么是盾？什么是剑？盾和剑之间有什么关系呢？

在 TDSQL 看来，技术只是一个防守工具，用于把梦想变成现实。梦想是技术人想利用各种高大上、高精尖的技术解决现实问题的美好愿景，诸如分布式、一致性、快照、RDMA、NVM、AI、全数据挖掘等各种技术的炫酷使用。业务只是一个进攻的工具，用于发现梦想。TDSQL 并不倡导业务为王的观点，而是左手盾右手剑，两手都要硬。但仅是左手盾右手剑，行走在技术的江湖，这只能成就技术人行侠仗义的梦想。其背后，还缺少灵魂的支柱。

而历史数据富有价值，在（金融/腾讯/互联网/一切…）业务中，挖掘数据的价值，更是富有意义。

但是，百尺竿头更进一步。

数据的创造是由用户和其业务决定的，他们是创造数据的甲方。数据库承载了数据的管理职责，是否数据库系统也可以参与到数据的创造环节中来呢？

在 TDSQL 团队看来，全时态这一概念，正是数据库系统参与到数据创造环节的最佳契机。数据库系统为数据赋于了事务时态、赋于了 DML 操作过程中的事件源，甚至可能为数据之间赋于关联关系（如下图中的 5W、Lineage），这使得数据库系统也成为了数据的创造者。

这就是我们、TDSQL 团队在技术和业务背后的驱动要素：“为数据赋能”的理念。