TDSQL 全时态数据库系统 -- 典型案例

本文大纲:

  • 经典案例
  • 增量计算
    • 对账业务
    • 对账优化
  •  安全
    • 联机闪回
  • 业务分析
    • 数据重演
    • 数据分析

经典案例

增量抽取、增量计算等都是T-TDSQL的经典案例。如下以增量计算为例,来分析T-TDSQL在腾讯金融业务中的典型应用。

增量计算

基于T-TDSQL全时态数据存储的特性,我们可以方便的进行增量式的数据查询、抽取和计算。

对于单表的数据增量抽取/计算[1],T-TDSQL首先通过快照差读方法,获取对应与给出快照范围的增量数据集,然后根据用户定义的计算规则,组合调用系统内置的聚集函数,如SUM,AVG,GROUP BY等,实现增量计算的功能。历史上任何时间段内的的数据都可以通过增量计算的技术进行“增量抽取”。

对于多表增量计算,T-TDSQL通过“快照差连接”支持增量计算场景。即首先得到两个快照差集合R和S,然后通过连接操作将两表合并,之后再使用聚集函数等完成计算。

本节通过在互联网金融中常用的对账业务来对增量计算的原理和实际应用进行介绍。

对账业务

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

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

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

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

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

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

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

 对账优化

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

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

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

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

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

对账步骤2—精准对账—对账过程:执行如下SQL,将账户余额块和对应账户流水块进行“快照差连接”,返回结果集中每条记录将含有{交易前余额,交易后余额,交易变动}。

对应的执行效果图如图13所示:

SELECT * FROM

(

User READVIEW START s_start TOs_stop as A ORDER BY User_id, Init_trx_id DESC

FULL OUTER JOIN

User READVIEW STARTs_start TO s_stop as B ORDER BY User_id, Init_trx_id DESC

ON A.trx_id= B.init_trx_id

)

FULL OUTER JOIN

Water READVIEW START s_start TO s_stop as C ORDER BYUser_id, Trx_id DESC

ON C.trx_id = A.trx_id

图13 精准对账示意图

对账步骤3—精准对账—精准之意:对步骤2结果里的每一条返回记录进行“交易后余额-交易前余额=交易变动”的试算[3](After-Before=Change),即可确认交易是否有误。如果有不满足此等式的情况存在,即为错误交易。

错误交易主要分为账户表错误和流水表错误两种。例如,图13中,结果集中第2条元组,不满足试算公式,表明流水ID为2的交易进行了错误的帐户余额更新或流水记录的交易变动值出错。结果集中的第4条元组,Change字段的值为NULL,代表该条交易的流水缺失。通过下表,我们对各种错误情况进行总结,这些错误,都需要在对账过程中进行报警。

表2  精准对账错误对照表

Before

After

Change

对账结果

M1

M2

M2-M1

正确

M1

M2

NULL

流水缺失

M1

M2

(M2-M1)’

流水记录有误

NULL

NULL

M3

流水误增

M1

M2’

M2-M1

账户表更新有误

M1

NULL

M2-M1

账户表没有更新

NULL

M2

NULL

账户表误增元组

安全

T-TDSQL中有一个逻辑结构“UNDO SEGMENT”,用于撤销数据即存放反转DML语句结果所需的信息,只要某个事务修改了数据,那么更新前的原有数据就会被写入一个撤销段。

而T-TDSQL实现了全时态数据管理,基于历史态和存于“UNDO SEGMENT”的过渡态数据,实现了历史上任何时间点上的数据闪回功能。

联机闪回

T-TDSQL提供联机的数据闪回,可以查询过去某个时间段的数据库状态。

而读取数据库的过去某个时间点的数据状态(历史态被储存而不是被清理),依据的是4.1.1节提及的三种快照读操作。这是闪回实现的原理。

基于此原理,实现了多种类型的联机闪回功能,包括:闪回查询,闪回删除,闪回归档。

1. 闪回查询:可以查询过去某个时间段的数据库状态,可将某个表回退到过去某个时间点。

2. 闪回删除:闪回删除可以将一个已经被Drop的表还原。相应的索引也会被还原(索引的还原是通过重建的方式进行)。

3. 闪回归档:闪回数据归档可使表具有回退到过去任何时间点。

业务分析

时态数据的双时态特性、全态属性、LineAge特性,以及在数据项上可识别发生的操作的特性等,为数据项赋予了5W的潜能。

5W是指:

1.原因(何因Why):数据挖掘和分析的目标。

2. 对象(何事What):数据项上执行了什么操作,数据变化因何而起(LineAge)。

3. 地点(何地Where):数据项的存储位置。

4. 时间(何时When):双时态属性。

5. 人员(何人Who):用户和数据项进行关联,在事务属性项上建立与用户UID标识的关联。

有了这5W的潜能,基于数据项和其历史,利用AI技术和全数据挖掘技术,可以进行无限想象力的数据分析。这是一个数据分析的新天地。

根据历史数据负载等情况用AI对系统进行细粒度地、带有峰值(预测峰值时段压力)和资源(资源自动配给)特性的调优。

多维分析全数据挖掘技术,可以对以多维形式组织起来的数据进行上卷、下钻、切片、切块、旋转等各种分析操作,以便剖析数据,使分析者、决策者能从多个角度、多个侧面观察数据库中的数据,从而深入了解包含在数据中的信息和内涵,透视未来。比如,实施上卷操作评估整体情况,实施下钻操作追查操作细节,为系统的监控和调优等打下基础。

数据重演

T-TDSQL提供数据重演的能力。

历史态数据存储,全时态数据中带有事务时间,基于这两点,可以分析数据的演变情况和某个时间点的事务发生情况,从而推演数据库在时间轴上的演进情况。

从数据推断应用的负载、推断数据的演化进程,是数据重演的意义所在。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, PengchengFan. The Art of Database Transaction Processiong: Transaction Management andConcurrency Control. 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 Insidea Database Engine. ICDE 2006: 35

[1]不受时限、任意对账:对账的SQL语句中指定快照差即可,FROM子句中涉及的表名等不发生变化,即对账使用的数据源没有改变,故不影响对账流程。

[2]试算(Spreadsheet)为会计程序中其中的一个流程,它简单的定义就是在检查日记簿的所有交易分录的借方、贷方金额是否有错误之情形。但是在做试算检查时,应每笔交易分录纪录后即做此一动作。

[3]试算(Spreadsheet)为会计程序中其中的一个流程,它简单的定义就是在检查日记簿的所有交易分录的借方、贷方金额是否有错误之情形。但是在做试算检查时,应每笔交易分录纪录后即做此一动作。

原文发布于微信公众号 - 腾讯技术工程(Tencent_TEG)

原文发表时间:2018-06-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(54)-SD-现金销售

前面讲过对信用度低的客户,可以采用现金销售,一手交钱,一手交货。另外就是对紧俏物资的销售,也可以采用现金销售,甚至要预付款。 SD 238现金销售订单 目的: ...

2513
来自专栏大数据和云计算技术

技术专栏丨2018 存储技术热点与趋势总结

类型:技术专栏 作者介绍 张凯(Kyle Zhang),SmartX 联合创始人 & CTO。毕业于清华大学计算机系,研究方向为分布式系统和体系结构。2013...

3708
来自专栏本立2道生

Data Warehouse

联机事务处理(OLTP, online transactional processing)系统:涵盖组织机构大部分的日常操作,purchasing, inven...

391
来自专栏数据和云

千头万绪:从一道面试题看数据库性能和安全的方方面面

这个问题在朋友圈引起了很多朋友的兴趣,转发并且提问,希望有一个标准答案输出作为参考。

541
来自专栏CSDN技术头条

漫谈千亿级数据优化实践:一次数据优化实录

即使没有数据倾斜,千亿级的数据查询对于系统也是一种巨大负担,对于数据开发来说,如何来优化它,既是挑战,也是机遇!

33710
来自专栏程序员互动联盟

【编程基础】聊聊C语言-存储世界的奥秘

上一篇讲到了C语言的数据类型,从这篇我们开始讲讲与数据类型有这着千丝万缕联系的变量。 所有语言的变量都是存储在计算机存储系统中,C语言的变量当然也不例外。所以...

3457
来自专栏EAWorld

生成全局唯一ID的3个思路,来自一个资深架构师的总结

标识(ID / Identifier)是无处不在的,生成标识的主体是人,那么它就是一个命名过程,如果是计算机,那么它就是一个生成过程。如何保证分布式系统下,并行...

3316
来自专栏大数据

快速数据管道设计:通过交换表更新各个事件决策

在 VoltDB(这是一种数据库) 经常使用到的术语,快速数据管道(Fast data pipeline),这是一种全新的现代应用程序 —— 这种应用程序将流式...

1747
来自专栏数据和云

Thinking in SQL系列之:供需分配问题

编辑手记:SQL做为一种编程语言,能够满足各类数据处理的需要,关键就在于算法与思维方式。以SQL会友,希望结交更多的数据库、数据分析领域的朋友。 推荐阅读: T...

3239
来自专栏大数据和云计算技术

新数仓系列:HBase关键能力和特性梳理

最近看一本书,铃木敏文的《零售的哲学》,里面提到一个很有意思的观点,711核心使命是提供便利,围绕便利场景,提供一系列食品、ATM服务等,而不是和超市去PK货物...

3134

扫码关注云+社区