基于Delta Table，计算引擎可高效支持Time Travel查询的典型业务场景，即查询历史版本的数据，可用于回溯历史状态的业务数据，或数据出错时，用来恢复历史状态数据进行数据纠正，当然也支持直接使用restore操作恢复到指定的历史版本。
查询过程
Time Travel查询Delta Table的处理过程如下所示。
当输入一个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 Travel查询的数据历史状态需要被保存才能查询，保存的时间周期可以通过表属性acid.data.retain.hours来配置，最大支持7天。建议用户按真实的业务场景需要来设置合理的时间周期，设置的时间越长，产生的存储费用就越多。如果用户不需要Time Travel查询，建议将时间周期设置为0，代表关掉Time Travel功能，这样可以有效节省数据历史状态的存储成本。