タイムトラベル, 基本概念 - MaxCompute - Alibaba Cloud ドキュメントセンター

ユースケース

エラー回復：不正な書き込み、失敗したパイプライン、または偶発的な削除が発生する前の時点でテーブルをクエリし、その結果を使用して下流のデータを修正します。
履歴監査：コンプライアンスチェックやデータリネージの調査のために、過去のトランザクション境界におけるデータセットの正確な状態を検査します。
データ比較：2 つの異なる履歴バージョンのデータを比較し、処理実行間でレコードがどのように変化したかを把握します。
ポイントインタイムリストア：テーブル全体を特定の履歴バージョンにロールバックして、一連の変更を元に戻します。

前提条件

タイムトラベルは、トランザクションテーブルでのみサポートされています。非トランザクションテーブルおよび外部テーブルでは、この機能はサポートされていません。

履歴データは、設定された保持期間内でのみ利用可能です。履歴データを保持するには、acid.data.retain.hours テーブルプロパティを設定する必要があります。詳細については、「データ保持の設定」をご参照ください。

履歴データのクエリ

タイムスタンプによるクエリ

TIMESTAMP AS OF を使用して、特定の時点のテーブルを読み取ります。

-- 特定のタイムスタンプを使用してクエリを実行 SELECT * FROM src TIMESTAMP AS OF '2024-01-15 10:00:00'; -- 最後にコミットされたバージョンのタイムスタンプを使用してクエリを実行 SELECT * FROM src TIMESTAMP AS OF get_latest_timestamp(1);

get_latest_timestamp 関数は、遡るコミット数を示すパラメーターを 1 つ引数に取ります。get_latest_timestamp(1) は、最後にコミットされたバージョンのタイムスタンプを返します。

バージョン ID によるクエリ

VERSION AS OF を使用して、特定のバージョン ID を指定してテーブルを読み取ります。

-- 特定のバージョン ID を使用してクエリを実行 SELECT * FROM src VERSION AS OF 3; -- 最新のコミットから 2 つ前のバージョンのバージョン ID を使用してクエリを実行 SELECT * FROM src VERSION AS OF get_latest_version(2);

get_latest_version 関数は、遡るコミット数を示すパラメーターを 1 つ引数に取ります。get_latest_version(2) は、最新のコミットから 2 つ前のバージョンのバージョン ID を返します。

テーブルの履歴バージョンへの復元

RESTORE ステートメントを使用して、現在のテーブルの状態を履歴バージョンのデータで上書きします。この操作は元に戻せません。

-- 特定のタイムスタンプに復元 RESTORE TABLE src TO TIMESTAMP AS OF '2024-01-15 10:00:00'; -- 特定のバージョン ID に復元 RESTORE TABLE src TO VERSION AS OF 3;

トランザクションバージョンタイプ

タイムトラベルは、2 つのバージョンタイプをサポートしています：

バージョンタイプ	説明	SQL 句
時間バージョン	トランザクションをタイムスタンプで識別します	`TIMESTAMP AS OF`
ID バージョン	トランザクションを内部バージョン ID で識別します	`VERSION AS OF`

絶対値ではなく、最新のコミットに対する相対的なバージョンを参照する必要がある場合は、get_latest_timestamp と get_latest_version を使用します。これらの関数では、パラメーターを使用して最新のコミットから遡るコミット数を指定します。MaxCompute はこの値を使用して、対応する内部データバージョンを解決します。

データ保持の設定

acid.data.retain.hours テーブルプロパティは、履歴データの保持期間を制御します。ALTER TABLE を使用して設定します：

-- 保持期間を 48 時間に設定 ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '48');

最大保持期間は 7 日間 です。運用要件に合った値を選択してください。保持期間が長いほど、MaxCompute が履歴 Delta ファイルを保持する必要があるため、ストレージコストが増加します。

タイムトラベルを無効にしてストレージコストを削減するには、acid.data.retain.hours を 0 に設定します：

-- テーブルのタイムトラベルを無効化 ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '0');

このプロパティを 0 に設定すると、履歴データの保持が停止し、ストレージコストが大幅に削減されます。

仕組み

次の図は、トランザクションテーブルに対するタイムトラベルクエリの内部クエリプロセスを示しています。

タイムトラベルクエリを実行すると、MaxCompute は次の処理を行います：

SQL ステートメントを解析し、ターゲットバージョン (タイムスタンプまたはバージョン ID) を特定します。
そのバージョンの時間範囲内にある最新のベースファイルを特定します。
ベースファイルが生成された後、ターゲットバージョンまでに書き込まれた Delta ファイルを特定します。
ベースファイルと関連する Delta ファイルをマージして、クエリ出力を生成します。

例：トランザクションテーブル src

pk と val という列を持つ src という名前のトランザクションテーブルを考えます。t1 から t5 の時点で 5 つの書き込みトランザクションが実行され、5 つの Delta ファイルが生成されます。t2 と t4 でコンパクションが実行され、それぞれベースファイル b1 と b2 が生成されます。

t2 でのコンパクション中に、履歴の中間状態レコード (2,a) はベースファイル b1 から削除され、最新の状態レコード (2,b) のみが b1 に保持されます。

クエリ時点	読み取るファイル	結果
t1	Delta ファイル d1 のみ	d1 からの出力
t2	ベースファイル b1 のみ	3 つのレコード
t3	ベースファイル b1 + Delta ファイル d3	マージされた出力
t4、t5	ベースファイル b2 + 関連する Delta ファイル	マージされた出力

ベースファイルは、特定の時点でのテーブル状態をコンパクトにマージしたスナップショットを提供することで、クエリと読み取りの効率を向上させます。ただし、これらのベースファイルを作成するコンパクション操作は多くのリソースを消費する可能性があります。そのため、ワークロードに適したコンパクションのトリガーポリシーを選択することが重要です。

制限事項

タイムトラベルは、トランザクションテーブル (Delta テーブル) でのみサポートされています。非トランザクションテーブルおよび外部テーブルはサポートされていません。
設定された保持期間より古い履歴データは、クエリまたは復元の対象外となります。
acid.data.retain.hours の設定値にかかわらず、最大保持期間は 7 日間です。
acid.data.retain.hours を 0 に設定すると、タイムトラベルが無効になり、テーブルの履歴データは保持されなくなります。

MaxCompute:タイムトラベル