基于Transactional Table 2.0，计算引擎可高效支持Time travel查询的典型业务场景，即查询历史版本的数据，可用于回溯历史状态的业务数据，或数据出错时，用来恢复历史状态数据进行数据纠正，当然也支持直接使用restore操作恢复到指定的历史版本。
查询过程
Time travel查询Transactional Table 2.0的处理过程如下所示。
当输入一个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操作，用户需要结合自己的业务场景选择合适的触发策略。
Time travel查询设置的事务版本，支持时间版本和ID版本两种形态，SQL语法上除了直接指定一些常量和常用函数外，还额外开发了get_latest_timestamp和get_latest_version两个函数，第二个参数代表它是最近第几次commit，方便用户获取MaxCompute内部的数据版本进行精准查询，提升用户体验。
历史数据可查询的时间周期
Time traval查询的数据历史状态需要被保存才能被查询，保存的时间周期可以通过表属性acid.data.retain.hours来配置，最大支持7天。建议用户按真实的业务场景需要来设置合理的时间周期，设置的时间越长，产生的存储费用就越多，如果用户不需要Time travel查询，建议将时间周期设置为0，代表关掉time travel功能，这样可以有效节省数据历史状态的存储成本。
- 本页导读 （1）