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

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

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

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

一部の 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 の構文例

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

VACUUM '/data/events' -- vacuum files in path-based table

VACUUM delta.`/data/events/`

VACUUM delta.`/data/events/` RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

VACUUM eventsTable 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) 構文を提供します。論理的な削除では、データの書き換えやデータファイルの削除は行われず、メタデータファイルを使用して一部のデータ値が変更されたことを示します。再編成表を参照してください。

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

列マッピングが有効になっている列を削除します。
削除ベクトルが有効になっている行の削除。
削除ベクトルが有効になっている場合のPhoton対応クラスターのデータ変更。

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

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

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

重要

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

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

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

ジョブは、使用可能なすべてのエグゼキューターノードを使用して、ソースディレクトリ内のファイルを並列に一覧表示することから始まります。この一覧は、削除するファイルを識別するために、Delta トランザクションログで現在参照されているすべてのファイルと比較されます。この間、ドライバーはアイドル状態になります。
ドライバーは、削除するファイルごとに削除コマンドを発行します。ファイルの削除はドライバーのみの操作であり、ワーカーノードがアイドル状態にある間、すべての操作が 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を使用して監査イベントを表示できます。