VACUUM Delta テーブル

Delta Lake VACUUM コマンドを使用して、Delta テーブルによって参照されなくなったデータ ファイルと、保持しきい値より古いデータ ファイルを完全に削除します。

Fabricでは、VACUUMが更新、削除、マージ、コンパクト操作後のOneLakeの古いファイルの整理を支援します。 これにより、ストレージ使用量が削減され、Fabric がアクティブなテーブル状態のためにもはや必要としない古いファイルが削除され、OPTIMIZE などのメンテナンス操作後に領域が回収されます。

VACUUM は、オープンソースの Delta Lake と同じコア Delta Lake の概念に従いますが、ノートブック、Spark ジョブ定義、Lakehouse Maintenance UI などの Fabric Spark エクスペリエンスで実行します。

VACUUM によって削除される内容

Delta テーブルは、Delta ログの現在のテーブルの状態を構成するファイルを追跡します。 UPDATE、DELETE、MERGE、書き込みの上書き、圧縮などの操作によって、古い Parquet ファイルが新しい Parquet ファイルに置き換えられると、古いファイルが参照されなくなる可能性があります。

VACUUM は、これらの両方の条件が当てはまる場合にのみ、これらの参照されていないファイルを削除します。

• ファイルはデルタ ログによって参照されなくなりました。
• ファイルが、構成された保持しきい値より古い。

VACUUMは OneLake からファイルを完全に削除するため、古いテーブル バージョンが必要な場合は慎重に使用してください。

VACUUM が重要な理由

次の場合は、 VACUUM を実行します。

• OneLake から古いファイルを削除してストレージ コストを削減する
• 更新、削除、およびマージ操作後の領域の再利用
• OPTIMIZE が置換ファイルを作成した後、コンパクション前のファイルを削除する
• 実行時間の長い運用テーブルで不要な古いデータ ファイルが蓄積されないようにする

VACUUM では、圧縮やファイル レイアウトの最適化と同じように、クエリのパフォーマンスがそれ自体で向上することはありません。 その主な目的は、ストレージのクリーンアップです。

VACUUM を実行する場所

VACUUM は、Fabricの Spark コマンドです。 次のような Spark エンジンを使用する場所で実行します。

• Fabric ノートブック
• Spark ジョブ定義
• Lakehouse メンテナンス UI とパイプラインベースのメンテナンス ワークフロー

SQL分析エンドポイントやウェアハウスのSQLエディタで VACUUM を実行しないでください。 これらのエクスペリエンスでは、Spark Delta メンテナンス コマンドはサポートされていません。

ポータルベースのワークフローが必要な場合は、 Lakehouse テーブルのメンテナンスに関する記事を参照してください。

構文の例

Fabricで VACUUM を実行するときは、次の例を使用します。

既定の保持期間でテーブルに対して VACUUM を実行する

VACUUM schema_name.table_name

from delta.tables import DeltaTable

deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum()

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum()

カスタムの保持しきい値を使用してテーブルをバキュームする

VACUUM schema_name.table_name RETAIN 168 HOURS

from delta.tables import DeltaTable

deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum(168)

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum(168)

DRY RUN を使用してファイルをプレビューする

DRY RUNを使用して、実際に削除せずに削除されるファイルを一覧表示します。

VACUUM schema_name.table_name DRY RUN

RETAINとDRY RUNを組み合わせることもできます。

VACUUM schema_name.table_name RETAIN 168 HOURS DRY RUN

ライトモードでのバキューム

VACUUM LITE は、テーブル ディレクトリ内のすべてのファイルを一覧表示するのではなく、差分トランザクション ログのみを使用して参照されていないファイルを識別するより高速な代替手段です。 この方法は、多数のファイルを含む大きなテーブルの場合に大幅に高速です。

VACUUM schema_name.table_name LITE

VACUUM schema_name.table_name LITE RETAIN 168 HOURS

from delta.tables import DeltaTable

deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum(mode="LITE")

spark.sql("VACUUM schema_name.table_name LITE")

VACUUM LITE は、完全なディレクトリ一覧を実行するのではなく、デルタ ログを読み取って削除するファイルを識別します。 高速ですが、どのファイルが参照されていないかを判断するのに十分なログ履歴が必要です。 デルタ ログが LITE モードで必要な範囲を超えて排除されている場合は、 DELTA_CANNOT_VACUUM_LITE 例外が発生します。その場合は、標準 VACUUM (フル モード) にフォールバックします。

インベントリ テーブルを使用したバキューム

非常に大きなテーブルで、既定のVACUUMディレクトリ全体の一覧表示でも時間がかかる場合は、事前に計算されたファイル インベントリを指定できます。 実行時にテーブル ディレクトリを一覧表示する代わりに、 VACUUM は指定したインベントリからファイル パスを読み取ります。

VACUUM schema_name.table_name USING INVENTORY inventory_table_name

VACUUM schema_name.table_name USING INVENTORY (SELECT * FROM inventory_table_name WHERE path LIKE 'abfss://%')

spark.sql("VACUUM schema_name.table_name USING INVENTORY inventory_table_name")

spark.sql("VACUUM schema_name.table_name USING INVENTORY inventory_table_name")

インベントリ テーブル (またはクエリ) には、次のスキーマが必要です。

OneLake ファイル メタデータ、ストレージ アカウント インベントリ レポート、またはスケジュールに従ってテーブル ディレクトリを一覧表示するカスタム Spark ジョブから、インベントリ テーブルを設定できます。 これにより、コストのかかるファイル一覧の手順が VACUUM 操作自体から切り離されます。

既定のリテンション期間

保持期間を指定しない場合、 VACUUM は既定の保持期間である 7 日間 ( 168 時間) を使用します。

その既定の設定により、アクティブな読み取り処理、書き込み処理、およびタイムトラベル クエリに対して、古いファイルが削除されるまでのより安全な猶予期間が確保されます。

短い保持期間の安全性チェック

Delta Lake には、 spark.databricks.delta.retentionDurationCheck.enabledによって制御される保持安全チェックが含まれています。

7 日未満の保有期間を使用しようとすると、Spark 構成のチェックを明示的に無効にしない限り、この安全性チェックによって警告が表示されます。

このセーフガードを無効にする前に、特別な注意を払ってください。 短いリテンション期間では、同時実行ワークロードまたは復旧シナリオで必要なファイルを削除できます。

たとえば、次のコマンドは、1 日の保持期間を要求します。

VACUUM schema_name.table_name RETAIN 24 HOURS

from delta.tables import *

deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum(24)

import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "schema_name.table_name")
deltaTable.vacuum(24)

環境で安全性チェックが有効な状態を維持している場合、ランタイムは 7 日未満のリテンション設定について警告します。

タイム トラベルへの影響を理解する

Delta Lake Time Travel を使用すると、必要な履歴ファイルがまだ存在する限り、古いテーブル バージョンに対してクエリを実行できます。

VACUUM は、保持期間よりも古いファイルを削除するため、その期間を超えて移動するために必要なデータ ファイルも削除されます。 これらのファイルがバキュームされた後は、古いバージョンに対してクエリを実行できなくなります。

リテンション期間を短縮する前に、ワークロード、監査、デバッグ手順、および復旧プロセスに必要な履歴アクセスの量を決定します。 詳細については、「 移動時間」を参照してください。

削除ベクトルへの影響を理解する

削除ベクトルは、影響を受けるすべてのデータ ファイルを直ちに書き換えることなく、行を削除済みとしてマークできます。 その動作のため、古く見えるファイルは、引き続きアクティブなテーブルの状態の一部である可能性があります。

VACUUM では、まだ参照されているファイル（deletion vector メタデータが引き続きそれらを参照しているため有効なままのファイルを含む）は削除されません。 削除ベクトルを使用し、後でテーブルを再構成または最適化すると、それらの変更が完了した後で、より古いファイルが VACUUM の対象になる可能性があります。

削除ベクトルの影響を受けるデータを物理的に書き換える場合は、 REORG Delta テーブルを参照してください。

ベスト プラクティスに従う

Fabricで VACUUM を実行する場合は、次のプラクティスを使用します。

• VACUUM後OPTIMIZE実行して、不要になった圧縮前ファイルを削除します。
• タイム トラベル、読者、ライター、回復への影響を明確に理解していない限り、リテンション期間を 7 日未満に設定しないでください。
• 古いファイルが OneLake に蓄積されないように、運用パイプラインで定期的な VACUUM 操作をスケジュールします。
• 保持期間を短縮する前に、タイムトラベルの要件を決定します。
• 削除しようとしているファイルを確認する場合は、最初に DRY RUN を使用します。

Fabric全体のメンテナンス ガイダンスについては、Table メンテナンスの概要および Lakehouse テーブルのメンテナンスを参照してください。

VACUUM で削除されない内容を理解する

VACUUM は古いデータ ファイルを削除しますが、 _delta_log フォルダー内の Delta ログ ファイルは削除されません。

デルタ ログのクリーンアップは、 VACUUMとは別のチェックポイントとログの保持動作に従います。

関連するコンテンツ

• タイム トラベル
• テーブル圧縮
• テーブルのメンテナンスの概要
• Lakehouse テーブルのメンテナンス
• REORG デルタ テーブル