次の方法で共有


V オーダーを使用して Delta Lake テーブルを最適化する

Lakehouse テーブルと Delta Lake テーブル形式は、Microsoft Fabric の中心です。 デルタ テーブルを最適化しておくことは、分析ワークロードのパフォーマンスとコスト効率の鍵となります。

この記事では、V オーダーを使用するタイミングを決定するのに役立ち、Delta テーブルの主な構成とメンテナンス パターンを示します。

この記事を使用して、次の操作を行います。

  • V オーダーが何を変更し、いつ役立つのかを理解します。
  • Z オーダーと V オーダーが相互にどのように補完されるかを理解します。
  • 適切な制御レベル (セッション、テーブル プロパティ、または書き込み操作) を選択します。
  • 適切な Spark ランタイム コンテキストで Delta テーブルのメンテナンス パターンを適用します。

消費シナリオに基づいて V Order を適用するタイミングに関するワークロード間のガイダンスについては、 ワークロード間のテーブルのメンテナンスと最適化に関するトピックを参照してください。

V オーダーとは

V オーダーは Parquet ファイルの書き込み時間の最適化であり、ファブリック エンジン全体のダウンストリーム クエリ パフォーマンスを向上させることができます。

一目でわかる

  • 最も役に立つ場所: ダッシュボード、対話型分析、繰り返しスキャンなどの読み取り負荷の高いパターン。
  • それがどのように役立つのか: Parquet レイアウト (行グループの配布、エンコード、圧縮など) を再構成して、読み取り効率を向上させます。
  • 一般的なトレードオフ: 書き込みには時間がかかる場合があります (多くの場合、平均で約 15%)。一方、読み取りはワークロードに応じて大幅に向上します。
  • エンジンの互換性: ファイルはオープンソースの Parquet に準拠したままであり、Z オーダーなどのデルタ機能には互換性があります。
  • スコープ: V オーダーはファイル レベルです。 圧縮、真空、タイムトラベルなどのデルタ操作を使用できます。

V オーダー書き込みを制御する

V オーダーは、特に読み取り負荷の高いシナリオで、クエリのパフォーマンスを向上させるために Parquet ファイル レイアウトを最適化するために使用されます。 Microsoft Fabric では、書き込み負荷の高いデータ エンジニアリング ワークロードのパフォーマンスを最適化するために、新しく作成されたすべてのワークスペースに対して V オーダーが既定で無効になっています

Apache Spark での V オーダー動作は、次の構成によって制御されます。

構成 デフォルト値 説明
spark.sql.parquet.vorder.default false セッション レベルの V オーダー書き込みを制御します。 新しい Fabric ワークスペースでは、既定で false に設定されます。
TBLPROPERTIES("delta.parquet.vorder.enabled") 未設定 テーブル レベルでの既定の V オーダー動作を制御します。
DataFrameのライターオプション: parquet.vorder.enabled 未設定 書き込み操作レベルで V オーダーを制御するために使用されます。

次のコマンドを使用して、シナリオで必要に応じて V オーダー書き込みを有効またはオーバーライドします。

新しい Fabric ワークスペース (spark.sql.parquet.vorder.default=false) では、インジェストおよび変換パイプラインの書き込みパフォーマンスを向上させるために、V オーダーが既定で無効になっています。

対話型クエリやダッシュボードなどの読み取り負荷の高いワークロードの場合は、 spark.sql.parquet.vorder.defaulttrue に設定して V-Order を有効にします。 readHeavyforSparkまたはReadHeavyリソース プロファイルに切り替えて、読み取り優先パフォーマンスのために V オーダーを自動的に有効にすることもできます。

Fabric ランタイム 1.3 以降では、 spark.sql.parquet.vorder.enable 設定は削除されます。 OPTIMIZEを使用してデルタ最適化中に V オーダーを自動的に適用できるため、この古い設定は必要ありません。 以前のランタイム バージョンから移行する場合は、コードからこの設定を削除します。

Apache Spark セッションで V オーダー構成を確認する

変更する前に、次のコマンドを使用して現在のセッション値を確認します。

%%sql 
SET spark.sql.parquet.vorder.default 

Apache Spark セッションで V オーダー書き込みを無効にする

ワークロードが書き込み負荷が高く、インジェストまたは変換の書き込みを高速化する場合は、次のコマンドを使用します。

%%sql 
SET spark.sql.parquet.vorder.default=FALSE 

Apache Spark セッションで V オーダー書き込みを有効にする

セッション レベルで V-Order を有効にすると、そのセッション内のすべての Parquet 書き込みでは、 parquet.vorder.enabled が明示的に false に設定されている場合でも、非デルタ Parquet テーブルとデルタ テーブルを含む V オーダーが使用されます。

%%sql 
SET spark.sql.parquet.vorder.default=TRUE 

Delta テーブルのプロパティを使用して V オーダーを制御する

このセクションでは、テーブルのプロパティが SQL DDL ステートメントと ALTER TABLE ステートメントを使用して定義されているため、Spark SQL のみを使用します。

複数のセッションに適用されるテーブル レベルの既定値が必要な場合は、テーブルプロパティを使用します。

テーブルの作成時に V オーダー テーブル プロパティを有効にする:

%%sql 
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

table プロパティが trueINSERTUPDATE、および MERGE に設定されている場合、書き込み時に V オーダーを適用します。 セッション レベルと書き込みレベルの設定は引き続き優先されるため、 TBLPROPERTIESfalse に設定されている場合でも、書き込みでは V オーダーを使用できます。

テーブル プロパティを変更して、V オーダーを有効または無効にします。

%%sql 
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");

ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");

テーブル プロパティを使用して V オーダーを有効または無効にすると、テーブルへの今後の書き込みのみが影響を受けます。 Parquet ファイルは、作成時に使用される順序を維持します。 V オーダーを適用または削除するように現在の物理構造を変更するには、テーブルを 最適化するときに V オーダーを制御する方法を参照してください。

書き込み操作での V オーダーの直接制御

このセクションでは、PySpark を使用して DataFrame ライター API を示します。 同等のオプションを持つ Scala DataFrame API でも同じパターンを使用できます。

セッション全体またはテーブル全体の既定値ではなく、操作ごとの制御が必要な場合は、書き込みレベルのオプションを使用します。

明示的にオーバーライドされない場合、すべての Apache Spark 書き込みコマンドはセッション設定を継承します。 次の例では、セッション構成を継承して V-Order を使用して書き込みます。

df_source.write\
  .format("delta")\
  .mode("append")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .location("Files/people")\
  .execute()

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2025-01-01' AND end_date <= '2025-01-31'")\
  .saveAsTable("myschema.mytable") 

V オーダーは、述語の影響を受けるファイルのみに適用されます。

spark.sql.parquet.vorder.defaultが設定されていないか、falseに設定されているセッションでは、次のコマンドは V オーダーを使用して書き込みます。

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2025-01-01' AND end_date <= '2025-01-31'")\
  .option("parquet.vorder.enabled","true")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .option("parquet.vorder.enabled","true")\
  .location("Files/people")\
  .execute()

書き込みの最適化とは

通常、ファイル サイズの一貫性が高く、ファイル数が少ないほど、分析 Spark ワークロードのパフォーマンスが向上します。 インジェスト パイプラインでは、多くの場合、多数の小さなファイルが生成されるため、小さなファイルの一般的な問題が発生します。

書き込みの最適化は、Apache Spark での書き込み中にファイル数を減らし、個々のファイル サイズを増やす、Fabric と Synapse の Delta Lake 機能です。 対象ファイルのサイズは構成を使用して、ワークロード要件ごとに変更できます。

この機能は、Microsoft Fabric Runtime for Apache Spark既定で有効になっています。 書き込みの最適化の使用シナリオの詳細については、「Apache Spark での書き込みの最適化の必要性」の記事を参照してください

マージの最適化

Delta Lake MERGE は、ソース テーブル、ビュー、または DataFrame からターゲット テーブルを更新します。 オープン ソースの Delta Lake では、 MERGE は変更されていない行に不要なシャッフル作業を費やすことができます。 ファブリック ランタイムには、オーバーヘッドを削減するための低シャッフル マージの最適化が含まれています。

実装は spark.microsoft.delta.merge.lowShuffle.enabled によって制御され、実行時に既定で有効になります。 コードを変更する必要はなく、オープンソースの Delta Lake との互換性が維持されます。 詳細については、「 差分テーブルでの低シャッフル マージの最適化」を参照してください。

デルタ テーブルのメンテナンス

Delta テーブルの進化に伴い、パフォーマンスとストレージの効率が低下する理由はいくつかあります。

  • テーブルに追加された新規データはデータを歪ませる可能性があります。
  • バッチおよびストリーミング データの取り込み率により、多数の小さなファイルが取り込まれる可能性があります。
  • 更新操作と削除操作では、Parquet ファイルは不変であり、Delta は変更のために新しいファイルを書き込むため、読み取りオーバーヘッドが増加します。
  • 古いデータ ファイルとログ ファイルは、ストレージに蓄積される可能性があります。

テーブルを正常な状態に保つには、圧縮とクリーンアップ操作を定期的に使用します。

  • OPTIMIZE では、変更を大きな Parquet ファイルに統合することで、ビン圧縮が実行されます。
  • VACUUM は、逆参照されたファイルをストレージから削除します。

ヒント

ポータルベースのメンテナンス ワークフローや監視ガイダンス、保持を重視した運用ガイダンスに対しては、Lakehouse の Delta テーブルメンテナンスを活用します。

OPTIMIZEVACUUM は Spark SQL コマンドです。 次のコマンドで実行します。

これらのコマンドは、T-SQL のみをサポートする SQL Analytics エンドポイント または Warehouse SQL クエリ エディターではサポートされていません。 SQL エンドポイント ワークフローの場合は、 Delta Lake テーブルのメンテナンス を使用するか、Fabric ノートブックでコマンドを実行します。

最初にインジェストの頻度と読み取りパターンに基づいてテーブルの物理構造を設計します。 多くのワークロードでは、テーブルの設計は最適化コマンドよりも影響が大きいです。

テーブルを最適化するときに V オーダーを制御する

圧縮と V オーダー書き換えを 1 回の操作で行う場合は、次のコマンドを使用します。

Z オーダーと V オーダーでは、読み取りパフォーマンスのさまざまな側面が最適化されます。

  • 選択的フィルターのデータ スキップを改善するために、Z オーダー (SQL キーワード ZORDER) は関連する値をクラスター化します。
  • V オーダー (SQL キーワード VORDER) は、Parquet ファイル レイアウトを最適化して、ファブリック エンジン全体の読み取り効率を向上させます。

クエリで特定の列に対してフィルター処理が頻繁に行われる場合は、Z オーダーが役立ちます。 ワークロード全体が読み取り負荷が高い場合は、V オーダーが役立ちます。 多くの場合、両方を組み合わせることができます。

このクイック デシジョン ガイドを使用します。

  • エンジン間で広範な読み取りパフォーマンスの向上が必要な場合は、 VORDER を使用します。
  • 既知の列に対してクエリが繰り返しフィルター処理され、V オーダー レイアウトの利点も必要な場合は、ZORDER BY (...)VORDERを使用します。

次のコマンドは、 TBLPROPERTIES とセッションの設定に関係なく、bin-compact を形成し、影響を受けるすべてのファイルを V オーダーを使用して書き換えます。

%%sql 
OPTIMIZE <table|fileOrFolderPath> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER BY (col_name1, col_name2, ...)] VORDER;

ZORDERVORDERを SQL で一緒に使用すると、Apache Spark はビン圧縮、Z オーダー、V オーダーの順に適用されます。

次のコマンドは、 TBLPROPERTIESを使用して、影響を受けるすべてのファイルをビン圧縮して書き直します。 TBLPROPERTIESが V オーダーを有効にするように設定されている場合、影響を受けるすべてのファイルは V オーダーで書き込まれます。 TBLPROPERTIESが設定されていないか、falseに設定されている場合、動作はセッション設定を継承します。 テーブルの書き換えから V オーダーを削除するには、セッション構成を false に設定します。

Fabric ノートブックでこれらのコマンドを実行する場合は、 %%sqlOPTIMIZEの間にスペースを含めます。

正しい構文:

%%sql 
OPTIMIZE table_name;

構文が正しくありません: %%sqlOPTIMIZE table_name;

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];

保持とストレージのクリーンアップに VACUUM を使用する

一般的な VACUUM シナリオは、データ保持によるクリーンアップです。 古い参照されていないファイルが蓄積され、更新、削除、または繰り返しインジェスト サイクル後にストレージを再利用する場合に使用します。

VACUUMは、タイムトラベルと復旧要件に合った保持期間でのみ実行します。 既定のパターンでは、7 日間の履歴が保持されます。

Spark ノートブックでは、コンパクトな VACUUM パターンは次のようになります。

%%sql
VACUUM schema_name.table_name;

VACUUM schema_name.table_name RETAIN 168 HOURS;

保持動作と安全性のガイダンスについては、 VACUUM コマンドを参照してください。 プログラムによるメンテナンスの実行については、「 Delta テーブルでのテーブルメンテナンスの実行」を参照してください。