专栏名称: 腾讯云加社区
目录
相关文章推荐
正午故事  ·  被“电诈”PUA的高学历者们 ·  昨天  
三联生活周刊  ·  福建没有的“福建面”,成了这座城的顶流小店? ·  2 天前  
新周刊  ·  为什么成年后,毛绒玩具更重要了 ·  3 天前  
三联生活周刊  ·  给企业大佬写演讲稿的我,对“预制金句”过敏了 ·  3 天前  
51好读  ›  专栏  ›  腾讯云加社区

一个典型案例为你解读TDSQL 全时态数据库系统

腾讯云加社区  · 掘金  ·  · 2018-06-26 10:35

正文

一个典型案例为你解读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

img

图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技术和全数据挖掘技术,可以进行无限想象力的数据分析。这是一个数据分析的新天地。







请到「今天看啥」查看全文