時間の経過に伴う変更を記録するテンポラル (履歴) テーブルを設計して実装する

多くの場合、データ パイプラインでは、現在の値だけでなく、時間の経過と同時に発生するすべての変更を追跡する必要があります。 テンポラル テーブルは、行レベルの変更を自動的に記録するメカニズムを提供し、ポイントインタイム クエリと完全な監査証跡を有効にします。 ビジネス データ履歴に焦点を当てた緩やかに変化するディメンションとは異なり、テンポラル テーブルでは、運用の追跡とデバッグのための技術履歴がキャプチャされます。

テンポラル テーブルと SCD タイプ 2 の比較

テンポラル テーブルと SCD タイプ 2 ディメンションは異なる目的で機能しますが、どちらも履歴の変更を追跡します。 各アプローチを使用するタイミングを理解することは、適切なソリューションを設計するのに役立ちます。

SCD タイプ 2 では、分析レポートの時間の経過と同時にビジネス エンティティに対する変更が追跡されます。 顧客がシアトルからポートランドに移行する場合は、各トランザクションの時点で顧客の場所に過去の売上を属性付けする必要があります。 SCD タイプ 2 では、明示的な開始日と終了日を使用して、ビジネスに意味のあるバージョンが保持されます。

テンポラル (履歴) テーブルは 、運用上のニーズに合わせて技術的な変更をキャプチャします。 データが正しく読み込まれていない理由をトラブルシューティングする場合は、各時点に存在していた値、処理されたファイル、および変更が発生したタイミングを正確に確認する必要があります。 テンポラル テーブルは、このフォレンジック機能を自動的に提供します。

次の必要がある場合は、テンポラル テーブルの使用を検討してください。

• 特定のタイムスタンプでテーブルの状態を調べることで、データ インジェストの問題をデバッグする
• コンプライアンスまたは規制要件に関するすべての変更を監査する
• 特定の時点からの分析またはレポートを再現する
• 読み込み時間やソース ファイル情報などの操作メタデータを追跡する

行レベルの追跡で変更データ フィードを有効にする

Delta Lake の変更データ フィードは、すべての行レベルの変更を自動的にキャプチャします。 有効にすると、ランタイムは、各行が挿入、削除、または更新されたかどうかを示すメタデータを含む変更イベントを記録します。 変更データ フィードは既定で無効になっているため、この機能が必要なテーブルで明示的に有効にする必要があります。

新しいテーブルで変更データ フィードを有効にするには:

CREATE TABLE bronze.sales_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DECIMAL(10,2),
    transaction_date TIMESTAMP,
    source_file STRING,
    load_timestamp TIMESTAMP
)
USING DELTA
TBLPROPERTIES (delta.enableChangeDataFeed = true);

既存のテーブルの場合は、 ALTER TABLE ステートメントを使用して変更データ フィードを有効にします。

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

テーブル履歴のクエリを実行する

変更データ フィードが有効になったら、変更履歴に対してクエリを実行して、変更が発生した内容を正確に確認できます。 変更データ フィードは、次の 3 つのメタデータ列をデータに追加します。

特定の時間範囲内の変更をクエリします。

SELECT 
    transaction_id,
    amount,
    _change_type,
    _commit_version,
    _commit_timestamp
FROM table_changes('bronze.sales_transactions', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

このクエリは、特定のレコードが変更された時期を特定するのに役立ちます。これは、データ品質の問題をデバッグするために役立ちます。

ポイントインタイム クエリにタイム トラベルを使用する

Delta Lake では、履歴内の任意の時点に存在していたデータに対してクエリを実行できるトランザクション ログが保持されます。 この機能は、現在のデータを以前の状態と比較する必要があるデバッグ シナリオをサポートします。

特定のタイムスタンプでデータを照会します。

SELECT * FROM bronze.sales_transactions
TIMESTAMP AS OF '2026-01-15 14:30:00';

特定のバージョンでデータを照会する:

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

テーブルに対して実行された操作の完全な履歴を表示するには:

DESCRIBE HISTORY bronze.sales_transactions;

履歴の出力には、各変更の操作の種類、タイムスタンプ、ユーザー、詳細なメトリックが含まれます。

長期的な監査のために変更履歴を保持する

Delta Lake の組み込みのタイム トラベルには保持制限があるため、長期的な監査要件のために変更データを別の履歴テーブルに保持する必要があります。 この方法では、すべての変更の永続的なレコードが作成されます。

構造化ストリーミングを使用して、変更を継続的にキャプチャします。

(spark.readStream
    .option("readChangeFeed", "true")
    .option("ignoreDeletes", "false")
    .table("bronze.sales_transactions")
    .writeStream
    .option("checkpointLocation", "/checkpoints/sales_history")
    .trigger(availableNow=True)
    .toTable("audit.sales_transactions_history")
)

readChangeFeed オプションは、変更データ フィードを読み取るよう Spark に指示します。これにより、挿入、更新、削除などの行レベルの変更イベントが返されます。 ignoreDeletes オプションは、削除操作をストリームに含めるかどうかを制御します。 falseに設定すると、削除レコードが履歴テーブルに確実にキャプチャされ、すべてのデータ変更の完全な監査証跡が提供されます。

履歴テーブルには、完全なメタデータを含むすべての変更イベントが含まれています。これにより、保持期間だけでなく、データの有効期間全体にわたってクエリが有効になります。

コンプライアンス要件の保持を構成する

コンプライアンスまたは規制のニーズをサポートするテンポラル テーブルの場合は、要件に合わせて保持設定を構成します。

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (
    delta.logRetentionDuration = 'interval 90 days',
    delta.deletedFileRetentionDuration = 'interval 90 days'
);

両方のプロパティを一緒に設定する必要があります。 logRetentionDurationは履歴メタデータを保持する期間を制御しますが、deletedFileRetentionDurationは削除されたデータ ファイルを削除するまでの保持期間VACUUM制御します。

保有期間が長いほどストレージ コストは増加しますが、時間の移動アクセスが長くなり、監査用のデータ フィードの可用性が変更されます。

テンポラル テーブルを適切に構成すると、インジェストから変換まで、データに対するすべての変更をトレースでき、運用デバッグと規制コンプライアンス要件の両方をサポートできます。