Databricks のテーブルサイズ
Databricks 上の Delta Lake によってサポートされるテーブルについて報告されるテーブル サイズは、クラウド オブジェクト ストレージ内の対応するファイル ディレクトリの合計サイズとは異なります。 この記事では、この違いが存在する理由と、コスト管理に関する推奨事項について説明します。
Delta テーブルのサイズがディレクトリのサイズと一致しないのはなぜですか?
UI と DESCRIBE
コマンドを使用して Databricks で報告されるテーブル サイズは、現在のバージョンの Delta テーブルで参照されるファイルのディスク上のデータ ファイルの合計サイズを参照します。 テーブルに書き込むほとんどの操作では、基になるデータ・ファイルを書き直す必要がありますが、古いデータ・ファイルはタイムトラベル・クエリをサポートするために一定期間保持されます。
テーブル内のレコードを定期的に削除または更新する場合、削除ベクトルを使用するとクエリを高速化し、データファイルの合計サイズを削減できます。 削除ベクトルとはを参照してください。
予測的最適化を使用してデータサイズを制御する
Databricks Unity Catalog マネージドテーブルは、予測的最適化を有効にして使用することをお勧めします。 マネージドテーブル and 予測的最適化により、 Databricks は自動的にOPTIMIZE
を実行し、コマンドVACUUM
、未使用のデータファイルの蓄積を防ぎます。 テーブルの現在のバージョンと、クラウド・オブジェクト・ストレージ内のデータ・ファイルの合計サイズとの間には、常にサイズの違いがあることが想定されます。 これは、現在のバージョンで参照されていないデータ ファイルがタイムトラベル クエリをサポートする必要があるためです。 Unity Catalog マネージドテーブルの予測的最適化を参照してください。
VACUUM
はどのファイル メトリクスを報告しますか?
未使用のデータファイルを VACUUM
でクリーンアップしたり、 DRY RUN
を使用して削除対象ファイルをプレビューしたりすると、メトリクスは削除されたファイルの数とデータのサイズを報告します。 VACUUM
によって削除されるファイルのサイズと数は大きく異なりますが、削除されたファイルのサイズがテーブルの現在のバージョンの合計サイズを超えることは珍しくありません。
OPTIMIZE
はどのファイル メトリクスを報告しますか?
OPTIMIZE
をターゲット表で実行すると、新しいデータ・ファイルは既存のデータ・ファイルのレコードを結合します。OPTIMIZE
中にコミットされた変更は、データ編成にのみ影響し、基になるデータの内容は変更されません。テーブルに関連付けられたデータ・ファイルの合計サイズは、 OPTIMIZE
の実行後に増加します。これは、新しく圧縮されたファイルが、参照されなくなったデータ・ファイルと包含ディレクトリに共存するためです。
OPTIMIZE
後に報告されるテーブルのサイズは、現在のテーブル・バージョンによって参照されるデータ・ファイルの合計サイズがデータ圧縮によって減少するため、通常は OPTIMIZE
が実行される前のサイズよりも小さくなります。VACUUM
は、基になるデータ ファイルを削除するために、rentention しきい値が経過した後に実行する必要があります。
REORG TABLE
や DROP FEATURE
などの操作についても同様のメトリクスが表示される場合があります。データ・ファイルの書き換えが必要なすべての操作では、現在のテーブル・バージョンで参照されなくなったデータ・ファイルが VACUUM
削除されるまで、包含ディレクトリ内のデータの合計サイズが増加します。