Iceberg テーブルの保持

Foundry の Iceberg テーブルでは、スナップショットの期限切れ処理と孤立ファイルの削除によって、データの保持とクリーンアップがサポートされています。これらの操作は、古いテーブル履歴を Iceberg メタデータから削除し、テーブルが継続的に更新される際のストレージ増加を抑えるのに役立ちます。このページでは、Iceberg のメンテナンスプロシージャを使用して、Foundry の個別のテーブルに保持を実装する方法を説明します。

スナップショットを期限切れにする

Iceberg テーブルに保持を実装する主要な仕組みは、expire snapshots メンテナンスプロシージャ ↗です。Iceberg テーブルへのデータの書き込みごとに、スナップショットが作成されます。スナップショットの期限切れ処理では、古いスナップショットがテーブルのメタデータから削除されます。スナップショットが期限切れになると、テーブルのスナップショット履歴に表示されなくなり、そのスナップショットへのロールバックやタイムトラベルはできなくなります。

スナップショットを期限切れにするメンテナンスタスクを設定する際は、テーブルで保持する必要がある履歴の量に基づいて保持設定を選択します。一般的な設定には、次のものがあります。

• 保持するスナップショットの最小数： 経過時間に関係なく、少なくともこの数の最新スナップショットを常に保持します。
• 保持する最小期間または時間ウィンドウ： より新しいスナップショットの数に関係なく、設定したウィンドウより新しいスナップショットを常に保持します。

スナップショットは、設定されたしきい値のいずれかを満たす場合に保持されます。たとえば、少なくとも3個のスナップショットと、少なくとも30日間の履歴を保持するように設定されたテーブルを考えます。このテーブルでは、より新しいスナップショットが多数存在していても、設定された履歴期間に基づいて10日前のスナップショットが保持されます。同様に、30日より前のスナップショットでも、最新の3個のスナップショットのいずれかである限り保持されます。

スナップショットの期限切れ処理は、該当する場合、Iceberg のブランチごとに独立して適用されます。たとえば、保持するスナップショットの最小数が 3 で、テーブルに2個のブランチがある場合、この設定により、ブランチごとに3個のスナップショットが保護されます。そのため、スナップショットの最小数の設定によって、重複のない2個のブランチ全体で最大6個の異なるスナップショットが保護される可能性があります。ブランチが削除されると、そのブランチだけで保護されていたスナップショットは、今後の保持処理の実行時に期限切れの対象になります。

また、タグ ↗を使用して、特定の古いスナップショットを期限切れから保護することもできます。

スナップショットを期限切れにする操作を使用する際は、次の点に注意してください。

• スナップショットを期限切れにする際は、慎重に操作してください。期限切れのスナップショットはテーブルのメタデータから削除され、ロールバックやタイムトラベルのために復元することはできません。下流のインクリメンタル（差分処理）コンシューマーも、変更の特定に古いスナップショットを使用している場合は影響を受ける可能性があります。
• スナップショットの期限切れ処理プロシージャでは、プロシージャで明示的に上書きしない限り、関連する Iceberg テーブルプロパティが適用されます。たとえば、プロシージャの引数 older_than と retain_last を指定しない場合は、テーブルプロパティ history.expire.max-snapshot-age-ms と history.expire.min-snapshots-to-keep が適用されます。

孤立ファイルを削除する

孤立ファイルとは、テーブルのストレージの場所に存在するものの、現在のテーブルメタデータから参照されていないファイルです。このメタデータには、期限切れになっていないすべてのスナップショットから参照されているファイルが含まれます。孤立ファイルは、書き込みの失敗、メタデータのクリーンアップ、または過去のスナップショットの期限切れ処理によって残ることがあります。

Foundry は、これらの古いファイルをクリーンアップするために、すべての Iceberg テーブルに対して孤立ファイルの削除を定期的に自動実行します。必要に応じて、メンテナンスタブから、テーブルに孤立ファイルを削除するタスクを手動で設定することもできます。

Foundry では、オープンソースの Iceberg の孤立ファイルクリーンアップとは異なり、設定された災害復旧のルックバックウィンドウ外にあるファイルだけを物理的に削除します。そのウィンドウ内のファイルは、現在のテーブルメタデータから参照されなくなっていても保持される場合があります。

ファイル削除の延期と災害復旧

Foundry の Iceberg 実装では、メタデータのクリーンアップと物理ファイルの削除を分離しています。これにより、Foundry の災害復旧手順に従って、期限切れ処理後も関連する孤立ファイルが短期間保持されます。

このため、Foundry の動作はオープンソースの実装と次の点で異なります。

• オープンソースの Iceberg では、スナップショットを期限切れにすると、通常、保持されているスナップショットから参照されなくなった物理ファイルも削除されます。Foundry でスナップショットを期限切れにする操作は、オープンソースの Iceberg と同様にテーブルメタデータからスナップショットを削除しますが、物理ファイルの削除は後日に延期されます。
• オープンソースの Iceberg では、孤立ファイルの削除によって、プロシージャで指定された older_than タイムスタンプより前のすべての孤立ファイルが削除されます。Foundry で孤立ファイルを削除する操作は、ユーザーが指定した older_than タイムスタンプより古く、かつ環境に設定された災害復旧のルックバックウィンドウより前にある孤立ファイルだけを削除します。

災害復旧バックアップが誤って無効になるのを防ぐため、Foundry が管理する Iceberg テーブルは、プロパティ gc.enabled=false が設定されているかのように動作します。これにより、災害復旧ウィンドウ内のファイルを削除する可能性がある標準の Iceberg 操作を、ユーザーが誤って実行することを防ぎます。

例とガイダンス

スナップショットは、追加、上書き、削除、およびコンパクションなどの置換操作を含む、Iceberg のコミットごとに生成されます。そのため、固定数のスナップショットを保持する設定では、テーブルのコミット頻度とコミットの種類によって、保持される実時間の履歴の長さが大きく異なる可能性があります。

ロールバックの要件、タイムトラベルに期待する動作、下流のインクリメンタルビルドの頻度、およびストレージ管理の目標に基づいて保持設定を選択します。下流のコンシューマーのビルド頻度が低い場合は、最後に処理したスナップショットと現在のテーブルの状態の間の変更を特定できるだけのスナップショット履歴を保持してください。

以下の2つの例では、最新の3個のスナップショットを保持するようにスナップショットの期限切れ処理を設定した場合に、どのような結果になるかを示します。

例1： 定期的にコンパクションを行う非インクリメンタルテーブルでは、テーブルの論理的に異なるバージョンを表さないスナップショットが蓄積することがあります。

例2： インクリメンタルテーブルで3個のスナップショットを保持すると、現在のテーブルと、直近2回の追加後の状態だけが保持される場合があります。各スナップショットは完全なテーブルの状態を表しますが、これだけでは、以前のテーブル全体の再ビルド時点や、その他の主要な論理バージョンに戻るための十分な履歴を保持できない可能性があります。