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

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

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

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

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

Vacuumに関する注意事項​

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

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

削除ベクトルなどの一部のテーブル機能は、データファイルを書き換えるのではなく、メタデータファイルを使用してデータを削除済みとしてマークします。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 の構文例​

デフォルトの保持期間よりも古いバージョンで不要になったファイルを削除するには、追加の構成なしで VACUUM を実行します。

SQL
VACUUM table_name

ファイルを削除せずに削除対象のファイルリストをプレビューするには、DRY RUN を指定して VACUUM を実行します：

SQL
VACUUM table_name DRY RUN

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

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

注記

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

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

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

備考

プレビュー

この機能は、Databricks Runtime 16.4 LTS以降ではパブリックプレビュー段階にあります。

パフォーマンスを向上させ、テーブルディレクトリ内のすべてのファイルをリストすることを避けてコストを削減するには、「vacuum」ステートメントでLITE キーワードを指定して、VACUUM の代替モードをトリガーします。これは、頻繁な VACUUM 操作が必要な大規模なテーブルに役立ちます。

LITE モードはトランザクションログを使用して、VACUUM の保持しきい値内になくなったデータファイルを識別し、これらのデータファイルをテーブルから削除します。

注記

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

LITEモードでVACUUMする場合の構文は、次のとおりです。

SQL
VACUUM table_name LITE

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

SQL
VACUUM table_name FULL

See vacuum.

要件​

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.

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

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 コマンドが実行されないように、安全チェックがあります。指定する保持間隔より長くかかる操作がこのテーブルで実行されていないことが確実な場合は、retentionDurationCheck Spark 設定をfalseに設定して、この安全チェックを無効にしてください。

SQL
SET spark.databricks.delta.retentionDurationCheck.enabled = false

監査情報​

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

デフォルトでは、Unity Catalogマネージドテーブルのすべてのプラットフォームで監査ログが有効になっています。vacuum.logging Spark 設定で vacuum 監査ログを制御します。

SQL
SET spark.databricks.delta.vacuum.logging.enabled = true

この構成をワークスペース全体およびすべてのクラスターに適用するには、クラスターポリシーを使用し、ポリシーJSONに以下を追加します:

JSON
{
  "spark_conf.spark.databricks.delta.vacuum.logging.enabled": {
    "type": "fixed",
    "value": "true"
  }
}

コンピュート ポリシーの作成と管理を参照してください。

注記

監査ログは、外部テーブルでもデフォルトで有効になっています。

このページの見出し