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

予測的最適化は on Unity Catalog マネージドテーブルに対して自動的に VACUUM を実行します。Databricks では、すべての Unity Catalog マネージドテーブルに対して予測的最適化を有効にして、データのメンテナンスを簡素化し、ストレージ コストを削減することをお勧めします。 Unity Catalog マネージドテーブルの予測的最適化を参照してください。

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

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

vacuumに関する注意事項

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

VACUUM その中からすべてのファイルを削除した後、空のディレクトリが残る可能性があります。 続く VACUUM 操作により、これらの空のディレクトリが削除されます。

Databricks では、予測的最適化を使用して、 Delta テーブルのVACUUMを自動的に実行することをお勧めします。 Unity Catalog マネージドテーブルの予測的最適化を参照してください。

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

重要

• Databricks Runtime 13.3 LTS 以降では、Unity Catalog マネージドテーブルを持つ浅いクローンのVACUUMセマンティクスは、他の Delta テーブルとは異なります。浅いクローンのvacuumとUnity Catalogを参照してください。

• VACUUM Delta Lake で管理されていないディレクトリからすべてのファイルを削除し、 _ または .で始まるディレクトリは無視します。 Deltaテーブルディレクトリ内に構造化ストリーミングチェックポイントなどの追加のメタデータを保存する場合は、_checkpoints などのディレクトリ名を使用します。

  • チェンジデータフィードのデータは、_change_dataディレクトリで Delta Lake によって管理され、VACUUMで削除されます。 DatabricksでのDelta Lake チェンジデータフィードの使用 を参照してください。
  • ブルーム フィルター インデックスは、Delta Lake によって管理される _delta_index ディレクトリを使用します。 VACUUM は、このディレクトリ内のファイルをクリーンアップします。 ブルーム・フィルター・インデックスを参照してください。

• 保持期間より古いテーブル・バージョンをクエリする機能は、 VACUUMの実行後に失われます。

• ログ・ファイルは、チェックポイント操作後に自動的かつ非同期的に削除され、 VACUUMによって管理されません。 ログファイルのデフォルトの保持期間は 30 日ですが、テーブルで VACUUM を実行すると、タイムトラベルに必要なデータファイルが削除されます。

注記

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

vacuum の構文例

SQL

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

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

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

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

注記

Databricks Runtime 18.0 以降では、 deletedFileRetentionDurationテーブル プロパティを使用して保持期間を制御します。Unity Catalogマネージドテーブルの場合、これはDatabricks Runtime 12.2 以降に適用されます。

「タイムトラベルクエリのデータ保持を構成する」を参照してください。

フルモードとライトモード

備考

プレビュー

この機能は、Databricks Runtime 16.1 以降でパブリック プレビュー段階です。

vacuum 文で LITE キーワードを指定すると、テーブルディレクトリ内のすべてのファイルがリストされないように、代替モードの VACUUM をトリガーできます。

LITE モード は、Delta トランザクション・ログを使用して、 VACUUM リテンション期間のしきい値内になくなったデータ・ファイルを識別し、これらのデータ・ファイルをテーブルから削除します。 LITE モードは、削除するデータファイルを識別するためにすべてのファイルをリストする必要がないため、頻繁な VACUUM 操作が必要な大きなテーブルで特に便利です。

注記

VACUUM``LITEモードで実行しても、トランザクション・ログで参照されていないファイルは削除されません。たとえば、中止されたトランザクションによって作成されたファイルなどです。

次の構文を使用して、LITEモードでVACUUMします。

SQL

VACUUM table_name LITE

LITE モード には次の要件があります。

• 構成されたトランザクション ログの保持しきい値 (デフォルトでは 30 日) 内で、少なくとも 1 つの VACUUM 操作が正常に実行されている必要があります。

この要件が満たされていない場合、LITE モードでVACUUMを実行しようとすると、次のエラー メッセージが表示されます。続行するには、 VACUUM を FULL モードで実行する必要があります。

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the Delta log. Please run VACUUM FULL.

FULL mode は vacuum のデフォルトです。 フル モードは、次のコマンドで明示的に実行できます。

SQL

VACUUM table_name FULL

vacuumを参照してください。

メタデータのみを削除してデータを強制的に書き換えます

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

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

• 列マッピングが有効になっている列の削除。
• 削除ベクトルが有効になっているデータの変更。

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

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

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

重要

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

vacuumにはどのくらいのサイズのクラスターが必要ですか?

VACUUMの正しいクラスター サイズを選択するには、操作が次の 2 つのフェーズで行われることを理解しておくと役立ちます。

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

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

• 各ワーカーに8つのコアがある1-4台のワーカーのオートスケーリングが設定されたクラスターにvacuumを実行します。
• 8 から 32 コアのドライバーを選択します。 メモリ不足 (OOM) エラーを回避するために、ドライバーのサイズを大きくします。

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

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

どのくらいの頻度で vacuum実行する必要がありますか?

Databricks では、余分なクラウドデータストレージのコストを削減するために、すべてのテーブルで VACUUM を定期的に実行することをお勧めします。 vacuum のデフォルト保持しきい値は 7 日間です。しきい値を高く設定すると、テーブルの履歴にアクセスできるようになりますが、保存されるデータファイルの数が増え、その結果、クラウドプロバイダーからのストレージコストが増加します。

vacuumDeltaリテンション期間のしきい値が低い テーブルを できないのはなぜですか?

警告

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

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

監査情報

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

監査情報をキャプチャするには、 [ spark.databricks.delta.vacuum.logging.enabled] を有効にします。 AWS S3 テーブルの監査ログは、マルチワークスペースの書き込みに関して S3 が提供する一貫性の保証が限られているため、デフォルトでは有効になっていません。 S3 で有効にする場合は、マルチワークスペース書き込みを伴うワークフローがないことを確認してください。 そうしないと、データが失われる可能性があります。