次の方法で共有

Microsoft Fabric でのワークロード間テーブルのメンテナンスと最適化

Microsoft Fabric のデルタ テーブルは、パフォーマンス特性と最適化要件が異なる複数の消費エンジンを提供します。 このガイドでは、1 つのエンジンによって記述されたテーブルが他のエンジンによって使用される方法と、それに応じてテーブルのメンテナンス戦略を最適化する方法を理解するための包括的なフレームワークを提供します。

効率的なデータ プラットフォームを構築するには、異なるエンジン間の書き込みパターンと読み取りパフォーマンスの関係を理解することが不可欠です。 目標は、データ プロデューサーが、コンシューマーが Spark、SQL 分析エンドポイント、Power BI Direct Lake、Warehouse のいずれを使用しているかに関係なく、ダウンストリーム コンシューマーの読み取りパフォーマンスを最適化するテーブル レイアウトを確実に作成することです。

シナリオ マトリックスの書き込みと読み取り

次の表は、一般的な書き込みと読み取りの組み合わせに予想されるパフォーマンス特性と、推奨される最適化戦略をまとめたものです。 このマトリックスを使用して、シナリオを特定し、関連するガイダンスを理解します。

Write メソッド 読み取りエンジン 予想されるギャップ 推奨される戦略
Sparkバッチ処理 Spark ギャップなし 既定の Spark 書き込み構成 で十分です
「Spark」バッチ SQL 分析エンドポイント ギャップなし 自動圧縮と書き込みの最適化を有効にする
Spark ストリーミング Spark 小さいファイルが可能 スケジュールされた OPTIMIZE を用いた自動圧縮および最適化された書き込み
Spark ストリーミング SQL 分析エンドポイント 小さいファイルとチェックポイント 自動圧縮、最適化書き込み、分割メダリオン階層
倉庫 Spark ギャップなし システム管理の最適化 でレイアウトが処理される
倉庫 SQL 分析エンドポイント ギャップなし システム管理の最適化 でレイアウトが処理される

エンジン別の最適なファイル レイアウト

消費エンジンによって、最適なファイル レイアウトが異なります。 これらのターゲットを理解することは、書き込み操作とメンテナンス ジョブを適切に構成するのに役立ちます。

SQL 分析エンドポイントと Fabric Data Warehouse のガイダンス

SQL 分析エンドポイントと Warehouse で最適なパフォーマンスを実現するには、次の設定を使用します。

  • ターゲット ファイル サイズ: ファイルあたり約 400 MB
  • 行グループ のサイズ: 行グループあたり約 200 万行
  • V オーダー: 読み取りパフォーマンスを 10% 向上

倉庫では、次の条件を使用して圧縮候補を検出します。

  • テーブル ファイルのオーバーヘッドが 10% を超えています
  • 論理的に削除されたテーブルの行が 10% を超えています
  • テーブル サイズが 1,024 行を超えています

圧縮の実行中に、プロセスは次の条件に基づいて候補を選択します。

  • 任意のファイルが理想的なサイズの 25% より小さい (行数に基づく)
  • 削除された行が 20% を超えるファイルがある

Spark

Spark は、さまざまなファイル サイズを読み取るときに堅牢です。 最適なパフォーマンスを得る場合:

  • ターゲット ファイル サイズ: テーブル サイズに応じて 128 MB から 1 GB
  • 行グループ のサイズ: 行グループあたり 100 万から 200 万行
  • V オーダー: Spark の読み取りパフォーマンスには必要ありません (15 から 33% 書き込みオーバーヘッドを追加できます)

Spark 読み取りでは、テーブル サイズに基づいて自動的に調整される アダプティブ ターゲット ファイル サイズの利点があります。

  • 10 GB 未満のテーブル: 128 MB ターゲット
  • 10 TB を超えるテーブル: 最大 1 GB のターゲット

Power BI Direct Lake

Direct Lake のパフォーマンスを最適化する場合:

  • ターゲット行グループのサイズ: 最適なパフォーマンスを得るための行グループあたり 800 万行以上
  • V オーダー: コールド キャッシュ クエリでの 40 から 60% の改善に不可欠
  • ファイル数: コード変換のオーバーヘッドを減らすためにファイル数を最小限に抑える
  • 一貫性のあるファイル サイズ: 予測可能なクエリ パフォーマンスに重要

Direct Lake セマンティック モデルは、次の場合に最適に動作します。

  • 列データは、VertiPaq と互換性のある圧縮用に V オーダーです
  • 行グループは、効率的なディクショナリのマージに十分な大きさです
  • 削除ベクトルは、通常の圧縮によって最小化されます

詳細については、「 Direct Lake クエリのパフォーマンスについて」を参照してください。

ミラーリング

ミラーリングでは、テーブルボリュームに基づいてファイルのサイズが自動的に設定されます。

テーブルのサイズ 行グループあたりの行数 ファイルあたりの行数
小 (最大 10 GB) 200 万 1,000 万
中 (10 GB から 2.56 TB) 400 万 6000万
大 (2.56 TB を超える) 800 万 8000万

書き込みパターンと構成

Spark 書き込みパターン

Spark 書き込みでは、次の既定の構成が使用されます。

コンフィギュレーション 既定値 Description
spark.microsoft.delta.optimizeWrite.fileSize 128 MB 最適化された書き込みのターゲット ファイル サイズ
spark.databricks.delta.optimizeWrite.enabled プロファイルによって異なります 自動ファイル結合を有効にします
spark.databricks.delta.autoCompact.enabled Disabled 書き込み後の圧縮を有効にします
spark.sql.files.maxRecordsPerFile 無制限 ファイルあたりの最大レコード数

ダウンストリーム SQL を使用するように Spark 書き込みを構成するには:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

リソース プロファイルとその既定値の詳細については、「リソース プロファイル構成の 構成」を参照してください。

倉庫書き込みパターン

Warehouse では、書き込み中にデータ レイアウトが自動的に最適化されます。

  • V オーダーは、読み取り最適化のために既定で有効になっています。
  • 自動圧縮はバックグラウンド プロセスとして実行されます。
  • チェックポイント管理は自動的に処理されます。

ウェアハウスでは、手動操作なしで SQL の使用に最適化されたファイルが生成されます。 ウェアハウスによって書き込まれたテーブルは、本質的に SQL 分析エンドポイントと Warehouse 読み取りの両方に最適化されています。

テーブルのメンテナンス操作

OPTIMIZE コマンド

OPTIMIZE コマンドは、小さなファイルを大きなファイルに統合します。

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Important

OPTIMIZE コマンドは Spark SQL コマンドです。 ノートブック、Spark ジョブ定義、Lakehouse メンテナンス インターフェイスなどの Spark 環境で実行する必要があります。 SQL 分析エンドポイントと Warehouse SQL クエリ エディターでは、このコマンドはサポートされていません。

詳細については、「テーブル圧縮 」を参照してください。

自動圧縮

自動圧縮では、各書き込み操作の後にパーティションの正常性が自動的に評価され、ファイルの断片化が検出されたときに同期最適化がトリガーされます。

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

手動スケジュールを回避し、ファイルを自動的に圧縮し続けるために、頻繁に小さな書き込み (ストリーミングまたはマイクロバッチ) を含むインジェスト パイプラインに自動圧縮を使用します。

自動圧縮と書き込みの最適化は、通常、一緒に使用すると最適な結果が得られます。 書き込みを最適化すると、書き込まれる小さなファイルの数が減り、自動圧縮によって残りの断片化が処理されます。

詳細については、「 自動圧縮」を参照してください。

書き込みの最適化

書き込みを最適化すると、書き込み前圧縮を実行することでファイルのオーバーヘッドが小さくなり、生成されるファイルが少なくなります。

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

書き込みの最適化は、次の場合に役立ちます。

  • パーティション化されたテーブル
  • 小さな挿入が頻繁に行われるテーブル
  • 多くのファイルに触れる操作 (MERGE、 UPDATE、 DELETE)

書き込み前圧縮 (書き込みの最適化) は、通常、書き込み後の圧縮 (最適化) よりもコストが低くなります。 詳細については、「 書き込みの最適化」を参照してください。

VACUUM コマンド

VACUUM コマンドは、Delta テーブル ログが参照しなくなった古いファイルを削除します。

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

既定の保持期間は 7 日に設定されています。 保持期間を短く設定すると、Delta のタイム トラベル機能に影響し、同時閲覧者またはライターに問題が発生する可能性があります。

詳細については、 Lakehouse テーブルのメンテナンスを参照してください。

V-オーダーの最適化

V オーダーは、VertiPaq と互換性のある並べ替え、エンコード、および圧縮を Parquet ファイルに適用する書き込み時の最適化です。

  • Power BI Direct Lake: コールド キャッシュ クエリでの 40 から 60% の改善
  • SQL 分析エンドポイントとウェアハウス: 約 10% 読み取りパフォーマンスの向上
  • Spark: 固有の読み取り利点はありません。15 から 33% 低速書き込み

V オーダーを有効にするタイミング

V オーダーには、次の利点があります。

  • Power BI Direct Lake を提供するゴールドレイヤー テーブル
  • SQL 分析エンドポイントを通じて頻繁に照会されるテーブル
  • 書き込みパフォーマンスの重要度が低い読み取り負荷の高いワークロード

V オーダーを回避するタイミング

V オーダーを無効にすることの検討をしてください。

  • インジェスト速度に重点を置いたブロンズレイヤー テーブル
  • SQL と Power BI がデータを使用しない Spark から Spark へのパイプライン
  • データ待機時間が重要な書き込み負荷の高いワークロード

V オーダーを設定する

V オーダーは、新しい Fabric ワークスペースでは既定で無効になっています。 有効にするには、次の手順を実行します。

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Direct Lake の使用量に基づいて V オーダーを選択的に適用するには、Direct Lake セマンティック モデルで使用されるテーブルの V オーダー有効化を自動化することを検討してください。 Direct Lake で使用されないテーブルは、書き込みパフォーマンスを向上させるために V オーダーなしで残ることができます。

詳細については、「Delta Lake テーブルの最適化と V オーダー」を参照してください。

液体クラスタリングと Z オーダー

液体クラスタリング

Liquid Clustering は、データ編成に推奨されるアプローチです。 従来のパーティショニングとは異なり、Liquid Clustering:

  • クエリ パターンの変更に適応
  • クラスタリングを適用するには OPTIMIZE が必要です
  • フィルター処理されたクエリのファイル スキップの改善を提供します

テーブル作成時に Liquid Clustering を有効にする:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z オーダー

Z オーダーでは、関連するデータが同じファイルに併置されるため、フィルター述語のクエリ パフォーマンスが向上します。

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Z オーダーは次の場合に使用します。

  • Liquid Clustering はパーティション分割されたテーブルでは機能しないため、テーブルはパーティション分割されています。
  • クエリでは、多くの場合、2 つ以上の列をフィルター処理します。
  • 述語は選択性が高いため、ファイルのスキップによる利点を十分に活用できます。

Medallion アーキテクチャの推奨事項

medallion アーキテクチャ (ブロンズ、シルバー、ゴールド レイヤー) は、各レイヤーの目的に基づいてテーブルのメンテナンス戦略を最適化するためのフレームワークを提供します。

ブロンズレイヤー(ランディングゾーン)

Bronze テーブルは、書き込み性能と低遅延のデータ取り込みに重点を置いています。

  • 最適化の優先順位: 読み取りパフォーマンスに対するインジェスト速度
  • パーティション分割: 新しい実装では許容できますが、推奨されません
  • 小さいファイル: 取り込み速度に焦点を当てているので受け入れ可能
  • V オーダー: 推奨されません (書き込みオーバーヘッドが追加されます)
  • 自動圧縮: 小さなファイルを減らすことができますが、インジェスト速度のために犠牲にすることができます
  • 削除ベクトル: マージ パターンを持つテーブルに対して有効にする

ブロンズ テーブルは、SQL 分析エンドポイントまたは Power BI Direct Lake コンシューマーに直接提供しないでください。

シルバー レイヤー (キュレーション ゾーン)

Silver テーブルでは、書き込みと読み取りのパフォーマンスのバランスが取られます。

  • 最適化の優先順位: インジェストとクエリのパフォーマンスのバランス
  • ファイル サイズ: 書き込み操作と読み取り操作の両方をサポートするようにモデレート (128 ~ 256 MB)
  • V オーダー: 省略可能。SQL 分析エンドポイントまたは Power BI の消費量が大きい場合に有効にする
  • Liquid Clustering または Z オーダー: クエリのパフォーマンスを向上させるために推奨
  • 自動圧縮と書き込みの最適化: ダウンストリームの要件に基づいて有効にする
  • 削除ベクトル: 頻繁に更新されるテーブルに対して有効にする
  • スケジュールされた OPTIMIZE: ファイル レイアウトを維持するために積極的に実行する

ゴールド レイヤー (サービング ゾーン)

ゴールド テーブルは、エンド ユーザーが使用するための読み取りパフォーマンスに優先順位を付けます。

  • 最適化の優先順位: 分析の読み取りパフォーマンス
  • ファイル サイズ: SQL と Power BI の最適なパフォーマンスを実現するために大きい (400 MB から 1 GB)
  • V オーダー: Power BI Direct Lake に必要です。SQL 分析エンドポイントに役立つ
  • 液体クラスタリング: 最適なファイル スキップに必要
  • 書き込みの最適化: 一貫性のあるファイル サイズに必要
  • スケジュールされた OPTIMIZE: 最適なレイアウトを維持するために集中的に実行する

主消費エンジンに基づいて異なる方法でゴールド テーブルを最適化します。

消費エンジン V オーダー ターゲット ファイル サイズ 行グループのサイズ
SQL 分析エンドポイント イエス 400 MB 200 万行
Power BI Direct Lake イエス 400 MB から 1 GB 800 万行以上
Spark オプション 128 MB から 1 GB 1 ~ 200 万行

複数のテーブル複製

異なる消費パターンに合わせて最適化されたテーブルの複数のコピーを保持することは許容されます。

  • Spark 処理用に最適化された Silver テーブル
  • SQL 分析エンドポイントと Power BI Direct Lake 用に最適化された Gold テーブル
  • 各レイヤーに適切な構造を変換して配置するデータ パイプライン

ストレージはコンピューティングに比べて安価です。 使用パターンに合わせてテーブルを最適化すると、1 つのテーブル レイアウトからすべてのコンシューマーにサービスを提供するよりも、ユーザー エクスペリエンスが向上します。

テーブルの正常性を特定する

テーブルを最適化する前に、現在のテーブルの正常性を評価して、最適化のニーズを理解します。

Parquet ファイルを直接検査する

OneLake のテーブル フォルダーを参照して、個々の Parquet ファイルのサイズを調べることができます。 正常なテーブルには、均等に分散されたファイル サイズがあります。 検索対象:

  • 一貫性のあるファイル サイズ: ファイルのサイズはほぼ同じである必要があります (互いの 2 倍以内)。
  • 非常に小さいファイルはありません:25 MB 未満のファイルは断片化を示します。
  • 非常に大きなファイルはありません:2 GB を超えるファイルは並列処理を減らすことができます。

ファイル サイズの分布が不均一な場合は、多くの場合、異なるジョブ間で圧縮が不足しているか、書き込みパターンに一貫性がないことを示します。

Spark SQL での DRY RUN の最適化

圧縮を実行せずに最適化の対象となるファイルをプレビューするには、 DRY RUN オプションを使用します。

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

このコマンドは、最適化時に書き換えられるファイルの一覧を返します。 これを使用して次の操作を行います。

  • 最適化を実行する前に、そのスコープを評価します。
  • テーブルを変更せずにファイルの断片化を理解する。
  • 影響を受けるファイルの数に基づいて最適化時間を見積もる。

ファイル サイズの分布

ファイルのサイズと分布を分析するには、次の方法を使用します。

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

テーブルの先頭に近いファイルや特定のパーティションのファイルが最適化されない可能性があるため、ディストリビューションが歪む可能性があります。

テーブルのパーティション分割キーまたはクラスタリング キーによってグループ化するクエリを実行することで、分散を評価できます。

最適化のニーズを決定する

従量課金エンジンに基づいて、実際のファイル サイズとターゲット サイズを比較します。

Engine ターゲット ファイル サイズ ファイルが小さい場合 ファイルが大きい場合
SQL 分析エンドポイント 400 MB OPTIMIZE を実行します。 ファイルは受け入れ可能
Power BI Direct Lake 400 MB から 1 GB OPTIMIZE VORDER を実行します。 ファイルは受け入れられます
Spark 128 MB から 1 GB 自動圧縮を有効にする ファイルは受け入れられます。

テーブル履歴とトランザクション ログ

テーブル履歴を確認して、書き込みパターンとメンテナンス頻度を理解します。

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

構成のベスト プラクティス

セッション構成でテーブルのプロパティを使用する

テーブルのプロパティはセッション間で保持され、すべてのジョブとライターで一貫した動作が保証されます。

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

セッション レベルの構成は現在の Spark セッションにのみ適用され、異なるセッションで異なる構成が使用されている場合は、一貫性のない書き込みが発生する可能性があります。

アダプティブ ターゲット ファイル サイズを有効にする

アダプティブ ターゲット ファイル サイズでは、テーブル サイズに基づいてファイル サイズターゲットが自動的に調整されます。

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

この機能を使用すると、次のことが可能になります。

  • 小さいテーブルの場合は、小さいファイル (128 MB) から始まります
  • 10 TB を超えるテーブルで最大 1 GB にスケールアップ
  • OPTIMIZE操作中に自動的に再評価する

ファイル レベルの圧縮ターゲットを有効にする

ターゲット サイズが変更されたときに、以前に圧縮されたファイルの書き換えを防止します。

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

推奨事項の概要

レイヤー 自動圧縮 最適化書き込み V オーダー 液体クラスタリング スケジュールされた最適化
銅 有効にする (省略可能) Enable いいえ いいえ オプション
銀 Enable Enable オプション イエス Aggressive
金 Enable Enable イエス イエス Aggressive

特定のシナリオでは、次の推奨事項を使用します。

  • Spark-to-Spark: ファイル サイズの最適化に重点を置く。V オーダー（オプション）。
  • Spark-to-SQL: optimize-write と auto-compaction を有効にします。は、200 万行グループの 400 MB ファイルを対象とします。
  • ストリーミング インジェスト: 自動圧縮を有効にする。SQL コンシューマーの追加の OPTIMIZE ジョブをスケジュールします。
  • Power BI Direct Lake: V オーダーを有効にする。800万以上の行グループをターゲットとする。 OPTIMIZE VORDERを実行します。

関連するコンテンツ

  • Last updated on