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

Microsoft Fabricのデルタテーブルは、OneLakeに保存されたデータからSpark、SQL分析エンドポイント、Power BI Direct Lake、Warehouse、その他のFabric体験にサービスを提供します。最適なクロスワークロードパフォーマンスは、以下の2つの要因に依存します。

テーブルの作成と維持にかかる作業量です。
テーブルを飲み込むエンジンたち。

レイクハウステーブルは通常、Spark、Fabric pipeline Copy アクティビティ、またはDataflow Gen2によって管理されます。 Sparkは最も一般的なライターであり、最も広範なレイアウトとメンテナンス管理を提供します。ウェアハウスやデータベースミラーリングは物理的なレイアウトを自動的に管理します。ミラーカタログはソースシステムで管理されたレイアウトを保持します。消費者向けの要件は概ね互換性がありますが、Power BI Direct Lakeには最適なパフォーマンスのために追加のストレージ要件があります。

要件が一致するときは、共有テーブルを一つ使うのが良いです。別のテーブルを正当化する例外については、「いつ別のテーブルを作成するか」を参照してください。

レイアウト所有権を理解する

まずは、どのワークロードが物理テーブルレイアウトを所有しているかを特定しましょう。以下の表の制御は、クロスワークロードのテーブルレイアウトや保守に関連する主要な制御であり、各エンジンの能力の網羅的なリストではありません。

データストア	ライターまたは取り込み方法	レイアウトと保守の担当	キーコントロール
Lakehouse	Spark	ユーザー管理型	ファイルサイズ:適応型ターゲットファイルサイズおよびファイルレベルのコンパクトターゲット。書き込みとメンテナンス:削除ベクター、自動コンパクト、書き込みの最適化、`OPTIMIZE`、`VACUUM`。データ整理: リキッドクラスタリング、パーティショニング、 Zオーダー、 Vオーダー。
Lakehouse	Fabric パイプラインのコピーアクティビティまたは Dataflow Gen2	サービスがデータを書き込みます。湖畔の家の持ち主がテーブルを管理しています	宛先固有の書き込み設定。 Spark、 Lakehouseメンテナンス、またはパイプラインメンテナンスアクティビティを使って、互換性のあるメンテナンスを別途実行してください。
倉庫	Fabric Data Warehouse、Fabric パイプラインのコピーアクティビティ、または Dataflow Gen2	倉庫管理	データクラスタリングと倉庫レベルのV-Order設定。
ミラードアイテム	ミラーサービス	ミラーリングの種類によります	データベースミラーリングは、直接的なレイアウト制御を持たないシステム管理のV-オーダード・デルタレイアウトを使用します。ミラーカタログはソースファイルのレイアウトを保持し、サポートがあればソースシステムで最適化できます。

ワークロード横断ガイダンス

以下の表は、生産者と消費者による推奨アプローチをまとめたものです。

Producer	Consumer	推奨される方法
レイクハウス:スパークライター	Spark	Fabric Spark ランタイム2.0以降のデフォルト設定を使用し、自動圧縮を有効にしてください。測定対象の述語でリキッドクラスタリングによるファイルスキップの向上が見込める場合は、それを検討してください。
レイクハウス:スパークライター	SQL 分析エンドポイント	Sparkで推奨されているレイアウトと同じものを使うのが良いです。 SQL分析エンドポイントのパフォーマンスだけのために、静的な目標ファイルサイズや任意の行制限、 V-Order を設定しないでください。
レイクハウス:スパークライター	Power BI ダイレクトレイク	Sparkで推奨されているレイアウトと同じものを使用し、さらに V-Orderを有効にするか、 `readHeavyForPBI` リソースプロファイルを使うと良いでしょう。
Lakehouse: Fabric パイプラインまたは Dataflow Gen2 ライター	Spark、SQL分析エンドポイント、またはPower BI Direct Lake	結果として得られるファイルレイアウトを監視し、対応する湖畔ハウスのメンテナンスを別途スケジュールしてください。 Dataflow Gen2のインクリメンタルリフレッシュのような一部の宛先モードは保守制限を課します。
倉庫	Fabric Data Warehouseまたはスパーク	システム管理レイアウトを使いましょう。 Fabric Data Warehouse自動的に締固めやその他のメンテナンスを管理します。データクラスタリングを使って、選択的述語が繰り返されるワークロードのファイルスキップを改善しましょう。
倉庫	Power BI ダイレクトレイク	デフォルトのWarehouse V-Order設定を維持してください。共有クエリパターンに有利な場合はデータクラスタリングを活用しましょう。
ミラーリング	Spark、SQL分析エンドポイント、またはPower BI Direct Lake	データベースミラーリングには、システム管理のV-Ordered Deltaレイアウトを使用します。ミラーカタログの場合は、サポートに応じてソースシステム内の基礎ファイルを最適化してください。「Fabricにおけるミラーリングとは何か?」をご覧ください。

Lakehouseテーブルの最適化

Lakehouse Deltaのテーブルは、Spark、Pipeline Copy アクティビティ、Dataflow Gen2のいずれかが書き込む場合でも、明示的な保守戦略が必要です。 Sparkはこのセクションの主な例であり、Fabricで最も広範なレイアウトおよびメンテナンス管理を提供しています。

Important

テーブルのメンテナンスは、エンジン間で最適な書き込み・読み込み性能を得るために不可欠です。メンテナンスなしで最初は良好に動作する追加専用ワークロードでさえ、過剰な小さなファイルが蓄積され、Spark、SQL分析エンドポイント、Direct Lake、外部データリーダーに影響を及ぼします。自動および手動の圧縮方法については、Compacting Delta tables を参照してください。

Sparkのランタイムデフォルトを使います

Sparkがテーブルを書く際は、Fabric Spark runtime 2.0以降のデフォルトを使用してください:

適応ターゲットファイルサイズを有効にしておきましょう。各テーブルに対して128MBから1GBまでのターゲットを自動的に選択します。
ファイルレベルのコンパクト化ターゲットを有効にして、以前の適応ターゲットを満たすファイルを書き換えないようにしましょう。
削除ベクターを有効にしておきましょう。
ファイルあたりの行数を恣意的に設定しないでください。行幅は変動するため、行制限は狭いテーブルに対して過剰な小さなファイルを作ることがあります。

Fabric Spark 1.3のランタイムでは、適応型ターゲットファイルサイズ、ファイルレベルのコンパクト化ターゲット、削除ベクターがオプトイン設定として利用可能です。

Pipeline Copy アクティビティまたは Dataflow Gen2 がテーブルを書き込む際には、得られたファイルレイアウトを個別に確認し、メンテナンスをスケジュールしてください。これらのライターがSparkのランタイムデフォルトを適用しているとは限りません。

Fabric パイプラインでは、書き込み後に Lakehouse メンテナンスアクティビティをオーケストレーションできます。

Important

インクリメンタルリフレッシュを使うDataflow Gen2のレイクハウス宛先は、 OPTIMIZE や REORG TABLEをサポートしていません。 Dataflow Gen2のインクリメンタルリフレッシュの制限に従ってください。

小さなファイルの発生を防ぎ、統合する

Sparkで書かれたテーブルの場合は、自動コンパクト化を好みます。この機能は書き込み後にテーブル断片化を評価し、必要な時のみコンパクト化を実行します。これにより、メンテナンス実行前に別途テーブルの健康チェックを行う必要がなくなりました。

例外および補完的な機能については以下のガイダンスをご利用ください:

Scenario	推奨される方法
Spark で書き込まれたテーブル	自動圧縮をデフォルトのメンテナンス戦略として有効にしてください。
ストリーミングまたはマイクロバッチ書き込み	自動コンパクトを有効にし、書き込みを最適化して小ファイル蓄積を減らすことができます。
厳格な書き込み遅延要件を持つワークロード	同期`OPTIMIZE`を実行する代わりに、別にスケジュールします。
蓄積された小さなファイルを含む既存のテーブル	一度きりのメンテナンス `OPTIMIZE`を実行し、その後オートコンパクションを有効にして継続的なメンテナンスを行ってください。
頻繁に更新、削除、またはマージが行われるテーブル	削除ベクターと自動コンパクト化を有効にしてください。

OPTIMIZE ファイルを圧縮し、5% 以上のレコードが削除ベクターによって参照された場合、ファイルの削除ベクターを自動的にパーグします。 REORG TABLE ... APPLY (PURGE)その閾値以下の記録を物理的に削除する必要がある場合や、特定のコンプライアンス要件を満たす場合にのみ使用してください。

Note

オートコンパクトは、分割が小ファイルトリガーにも合致した場合にのみ削除ベクトルを消去します。ワークロードが小さなファイルを生成せずに更新や削除を行う場合は、定期的に条件付きの削除ベクトルを消去するために OPTIMIZE を実行してください。物理的な浄化を強制しなければならない時には REORG TABLE ... APPLY (PURGE) を使え。

保持期間終了後に参照されていないファイルを削除するために別のスケジュールで VACUUM を実行してください。 VACUUM ストレージは取り戻しますが、アクティブなファイルレイアウトは改善しません。

Warnung

タイムトラベルの要件や同時読者・執筆者数を評価せずに、 VACUUM の保持期間を短くしないでください。ファイルを早期に削除しすぎると、必要なテーブルバージョンが利用できなくなることがあります。

ファイルスキップのためのデータを整理する

繰り返し発生するフィルタリングや処理パターンで、向上したファイルスキップの効果が見込める場合は、リキッドクラスタリングを使用してください。リキッドクラスタテーブルは、新しく書かれたデータを整理するために OPTIMIZEまたは自動圧縮が必要です。

デフォルトでパーティション設定は避けてください。特定の要件が操作上のトレードオフを正当化する場合、例えば互いに異なるパーティション間でデータを更新、削除、マージする同時ライターを隔離する場合などに利用してください。詳細については、「パーティショニングを使用する場合」をご覧ください。

既存の分割テーブルについては、選択的述語がパーティション内の同じ列をフィルタリングすることが多い場合の Z順序を考えます。

倉庫管理テーブルの最適化

Fabric Data Warehouseインジェスティング方法に関わらず物理的なDeltaテーブルのレイアウトを管理します。

Warehouseが提供する戦略的コントロールを活用してデータレイアウトを調整しましょう:

同じ列に対して選択的述語を繰り返し使用する場合、大きなテーブルにデータクラスタリングを適用してください。
読み取り指向および混合ワークロード向けに V-Order を有効にしてください。 V-Orderはデフォルトで有効です。
書き込み集約型のウェアハウスワークロード用に V-Orderを無効にすることを検討してください。

Warnung

V-Orderの無効化は倉庫レベルで不可逆的な操作です。無効化する前に、すべての読み書きワークロードをテストしてください。

Warehouse の詳細については、Fabric Data Warehouse のパフォーマンスガイドラインを参照してください。

ミラーデータの最適化

物理レイアウトを改善するかどうかは、Fabricがデータを再現するか、ソースファイルを参照するかに依存します。

データベースミラーリング:FabricはOneLakeのDeltaテーブルにソースデータを複製し、V-Orderedファイルのレイアウトと保守を管理します。ターゲットファイルサイズ、削除ベクターのクリーンアップ、リキッドクラスタリング、パーティション、V-Orderをミラードデスティネーション上で直接設定することはできません。
ミラーカタログ:Fabricはメタデータを同期し、OneLakeのショートカットを使ってソースデータをその場で参照します。 Fabricはこれらのファイルを書き換えたり管理したりしません。サポート機能が許す場合は、ソースシステムの物理レイアウトとクリーンアップを改善しましょう。これらの変更は、Fabric で別のコピーを作成することなく、ショートカットを通じて確認できます。

データベースミラーデータの場合:

選択的述語を使用し、SparkやSQLクエリで不要な列を避けましょう。
効率的なDirect Lake消費のためにPower BIセマンティックモデルとDAX指標を設計します。

ミラーカタログの場合:

ソースプラットフォームのサポートテーブルメンテナンスおよびレイアウト機能を活用してください。
ショートカットをクエリするFabric利用者のソースファイルと行グループの分布を評価してください。
Direct Lakeでは、ソースレイアウトが性能要件を満たせない場合、追加の次元モデル化されたV-オーダードサービングレイヤーを作成することを検討してください。

ミラーリングの概念、型、サポートされるソースについては、「Fabricにおけるミラーとは何か?」および「メタデータミラーリングの仕組み」を参照してください。

消費者特化最適化を適用する

SparkとSQLの分析エンドポイントは同じアダプティブレイクハウスレイアウトで良好に動作します。適応型ターゲットファイルサイズを使用し、過度な小ファイルを防ぎ、測定述語がファイルスキップの改善を受けた場合はリキッドクラスタリングを適用します。 SparkやSQLの分析エンドポイントのパフォーマンスだけのために V-Order を有効にしないでください。エンジン固有の詳細は、 SQL分析エンドポイントのパフォーマンスに関する考慮事項を参照してください。

Power BI ダイレクトレイク

Direct Lakeは同じ基盤となるDeltaテーブルを使用しますが、トランスコーディングやインクリメンタルフレーミングに関する推奨事項を追加します。

ファイルおよび行グループのレイアウト:小さな行グループや行グループの分布の不均一を避けると、VertiPaqの列セグメントが増え、トランスコーディングのオーバーヘッドが増加します。
V-オーダー: クロスワークロードガイダンスの生産者固有の推奨に従います。主にDirect Lakeで消費されるSparkで作成されたテーブルについては、 V-Order を有効にするか readHeavyForPBI リソースプロファイルをご利用ください。
更新パターン:可能な限り、既存のParquetファイルを保持し、インクリメンタルフレーミングをサポートするために、付録に適した更新パターンを優先してください。

Note

Direct Lakeは一般的に100万から1600万行の行グループで最も良いパフォーマンスを示します。対応生産者設定を変更する前に、行群分布とダイレクトレイクのパフォーマンスを評価してください。

Sparkで書かれたテーブルの場合、spark.sql.parquet.native.writer.maxRowGroupRowCountネイティブ実行エンジンがParquetファイルを書き込む際に、1行あたりの最大行数を設定します。デフォルト値は 0であり、最大値を課すわけではありません。分析で行グループサイズがDirect Lakeのパフォーマンスに影響を与えていることが判明した場合は、テーブルを書き換える前にテスト済みの上限を設定してください。例えば次が挙げられます。

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

特定の行数を達成するためだけに制限を設定しないでください。行幅、圧縮、ファイル分布、容量並列処理もパフォーマンスに影響を与えます。 Delta Analyzerを使って結果的なレイアウトを評価してください。

フレーミング、トランスコーディング、行グループ、更新パターン、デルタアナライザーの詳細については、「 Understand Direct Lakeクエリパフォーマンス」をご覧ください。

メダリオン層にガイダンスを適用してください

ブロンズ、シルバー、ゴールドはデータの目的と洗練を表しています。レイアウトがユーザー管理かシステム管理かを決めるわけではなく、各消費者ごとに別々のコピーを要求するわけでもありません。

レイヤー	主な目標	ワークロード横断ガイダンス
ブロンズ(着地)	ソースの忠実度とインジェスループットの維持	書き込みスループットを優先しつつ、Sparkで書かれたテーブルを自動コンパクト化で維持します。モデルやデータ形状が意図的にその用途に設計されていない限り、生のブロンズテーブル上でPower BI Direct Lakeセマンティックモデルを使うのは避けてください。
シルバー（厳選）	再利用のために検証済み、適合したデータを提供すること	テーブルは互換性のあるFabricコンシューマー間で再利用してください。 Sparkで作成されたレイクハウステーブルでは、Direct Lakeがプライマリーユーザーである場合にのみ V-Order を有効にしてください。
ゴールド（提供中）	ビジネス対応の寸法、事実、集計、分析モデルを提供します	Direct Lakeのセマンティックモデルにはこのレイヤーを好む。このテーブルを互換性のある消費者間で再利用し、この記事で説明した生産者固有の管理を適用してください。

レイアウトとメンテナンスの問題を解決する

生産者意識型の修復を活用しましょう。スパークのメンテナンスコマンドを、宛先モードがこれらの操作をサポートする場合は、湖のテーブルに適用してください。信号を普遍的な閾値ではなく指標として扱い、テーブルの書き込みパターンや消費者のパフォーマンスに対して検証してください。

条件	信号	レイクハウステーブル	倉庫表
過剰な小さなファイル	ファイル数はアクティブなテーブルサイズよりも速く増加し、ファイルは適応目標を下回るままです。	Sparkでは、既存のバックログに対して一度限りの `OPTIMIZE` を実行し、その後自動圧縮を有効にします。 Pipeline Copy アクティビティまたは Dataflow Gen2 による書き込みの場合は、サポート対象の Lakehouse メンテナンスを個別にスケジュールしてください。	アクションなし。倉庫の圧縮は自動です。
レガシーのオーバーサイズファイル	ファイルは現在の適応ターゲットよりもはるかに高く、ファイル数が少なすぎると走査並列性が制限されます。	上書きまたはを使用し、`CREATE OR REPLACE TABLE AS SELECT` を有効にしてテーブルを書き換えます。	アクションなし。 Warehouseはファイルサイズを自動的に管理します。
欠失ベクトル蓄積	`DESCRIBE HISTORY`メトリクスは、削除ベクターがコンパクションによって削除されるよりも速く追加または更新されていることを示しており、読み取りオーバーヘッドが増加する可能性があります。	自動圧縮は有効にしてください。欠失ベクトルが小ファイルの圧縮をトリガーせずに蓄積した場合、 `OPTIMIZE`をスケジューリングします。 `REORG TABLE ... APPLY (PURGE)`は明確なパージ要件にのみ使ってください。	アクションなし。クリーンアップはシステム管理です。
ファイルのスキップ不良	選択的述語はテーブルの大部分をスキャンしたり、クラスタリング品質の評価で組織が不十分であることを示します。	Sparkでは、リキッドクラスタリングを設定するか、既存のパーティションテーブルに対して Z-Order を使用できます。	ウェアハウスデータクラスタリングの設定。
ダイレクトレイクトランスコーディングオーバーヘッド	Delta Analyzerは、過剰なファイル、小さな行グループ、または更新後の広範な再トランスコーディングを示します。	小さなファイルをコンパクトにまとめ、行グループをレビューし、Sparkで書かれたテーブルに V-Order を適用します。オプションとして、Parquetファイル内の圧縮品質を向上させるためにリキッドクラスタリングを設定することも可能です。	V-Orderを有効にしてデータのクラスタリングを評価してください。
参照なしファイルストレージの成長	OneLakeのストレージは、データ変更操作後、アクティブなテーブルサイズよりも速く成長します。	保持要件に従って `VACUUM` を実行します。	アクションなし。クリーンアップはシステム管理です。

ミラーデータについては、 Optimize mirrored dataの生産者固有の修復に従います。データベースミラーリングはシステム管理されます。ミラーカタログの場合は、ソースプラットフォームでサポート済みメンテナンスを適用してください。

レイクハウステーブルでは、Spark でサポートされる検査オプションには次のものがあります:

ファイル数、総サイズ、評価されたdelta.targetFileSize.adaptiveプロパティを確認するためにDESCRIBE DETAILを実行してください。
DESCRIBE HISTORY走って書き込みパターンやメンテナンス履歴を確認しましょう。
詳細なDirect Lake行グループや更新パターン分析が必要な場合は Delta Analyzer を使いましょう。

平均ファイルサイズの検査

テーブルレイアウトの初期指標として、平均ファイルサイズを DESCRIBE DETAIL で計算してください:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

平均はパーティション間や最近のファイル・以前に圧縮されたファイル間の歪みを隠すことができます。平均値がレイアウトの問題の可能性を示している場合は、パーケットの個別ファイルを確認するか、 Delta Analyzer を使って分布を評価してから保守設定を変更してください。

別のテーブルを作成するタイミング

複数のFabricエンジンがデータを消費しているからといって、物理的なテーブルをもう一つ作らないでください。

独立した目的を持つ場合は、次のテーブルを作成します。

データの粒状やビジネスの意味を変える変換や集約。
セキュリティ、保持、データ品質の要件が異なります。
共有テーブルが満たせない遅延やリフレッシュの要件。
消費者特化型レイアウトで、その測定された利益は保管、処理、系譜、ガバナンスコストを上回ります。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-27