Databricks のテーブル サイズ

Databricks 上の Delta Lake によってサポートされるテーブルについて報告されるテーブル サイズは、クラウド オブジェクト ストレージ内の対応するファイル ディレクトリの合計サイズとは異なります。 この記事では、この違いが存在する理由と、コストを制御するための推奨事項について説明します。

Delta テーブルのサイズがディレクトリのサイズと一致しないのはなぜですか?

UI およびDESCRIBEコマンドを通じて Databricks で報告されるテーブル サイズは、Delta テーブルの現在のバージョンで参照されるファイルのディスク上のデータ ファイルの合計サイズを参照します。 テーブルに書き込む操作のほとんどは、基礎となるデータ ファイルを書き換える必要がありますが、タイムトラベル クエリをサポートするために、古いデータ ファイルは一定期間保持されます。

注：

テーブル内のレコードを定期的に削除または更新する場合、削除ベクトルによってクエリが高速化され、データ ファイルの合計サイズが削減されます。 削除ベクトルとは何かを参照してください。 。

予測的最適化を使用してデータサイズを制御する

Databricks Unity Catalog マネージドテーブルは、予測的最適化を有効にして使用することをお勧めします。 マネージドテーブル and 予測的最適化により、 Databricks は自動的にOPTIMIZEを実行し、コマンドVACUUM、未使用のデータファイルの蓄積を防ぎます。 テーブルの現在のバージョンと、クラウド・オブジェクト・ストレージ内のデータ・ファイルの合計サイズとの間には、常にサイズの違いがあることが想定されます。 これは、現在のバージョンで参照されていないデータ ファイルがタイムトラベル クエリをサポートする必要があるためです。 予測的最適化 for Unity Catalog マネージドテーブルを参照してください。

VACUUMはどのファイルメトリックを報告しますか?

VACUUMを使用して未使用のデータ ファイルをクリーンアップするか、 DRY RUNを使用して削除対象として設定されたファイルをプレビューすると、メトリクスは削除されたファイルの数とデータのサイズを報告します。 VACUUMによって削除されるファイルのサイズと数は大きく異なりますが、削除されるファイルのサイズが現在のバージョンのテーブルの合計サイズを超えることは珍しくありません。

OPTIMIZEはどのファイルメトリックを報告しますか?

OPTIMIZEがターゲット テーブルで実行されると、新しいデータ ファイルによって既存のデータ ファイルのレコードが結合されます。 OPTIMIZE中にコミットされた変更は、データ編成にのみ影響し、基になるデータの内容は変更されません。OPTIMIZEの実行後、テーブルに関連付けられたデータ ファイルの合計サイズが増加します。これは、新しく圧縮されたファイルが、参照されなくなったデータ ファイルを含むディレクトリに共存するためです。

現在のテーブル バージョンによって参照されるデータ ファイルの合計サイズはデータ圧縮によって減少するため、 OPTIMIZE後に報告されるテーブルのサイズは通常、 OPTIMIZE実行前のサイズよりも小さくなります。 基礎となるデータ ファイルを削除するには、保持しきい値を超えた後にVACUUMを実行する必要があります。

注：

REORG TABLEやDROP FEATUREなどの操作に同様のメトリックが表示される場合があります。 データファイルの書き換えを必要とするすべての操作では、現在のテーブルバージョンで参照されなくなったデータファイルが削除されるまで VACUUM 含まれているディレクトリ内のデータの合計サイズが増加します。