データファイルのレイアウトを最適化する
予測的最適化は Unity Catalog マネージドテーブルに対して自動的にOPTIMIZEを実行します。Databricks では、すべての Unity Catalog マネージドテーブルに対して予測的最適化を有効にして、データのメンテナンスを簡素化し、ストレージ コストを削減することをお勧めします。 Unity Catalog マネージドテーブルの予測的最適化を参照してください。
OPTIMIZEコマンドはデータ ファイルを書き換えて、テーブルのデータ レイアウトを改善します。液体クラスタリングが有効になっているテーブルの場合、 OPTIMIZE液体クラスタリング キーによってデータ ファイルをグループ データに書き換えます。 パーティションが定義されたテーブルの場合、ファイルの圧縮とデータのレイアウトはパーティション内で実行されます。
リキッドクラスタリングのないテーブルには、書き換え時のデータクラスタリングを改善するために、オプションで ZORDER BY 句を含めることができます。 Databricks 、パーティション、ZORDER、またはその他のデータレイアウトアプローチの代わりにリキッドクラスタリングを使用することをお勧めします。
ZORDER Delta Lake 固有の最適化です。Apache Iceberg テーブルでは、代わりにクラスタリングとソートの戦略が使用されます。
OPTIMIZEを参照してください。
Databricks Runtime 16.0 以降では、OPTIMIZE FULL を使用して、リキッドクラスタリングが有効になっているテーブルの再クラスタリングを強制できます。すべてのレコードの再クラスタリングの強制を参照してください。
構文の例
OPTIMIZEコマンドを実行して圧縮をトリガーします。
- SQL
- Python
- Scala
OPTIMIZE table_name
Python DeltaTable API は Delta Lake 固有です。
from delta.tables import *
deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().executeCompaction()
Scala DeltaTable API は Delta Lake 固有です。
import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().executeCompaction()
大量のデータがあり、そのサブセットのみを最適化したい場合は、 WHEREを使用してオプションのパーティション述語を指定します。
- SQL
- Python
- Scala
OPTIMIZE table_name WHERE date >= '2022-11-18'
Python DeltaTable API は Delta Lake 固有です。
from delta.tables import *
deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().where("date='2021-11-18'").executeCompaction()
Scala DeltaTable API は Delta Lake 固有です。
import io.delta.tables._
val deltaTable = DeltaTable.forName(spark, "table_name")
deltaTable.optimize().where("date='2021-11-18'").executeCompaction()
- ビンパッキング最適化は べき等 であり、同じデータセットで 2 回実行された場合、2 回目の実行は効果がありません。
- ビンパッキングは、ディスク上のサイズに対して均等なバランスのデータファイルを生成することを目的としていますが、必ずしもファイルごとのタプルの数ではありません。 ただし、この 2 つのメジャーは、ほとんどの場合、相関しています。
OPTIMIZE操作を実行するためのPythonとScala APIは、Databricks Runtime 11.3 LTS以降で使用できます。
Delta テーブルのリーダーはスナップショット分離を使用します。つまり、 OPTIMIZE がトランザクション ログから不要なファイルを削除しても、スナップショット テーブルは中断されません。 OPTIMIZE はテーブルにデータ関連の変更は行わないため、 OPTIMIZE の前後に読み取っても同じ結果が得られます。 ストリーミングソースであるテーブルで OPTIMIZE を実行しても、このテーブルをソースとして扱う現在または将来のストリームには影響しません。 OPTIMIZE は、削除されたファイルと操作によって追加されたファイルのファイル統計 (最小、最大、合計など) を返します。 最適化統計には、Z-ordering 統計、バッチ数、最適化されたパーティションも含まれます。
自動圧縮を使用して、小さなファイルを自動的に圧縮することもできます。自動圧縮を参照してください。
どのくらいの頻度で OPTIMIZE実行する必要がありますか?
Unity Catalog マネージドテーブルの予測的最適化を有効にしてOPTIMIZEコスト効率が高いときに自動的に実行されるようにします。
OPTIMIZEを実行する頻度を選択すると、パフォーマンスとコストの間にトレードオフがあります。エンドユーザーのクエリパフォーマンスを向上させるには、 OPTIMIZE をより頻繁に実行します。 これにより、リソースの使用量が増加するため、コストが高くなります。 コストを最適化するには、実行頻度を減らします。
Databricks では、まず毎日 (できればスポット価格が低い夜間) OPTIMIZE を実行し、その後、コストとパフォーマンスのトレードオフのバランスを取るために頻度を調整することをお勧めします。
OPTIMIZE を実行するのに最適なインスタンスタイプ (bin-packing と Z-Ordering) は何ですか?
どちらの操作も、大量の Parquet デコードとエンコードを行う CPU を集中的に使用する操作です。
Databricks は 、コンピュート最適化 インスタンスタイプを推奨しています。 OPTIMIZE は、接続されたSSDのメリットも得られます。