vacuumで未使用のデータファイルを削除する
予測的最適化 自動的に実行 VACUUM
on Unity Catalog マネージドテーブル. 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
で削除されます。 でのDelta Lake チェンジデータフィードの使用Databricks を参照してください。 - ブルーム フィルター インデックスは、Delta Lake によって管理される
_delta_index
ディレクトリを使用します。VACUUM
は、このディレクトリ内のファイルをクリーンアップします。 ブルーム・フィルター・インデックスを参照してください。
- チェンジデータフィードのデータは、
-
保持期間より古いテーブル・バージョンをクエリする機能は、
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 は、そのテーブル バージョンとすべての新しいテーブル バージョンのクエリに必要なすべてのデータ ファイルを保持します。 この設定は、他のテーブル プロパティと相互作用します。 タイムトラベル クエリのデータ保持の構成を参照してください。
フルモードとライトモード
プレビュー
この機能は、Databricks Runtime 16.1 以降でパブリック プレビュー段階です。
vacuum 文で LITE
キーワードを指定すると、テーブルディレクトリ内のすべてのファイルがリストされないように、代替モードの VACUUM
をトリガーできます。
LITE
mode は、Delta トランザクション・ログを使用して、 VACUUM
リテンション期間のしきい値内になくなったデータ・ファイルを識別し、これらのデータ・ファイルをテーブルから削除します。 LITE
モードは、削除するデータファイルを識別するためにすべてのファイルをリストする必要がないため、頻繁な VACUUM
操作が必要な大きなテーブルで特に便利です。
VACUUM``LITE
モードで実行しても、トランザクション・ログで参照されていないファイルは削除されません。たとえば、中止されたトランザクションによって作成されたファイルなどです。
次の構文を使用して、LITE
モードでVACUUM
します。
VACUUM table_name LITE
LITE
mode には次の要件があります。
- 構成されたトランザクション ログの保持しきい値 (デフォルトでは 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 のデフォルトです。 フル モードは、次のコマンドで明示的に実行できます。
VACUUM table_name FULL
vacuumを参照してください。
メタデータのみを削除してデータを強制的に書き換えます
REORG TABLE
コマンドには、論理的な削除を適用するためにデータを書き換えるためのAPPLY (PURGE)
構文が用意されています。論理的な削除では、データの書き換えやデータ・ファイルの削除は行われず、メタデータ・ファイルを使用して、一部のデータ値が変更されたことを示します。 REORG TABLE を参照してください。
Delta Lake で論理的な削除を作成する操作には、次のものがあります。
論理的な削除を有効にすると、データが削除または更新された後でも、古いデータがテーブルの現在のファイルに物理的に存在する可能性があります。 このデータをテーブルから物理的に削除するには、次の手順を実行します。
REORG TABLE ... APPLY (PURGE)
を実行します。これを行うと、古いデータはテーブル の現在の ファイルに存在しなくなりますが、タイムトラベルに使用される古いファイルには引き続き存在します。VACUUM
を実行して、これらの古いファイルを削除します。
REORG TABLE
操作の完了時に、テーブルの新しいバージョンを作成します。 このトランザクションより前の履歴にあるすべてのテーブル・バージョンは、古いデータ・ファイルを参照しています。 概念的には、これは OPTIMIZE
コマンドと似ており、現在のテーブル バージョンのデータの一貫性が保たれていても、データ ファイルが書き換えられます。
データファイルは、VACUUM
保持期間に従ってファイルの 有効期限が切れ た場合にのみ削除されます。これは、古いファイルの有効期限が切れるように、REORG
後に遅延してVACUUM
を行う必要があることを意味します。VACUUM
の保持期間を短縮して必要な待ち時間を短縮できますが、保持される最大履歴が減少する代償としてカウントされます。
クラスター vacuum どのくらいのサイズが必要ですか?
VACUUM
の正しいクラスター サイズを選択するには、操作が次の 2 つのフェーズで行われることを理解しておくと役立ちます。
- ジョブは、使用可能なすべてのエグゼキューター ノードを使用して、ソース ディレクトリ内のファイルを並列に一覧表示することから開始されます。 このリストは、Delta トランザクション・ログで現在参照されているすべてのファイルと比較され、削除するファイルが識別されます。 この間、ドライバーはアイドル状態になります。
- その後、ドライバーは削除するファイルごとに削除コマンドを発行します。 ファイルの削除はドライバーのみの操作であり、ワーカー ノードがアイドル状態の間、すべての操作が 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
を使用してクエリできます。