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

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

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

  • 未使用のデータファイルを削除すると、クラウドストレージのコストが削減されます。

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

Vacuumに関する注意事項

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

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

Databricks では、予測的最適化を使用して、 Delta テーブルのVACUUMを自動的に実行することをお勧めします。 予測的最適化 for 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などのディレクトリ名を使用します。

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

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

注

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

VACUUM の構文例 

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

VACUUM table_name RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

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 のドキュメント を参照してください。

注

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にはどのサイズのクラスターが必要ですか?

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

  1. ジョブは、使用可能なすべての エグゼキューター ノードを使用して、ソース ディレクトリ内のファイルを並列に一覧表示することから始まります。 この一覧は、削除するファイルを識別するために、Delta トランザクション ログで現在参照されているすべてのファイルと比較されます。 この間、ドライバーはアイドル状態になります。

  2. ドライバーは、削除するファイルごとに削除コマンドを発行します。 ファイルの削除はドライバーのみの操作であり、ワーカー ノードがアイドル状態にある間、すべての操作が 1 つのノードで行われます。

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

  • 自動スケーリングが 1 〜 4 ワーカーに設定されたクラスターで vacuum を実行し、各ワーカーには 8 つのコアがあります。

  • 8〜32コアのドライバーを選択します。 ドライバーのサイズを増やして、メモリ不足 (OOM) エラーを回避します。

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

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

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

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

保有期間のしきい値が低い Delta テーブルをバキューム処理できないのはなぜですか?

警告

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

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

監査情報

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

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