文档

TimeTravel

更新时间:

基于Transactional Table 2.0,计算引擎可高效支持TimeTravel查询的典型业务场景,即查询历史版本的数据,可用于回溯历史状态的业务数据,或数据出错时,用来恢复历史状态数据进行数据纠正,当然也支持直接使用restore操作恢复到指定的历史版本。

查询过程

Timetravel查询Transactional Table 2.0的处理过程如下所示。

image.png

当输入一个SQL语句后,引擎侧会解析出来要查询的数据版本,然后找到此版本时间范围内最近的BaseFile,再查找BaseFile之后写入的DeltaFile,进行合并输出,其中BaseFile可以用来加速查询读取效率。

上图以创建一张事务表(src)为例:

  • schema包含一个pk列和一个val列。左边图展示了数据变化过程,t1-t5代表了事务的时间版本,分别执行了5次数据写入的事务,生成了5个DeltaFile,在t2和t4时刻分别执行了COMPACTION操作,生成了两个BaseFile: b1和b2,可见b1已经消除了历史中间状态记录(2,a),只保留最新状态的记录(2,b)。

  • 如查询t1时刻的历史数据,只需读取DeltaFile: d1进行输出; 如查询t2时刻,只需读取BaseFile:b1 输出其三条记录。如查询t3时刻,就会包含BaseFile: b1以及DeltaFile: d3进行合并输出,可依此类推其他时刻的查询。可见,BaseFile文件虽可用来加速查询,但需要触发较重的COMPACTION操作,用户需要结合自己的业务场景选择合适的触发策略。

  • Timetravel查询设置的事务版本,支持时间版本和ID版本两种形态,SQL语法上除了直接指定一些常量和常用函数外,还额外开发了get_latest_timestampget_latest_version两个函数,第二个参数代表它是最近第几次commit,方便用户获取MaxCompute内部的数据版本进行精准查询,提升用户体验。

历史数据可查询的时间周期

Timetraval查询的数据历史状态需要被保存才能被查询,保存的时间周期可以通过表属性acid.data.retain.hours来配置,最大支持7天。建议用户按真实的业务场景需要来设置合理的时间周期,设置的时间越长,产生的存储费用就越多,如果用户不需要Timetravel查询,建议将时间周期设置为0,代表关掉timetravel功能,这样可以有效节省数据历史状态的存储成本。

  • 本页导读 (1)
文档反馈