Azure Databricks テーブルに対して報告されるテーブル サイズは、クラウド オブジェクト ストレージ内の対応するファイル ディレクトリの合計サイズとは異なります。 このページでは、この違いが存在する理由と、コストを管理するための推奨事項について説明します。
テーブル サイズがディレクトリ サイズと一致しないのはなぜですか?
UI と DESCRIBE コマンドを使用して Azure Databricks で報告されるテーブル サイズは、現在のバージョンのテーブルで参照されているファイルのディスク上のデータ ファイルの合計サイズを参照します。 テーブルに書き込むほとんどの操作では、基になるデータ ファイルを書き換える必要がありますが、古いデータ ファイルは、タイム トラベル クエリをサポートするために一定期間保持されます。
Note
テーブル内のレコードを定期的に削除または更新すると、削除ベクトルによってクエリが高速化され、データ ファイルの合計サイズが小さくなります。 Databricks の削除ベクトルを参照してください。
テーブルのストレージに関するメトリックを計算する
適用対象:Databricks Runtime 18.0 以上で![]()
ストレージの合計サイズがテーブル サイズと異なる理由を理解するには、 ANALYZE TABLE … COMPUTE STORAGE METRICSを使用します。 このコマンドは、ストレージ割り当ての詳細な内訳を提供し、次の作業に役立ちます。
-
コスト最適化の機会を特定する: 回収できるストレージの量を確認する
VACUUM - 時間移動のオーバーヘッドを分析する: 履歴データを保持するコストを理解する
- ストレージ パターンの追跡: コマンドを定期的に実行して、時間の経過と同時にテーブル ストレージがどのように進化するかを監視する
- テーブル間のストレージの監査: ループでコマンドを実行してデータ資産全体を分析する
このコマンドは、次のような包括的なメトリックを返します。
- 合計ストレージ サイズ: すべてのデータ、メタデータ、ログを含む完全なフットプリント
- アクティブ データ: 現在のテーブル バージョンのサイズ
- バキューム可能なデータ: 回収できる領域
- タイム トラベル データ: ロールバックの過去データ
これは、予測最適化によって Azure Databricks がストレージを自動的に管理する Unity カタログのマネージド テーブルにとって特に重要 です。
完全な構文と例については、 COMPUTE STORAGE METRICS を参照してください。
予測最適化を使用してデータ サイズを制御する
Databricks では、予測最適化を有効にした Unity カタログのマネージド テーブルを使用することをお勧めします。 マネージド テーブルと予測の最適化により、Databricks は OPTIMIZE コマンドと VACUUM コマンドを自動的に実行して、未使用のデータ ファイルが蓄積されないようにします。 テーブルの現在のバージョンとクラウド オブジェクト ストレージ内のデータ ファイルの合計サイズには、常にサイズの違いがあることを想定してください。 これは、タイム トラベル クエリをサポートするために、現在のバージョンで参照されないデータ ファイルが必要となるためです。 「Unity Catalog 管理テーブルの予測最適化」を参照してください。
VACUUM によって報告されるファイル メトリックはどのようなものですか?
VACUUMを使用して未使用のデータ ファイルをクリーンアップするか、DRY RUNを使用して削除対象のファイル セットをプレビューすると、メトリックによって、削除されたファイルの数とデータサイズがレポートされます。
VACUUMによって削除されるファイルのサイズと数は大きく異なりますが、削除されたファイルのサイズが現在のバージョンのテーブルの合計サイズを超えるのは珍しくありません。
OPTIMIZE によって報告されるファイル メトリックはどのようなものですか?
ターゲット テーブルで OPTIMIZE 実行すると、新しいデータ ファイルによって既存のデータ ファイルのレコードが結合されます。
OPTIMIZE 中にコミットされた変更は、データの編成にのみ影響し、基になるデータ コンテンツに変更は加えられません。 テーブルに関連付けられているデータ ファイルの合計サイズは、 OPTIMIZE の実行後に増加します。これは、新しい圧縮されたファイルが、参照されなくなったデータ ファイルを含むディレクトリに共存するためです。
OPTIMIZE後に報告されるテーブルのサイズは、現在のテーブル バージョンによって参照されるデータ ファイルの合計サイズがデータ圧縮と共に小さくなるため、一般に、OPTIMIZE実行前のサイズよりも小さくなります。
VACUUM 基になるデータファイルを削除するには、保持しきい値を超えてから実行する必要があります。
Note
REORG TABLE や DROP FEATURE などの操作に関する同様のメトリックが表示される場合があります。 データ ファイルの書き換えを必要とするすべての操作は、現在のテーブル バージョンで参照されなくなったデータ ファイル VACUUM 削除するまで、格納ディレクトリ内のデータの合計サイズを増やします。