メインコンテンツまでスキップ
に最終更新

使われていないデータファイルをvacuumで削除する

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

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

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

Vacuumに関する注意事項​

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

VACUUM それらの中のすべてのファイルを削除した後、空のディレクトリが残ってしまう可能性があります。以降のVACUUM回の操作で、これらの空のディレクトリは削除されます。

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

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

重要

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

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

  • 保持期間を超えたテーブルのバージョンを照会する機能は、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 モードは、トランザクションログを使用して、VACUUM 保持のしきい値内になくなったデータファイルを識別し、これらのデータファイルをテーブルから削除します。LITE モードは、削除するデータファイルを識別するためにすべてのファイルをリストする必要がないため、頻繁な VACUUM 操作が必要な大規模なテーブルで特に有用です。

注記

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

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 log. Please run VACUUM FULL.

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

SQL
VACUUM table_name FULL

See vacuum.

メタデータのみの削除をパージしてデータを強制的に書き換える​

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

ソフト削除を作成する操作には、以下のものがあります。

  • 列マッピングが有効な状態での列の削除
  • 削除ベクトルが有効な場合のデータ変更。

論理的な削除が有効な場合、データが削除または更新された後でも、古いデータがテーブルの現在のファイル内に物理的に残存する可能性があります。このデータをテーブルから物理的に削除するには、以下のステップを完了してください。

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

REORG TABLE オペレーションが完了すると、テーブルの新しいバージョンを作成します。このトランザクション以前の履歴にあるすべてのテーブルバージョンは、古いデータファイルを参照します。概念的には、これはOPTIMIZEコマンドに似ています。このコマンドでは、現在のテーブルバージョン内のデータが整合性を保っているにもかかわらず、データファイルが書き換えられます。

重要

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

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

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

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

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

  • 各ワーカーに8つのコアがある1-4台のワーカーのオートスケーリングが設定されたクラスターにvacuumを実行します。
  • 8～32コアのドライバーを選択してください。OOM（Out of Memory）エラーを回避するために、ドライバーのサイズを増やしてください。

VACUUMの操作が定期的に1万ファイル以上を削除している、または30分以上処理に時間がかかっている場合、ドライバーのサイズ、またはワーカーの数を増やすことを検討してください。

削除対象のファイルを特定している際に遅延が発生する場合は、ワーカーノードをさらに追加してください。削除コマンドの実行中に遅延が発生している場合、ドライバーのサイズを増やしてみてください。

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

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

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

警告

Databricksでは、保持間隔を7日以上に設定することを強くお勧めします。数日間実行されるジョブがある場合、長時間実行されるジョブが、まだコミットされていないファイルを書き込むことがあります。保持期間が短すぎる場合、VACUUM はジョブが完了する前に、これらのコミットされていないファイルを削除する可能性があります。

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

監査情報​

VACUUM 監査情報をトランザクションログにコミットします。監査イベントを DESCRIBE HISTORY を使用してクエリします。

vacuum 監査ロギングは、ワークスペースレベルの設定 spark.databricks.delta.vacuum.logging.enabled (Delta) または spark.databricks.iceberg.vacuum.logging.enabled (Iceberg) によって制御されます。デフォルトでは、Unity Catalogマネージドテーブルに対し、すべてのプラットフォームで監査ログが有効になっています。

重要

AWS では、S3 に格納されている外部テーブルの場合、複数ワークスペースへの書き込みに関してS3が提供する整合性保証が限定的であるため、監査ロギングはデフォルトで有効になっていません。外部テーブルの監査情報をキャプチャするには、この設定を明示的に有効にする必要があります。S3上のテーブルで監査ログを有効にする場合は、複数ワークスペースへの書き込みを伴うLakeFlowジョブがないことを確認してください。これを行わないと、データが失われる可能性があります。

このページの見出し