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