基於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功能，這樣可以有效節省資料歷史狀態的儲存成本。