vacuum を使用して未使用のデータ ファイルを削除する

  • [アーティクル]

テーブルで VACUUM コマンドを実行すると、Delta テーブルによって参照されなくなったデータ ファイルや、保持期間のしきい値よりも古いファイルを削除できます。 次の考慮事項により、コストとコンプライアンスのためには定期的に VACUUM を実行することが重要です。

  • 未使用のデータ ファイルを削除すると、クラウド ストレージ のコストが削減されます。
  • VACUUM によって削除されたデータ ファイルには、変更または削除されたレコードが含まれている場合があります。 これらのファイルをクラウド ストレージから完全に削除すると、これらのレコードにアクセスできなくなります。

VACUUM を実行後のデータ ファイルの既定の保持期間のしきい値は 7 日です。 この動作を変更するには、「タイム トラベル クエリのデータ保持を構成する」を参照してください。

Databricks では、予測最適化を使い、差分テーブルに対して VACUUM を自動的に実行することをお勧めします。 「Delta Lake の予測最適化」を参照してください。

Delta Lake の一部の機能では、データ ファイルを書き換えるのではなく、メタデータ ファイルを使用してデータを削除済みとしてマークします。 REORG TABLE ... APPLY (PURGE) を使用して、これらの削除をコミットし、データ ファイルを書き換えることができます。 「メタデータのみの削除を消去してデータの書き換えを強制する」を参照してください。

重要

  • Databricks Runtime 13.3 LTS 以降では、Unity Catalog マネージド テーブルを使用したシャロー クローンの VACUUM セマンティクスは、他の Delta テーブルとは異なります。 「Vacuum と Unity Catalog のシャロー クローン」を参照してください。
  • VACUUM は、Delta Lake で管理されていないディレクトリからすべてのファイルを削除します。_ または . で始まるディレクトリは無視されます。 Delta テーブル ディレクトリ内に構造化ストリーミング チェックポイントなどの追加のメタデータを格納する場合は、_checkpoints のようなディレクトリ名を使用します。
  • VACUUM を実行すると、保持期間が過ぎたテーブルのバージョンのクエリを実行する機能が失われます。
  • チェックポイント操作の後、ログ ファイルは自動的かつ非同期的に削除されます。VACUUM によって管理されません。 ログ ファイルの既定の保持期間は 30 日ですが、テーブルに対して VACUUM を実行すると、タイム トラベルに必要なデータ ファイルが削除されます。

注意

ディスク キャッシュが有効になっている場合、クラスターには、VACUUM で削除された Parquet ファイルのデータが含まれる場合があります。 そのため、ファイルが削除された以前のテーブル バージョンのデータに対して、クエリを実行できる場合があります。 クラスターを再起動すると、キャッシュされたデータが削除されます。 「ディスク キャッシュを構成する」を参照してください。

vacuum の構文の例

VACUUM eventsTable   -- vacuum files not required by versions older than the default retention period

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable DRY RUN    -- do dry run to get the list of files to be deleted

Spark SQL 構文の詳細については、「VACUUM」を参照してください。

Scala、Java、Python 構文の詳細については、Delta Lake API ドキュメントを参照してください。

Note

データ ファイルを削除するべきか判断するためのしきい値を指定するには RETAIN キーワードを使用します。 VACUUM コマンドでは、このしきい値を使用し、指定の時間だけ過去を検索し、その時点の最新のテーブル バージョンを識別します。 Delta では、そのテーブル バージョンとすべての新しいテーブル バージョンに対してクエリを実行するために必要なすべてのデータ ファイルが保持されます。 この設定は、他のテーブル プロパティと互いに影響し合います。 「タイム トラベル クエリのデータ保持を構成する」を参照してください。

メタデータのみの削除を消去してデータの書き換えを強制する

REORG TABLE コマンドは、論理的な削除を適用するためにデータを書き換える APPLY (PURGE) 構文を提供します。 論理的な削除では、データの書き換えやデータ ファイルの削除は行われませんが、メタデータ ファイルを使用して、一部のデータ値が変更されたことを示します。 「REORG TABLE」を参照してください。

Delta Lake で論理的な削除を作成する操作には、次のようなものがあります。

  • 列マッピングが有効になっている列のドロップ。
  • 削除ベクトルが有効になっている行の削除。
  • 削除ベクトルが有効になっている場合の Photon が有効化されたクラスターでのすべてのデータ変更。

論理的な削除を有効にすると、データが削除または更新された後でも、古いデータがテーブルの現在のファイルに物理的に存在し続ける可能性があります。 このデータをテーブルから物理的に削除するには、次の手順を実行します。

  1. REORG TABLE ... APPLY (PURGE)を実行します。 これを行うと、古いデータはテーブルの "現在" のファイルに存在しなくなりますが、タイム トラベルに使用される古いファイルにはまだ存在します。
  2. VACUUM を実行して、これらの古いファイルを削除します。

REORG TABLE により、操作の完了時にテーブルの新しいバージョンが作成されます。 このトランザクションより前の履歴のすべてのテーブル バージョンは、古いデータ ファイルを参照します。 概念的には、これは OPTIMIZE コマンドに似ています。現在のテーブル バージョンのデータに一貫性がある場合でも、データ ファイルが書き換えられます。

重要

データ ファイルは、VACUUM 保持期間に従ってファイルの "有効期限が切れた" 場合にのみ削除されます。 これは、古いファイルの有効期限が切れるように、REORG の後に遅延を伴って VACUUM を実行する必要があることを意味します。 保持される履歴の最大量が減るのと引き換えに、VACUUM の保持期間を短縮し、必要な待機時間を短縮できます。

バキュームで必要なクラスターのサイズとは

VACUUM の適切なクラスター サイズを選択するとき、操作が次の 2 つのフェーズで発生することを理解すると役立ちます。

  1. ジョブは、使用可能なすべての Executor ノードを使用して、ソース ディレクトリ内のファイルを並列に一覧表示することから始まります。 この一覧は、削除するファイルを識別するために Delta トランザクション ログで現在参照されているすべてのファイルと比較されます。 この間、ドライバーはアイドル状態になります。
  2. その後、ドライバーから削除する各ファイルの削除コマンドが発行されます。 ファイルの削除はドライバーのみの操作です。つまり、ワーカー ノードがアイドル状態になっている間に、すべての操作が 1 つのノードで行われます。

コストとパフォーマンスを最適化するために、Databricks では、特に実行時間の長いバキューム ジョブに対して、次のことをお勧めします。

  • 1 から 4 個のワーカーに対して自動スケーリングが設定されたクラスターでバキュームを実行します。各ワーカーには 8 個のコアがあります。
  • 8 コアから 32 コアのドライバーを選択します。 メモリ不足 (OOM) エラーを回避するために、ドライバーのサイズを大きくします。

VACUUM 操作で定期的に 10,000 を超えるファイルが削除されている場合、または処理時間が 30 分を超える場合は、ドライバーのサイズまたはワーカーの数を増やします。

削除するファイルを特定するときに速度低下が発生する場合は、ワーカー ノードを追加します。 削除コマンドの実行中に速度低下が発生した場合は、ドライバーのサイズを大きくしてみてください。

バキュームを実行する頻度はどのくらいですか?

Databricks では、過剰なクラウド データ ストレージ コストを削減するために、すべてのテーブルに対して定期的に VACUUM を実行することを推奨しています。 vacuum の既定の保持期間のしきい値は 7 日です。 しきい値を高く設定すると、テーブルでより広範囲な履歴にアクセスできますが、格納されるデータ ファイル数が増えるため、クラウド プロバイダーでのストレージ コストが増大します。

保持期間のしきい値が低い Delta テーブルで vacuum を実行できないのはなぜですか?

警告

テーブルに対するコンカレント リーダーまたはライターによって、古いスナップショットとコミットされていないファイルが引き続き使用される可能性があるため、保有期間を少なくとも 7 日に設定することをお勧めします。 VACUUM でアクティブなファイルをクリーンアップすると、コンカレント リーダーが失敗することがあります。さらに悪いことに、まだコミットされていないファイルを VACUUM で削除した場合、テーブルが破損する可能性があります。 最も実行時間の長いコンカレント トランザクションよりも長く、テーブルに対する最新の更新に遅れて任意のストリームを開始できる最長期間よりも長い間隔を選択する必要があります。

Delta Lake には、危険性のある VACUUM コマンドを実行できないようにする安全性チェックが用意されています。 このテーブルに対して、指定しようとしている保持期間よりも長くかかる操作が実行されていないことが確かな場合は、Spark 構成プロパティ spark.databricks.delta.retentionDurationCheck.enabled を false に設定することで、この安全性チェックをオフにすることができます。

監査情報

Delta トランザクション ログへの VACUUM コミットには、監査情報が含まれます。 DESCRIBE HISTORY を使用して、監査イベントのクエリを実行できます。