炼数成金 门户 大数据 Nosql 查看内容

TDSQL 全时态数据库系统-理念与愿景

2018-6-6 10:29| 发布者: 炼数成金_小数| 查看: 9536| 评论: 0|原作者: 李海翔|来自: ITPUB

摘要: T-TDSQL是基于TDSQL的一个分布式全时态数据库。其特点是可扩展、多版本事务管理、分布式存储和计算、强数据一致性和强同步机制,且提供有效时间、事务时间双时态的全态数据存储、管理、计算。另外,基于MVCC技术描述 ...

管理 数据库 SQL 存储 数据库系统

目  录
1 Abstract

2 Introduction. 
  2.1  研究动机... 
  2.2 TDSQL整体架构... 
  2.3  TDSQL对时态数据库的需求... 
  2.4 T-TDSQL核心技术与系统的价值... 
  2.5 T-TDSQL解决了的问题... 

Acknowledgments

References

1、Abstract
TDSQL是腾讯公司研发的一款事务型分布式数据库。

T-TDSQL是基于TDSQL的一个分布式全时态数据库。其特点是可扩展、多版本事务管理、分布式存储和计算、强数据一致性和强同步机制,且提供有效时间、事务时间双时态的全态数据存储、管理、计算。

这篇文章描述了T-TDSQL的架构、双时态特性集,以及全双时态设计思考点和决策的因素。另外,基于MVCC技术描述了一种“全态数据可见性判断算法/历史态数据可见性判断算法”,这种算法能够读取到全态/历史态数据和其上发生的操作,这是T-TDSQL全时态数据库系统实现的关键算法。另外,T-TDSQL支持多种强大的特性,诸如:无阻塞读历史态数据、无锁只读事务、增量抽取、增量计算、全时态一致性快照等。

全时态数据库T-TDSQL核心价值观是:历史数据富有价值。

全时态数据库T-TDSQL核心理念是:为数据赋能。

2、Introduction
2.1 研究动机
腾讯公司的计费业务系统,是世界上领先的金融云计费业务系统。这个系统包括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关系型数据库研发了时态数据库 T-TDSQL,由数据库系统统一管理海量的全时态数据、当前数据,解决了上述四个业务中的问题。

2.2TDSQL整体架构
TDSQL是腾讯公司基于MySQL/InnoDB实现的一个可扩展的分布式数据库,支撑了腾讯公司如2017年的2377.6亿人民币的金融计费业务。

TDSQL整体架构如图1,采用SHARDING技术把逻辑表转换为不同物理实例上的子物理表,从而提供了数据分布的功能。每份数据为一个SET,一个SET内存在多个副本,副本间通过TDSQL的强同步技术实现数据强一致。SET中的数据可以线性扩容。节点失效通过ZooKeeper进行管理[2],并提供了两种节点级、Server级数据恢复技术。跨节点的写事务通过XA接口和2PC技术实现分布式事务对数据操作的原子性、一致性。

图1中的TSI部分,体现了T-TDSQL全时态数据库在存储层面对于TDSQL的创新与扩展,通过统一的数据管理接口,以满足对海量的历史态数据进行存储、管理。历史态数据的计算,则体现在图1的SQL计算层。详情参见第三、四章。


图1 T-TDSQL架构图

2.3TDSQL对时态数据库的需求
基于TDSQL数据库构建的金融计费业务,存在如上的问题外,还有一些时态需求,如金融监管部门或一位内部审计人员要求计费部门报告在过去5年内一家客户的金融账户所做的更改。

常规的解决办法,是按业务特点存储若干年流水日志数据,当需要时,把5年内的这些流水日志数据读取,从中过滤出特定客户的历史态数据。

显然,当需要个别用户的历史态数据,要过滤大量非相关用户的数据,会浪费大量的计算资源和时间,数据的检索方式原始且低效。

而我们期望,构建一个数据库系统,解决如上问题,新系统的核心价值观是“历史数据富有价值”,新系统应该提供的特性如下:
1.   全时态数据模型。能在数据库系统内统一管理数据的生命周期,即一个数据的诞生、修改、消亡的全过程、过程中的状态变迁操作的动作都能被一个数据库系统管理;也能按照对象的时间属性对对象进行管理和检索。如此,需要一个数据模型对数据进行管理。在3.1节讨论了全时态数据模型这个问题。

2.   全时态数据存储。现有的数据库系统,只能保存数据的当前状态值(当前态数据)。实现了MVCC技术的数据库,能在有限时长的时刻内保存尚被活跃事务使用的旧版本数据(过渡态数据)。但不再被活跃的事务操作的旧版本数据(历史态数据)被清理了,所以保存历史态数据是一个需要解决的问题,在3.2节讨论了如何存储历史态数据,并根据数据的特点提供了行存、列存等多种存储格式。4.3节讨论了如何构建合适的索引以助高效读取历史态数据。数据的有效时间状态的存储和管理(T-TDSQL提供了有效时间时态属性),类似普通列,4.4节讨论。

3.   全时态数据管理。数据一旦转变为历史态数据,就只具有归档的价值不可再更改。而历史态数据的数据量越来越大后,单机不能够容纳,存储海量历史态数据也将变为挑战。所以4.5节讨论了时态数据的常规管理如备份恢复等、4.6节讨论了海量的历史态数据如何集群化管理的问题。

4.   全时态数据计算。历史态数据存储在现有的数据库系统中,基于现有的MVCC技术是不能够读取到历史态数据的,如何历史态数据读取是一个历史态数据可见性判断的问题,在4.3节对这个问题进行了描述[1]。第4.3节讨论了如何利用索引高效读取历史态数据。
这些特性的实现,践行了“历史数据富有价值”,是的历史数据能够被存储、管理、参与到计算当中。

2.4T-TDSQL核心技术与系统的价值
TDSQL Temporal Database SystemOf The Tencent,简称T-TDSQL。

T-TDSQL是腾讯公司基于上节需求实现的一个带有双时态特征的分布式数据库系统。
其核心思想,是利用MVCC技术,确保数据库系统中有数据的旧版本,然后在系统清理旧版本数据的时刻,把将被清理的数据存储而不是被清理,从而实现了历史态数据的存储。

之后根据腾讯公司提出的“历史态数据可见性判断算法”、基于索引高效地读取历史态数据,从而使得获取历史态数据时只访问特定范围的数据而提高查询效率。

基于数学中集合对称差的原理的“历史态数据可见性判断算法”(4.1.1节),提出了快照差的概念和元组的历史态版本可见性算法,可读取任意历史时间段的历史态数据。
当历史态数据可读取时,基于历史上任何一个时间点T,可求出此时节点之后的任意一个时间段内相对于时间点T的数据的变化情况,如新插入的数据、连续被更新的数据、以及被删除的数据,并能识别出针对数据的操作动作是插入、更新还是删除。如此能追踪数据的历史轨迹,并能方便获取基于时间点T之后任意时间段的增量数据,还能在增量数据的基础上进行多表连接的增量计算。

数据库中存储有数据的历史状态信息,数据的安全性得到保证。防止篡改数据、数据误删除的恢复、账户变化轨迹追踪、回溯历史时空里的“过去的”数据等,在T-TDSQL中成为现实。

数据库中存储有数据的历史状态信息,基于历史上任何一个时间点T,可求出此时节点之后的任意一个时间段内相对于时间点T的数据的变化情况,使得基于日志、触发器等开发方式获取数据的变迁流水和增量数据等传统的开发方式,成为过去。

T-TDSQL存储、管理海量历史态数据、当前数据,使得随时都可以获取任何时间段的数据,因而流水日志不再重要。基于索引检索历史态数据时如同基于索引检索当前数据一样的方便快捷且消耗最少量的计算资源,这对于审计、安全、档案等部门有帮助。

T-TDSQL方便获取增量数据使得基于触发器或日志方式进行数据同步的系统以实现ETL、OLAP等应用开发变得简单,基于MVCC的历史态数据获取技术不会有读-写、写-读阻塞,因而数据读取的效率很高。

根据业务特点,T-TDSQL提供了两种历史态数据的存储方式,一个是行存、一个是列存,使得基于T-TDSQL的OLAP系统成为现实,且计算高效。T-TDSQL结合诸如Spark下推、列存等机制,能有效地支持“数据在生命周期范围内的联机分析”而不仅仅是“基于当前状态值的联机分析”。

T-TDSQL存储、管理海量历史态数据,分为两个层面:第一,不仅受限于单机系统的存储能力,其支持分布式网络文件系统以支持单机无限数据量的存储。第二,数据可以从单机系统脱机,然后联机到一个集群计算系统,把多个单机的海量数据聚集到一个集群中,并支持在集群中进行计算。

T-TDSQL不仅是存储、管理了历史数据,而且还参与到了“创造数据”的环节中,为数据赋予了事务时态、与用户的关联关系等,甚至还可以创造数据之间的关联关系以实现Data Lineage等。

富有价值的全时态数据存储在数据库中,为数据安全、数据重演、数据挖掘和AI技术的施展提供了物理基础。

总结T-TDSQL的特点,可以概括为:一切过往(数据的历史和状态)兼可追溯。

2.5T-TDSQL解决了的问题
T-TDSQL基于TDSQL,所做的功能增强如表1所示,主要使用于金融、保险、预订系统、决策支持、安全等领域。
 
表1 T-TDSQL功能对比(√数据库原生支持;û不支持;?通过配套工具支持)

Acknowledgments
本项目在腾讯TEG计费平台部立项,研究内容和实现过程得到中国人民大学信息学院教育部数据工程和知识工程重点实验室和腾讯公司的参与和支持,特别向项目参与人、支持者致谢。

References
[1] Haixiang Li et al. “EfficientTime-interval Data Extraction in MVCC-based RDBMS”. World Wide Web Journal. 2018, pp.922–933.
[2] 姜晓轶 蒋雪中 周云轩 时态数据库研究进展 计算机工程与应用 2005
[3] Dharavath Ramesh, Chiranjeev Kumar: A Scalablegeneric transaction model scenario for distributed NoSQL databases. Journal ofSystems and Software 101: 43-58 (2015)
[4]汤庸 时态数据库导论 2004
[5]Haixiang Li, Yi Feng, Pengcheng Fan. The Art ofDatabase Transaction Processiong: Transaction Management and ConcurrencyControl. First edition. Beijing. China Machine Press. 2017-10-01
[6]David B. Lomet, Roger S. Barga, Mohamed F. Mokbel, German Shegalov, Rui Wang,Yunyue Zhu: Transaction Time Support Inside a Database Engine. ICDE 2006: 35

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2018-6-19 01:17 , Processed in 0.151362 second(s), 26 queries .