Fabric Data Warehouse のパフォーマンスガイドライン

2025-10-14

適用対象:✅ Microsoft Fabric の Warehouse

この記事には、データインジェスト、テーブル管理、データ準備、統計、およびウェアハウスと SQL 分析エンドポイントでのクエリに関するベストプラクティスが含まれています。パフォーマンスのチューニングと最適化には固有の課題がありますが、データソリューションの機能を最大化する貴重な機会も提供します。

ウェアハウスのパフォーマンスを監視するには、「ファブリックデータウェアハウスの監視」を参照してください。

データ型の最適化

適切なデータ型を選択することは、ウェアハウスのパフォーマンスとストレージの効率を高める上で不可欠です。次のガイドラインは、スキーマ設計で高速クエリ、効率的なストレージ、保守容易性を確実にサポートするのに役立ちます。

Fabric Data Warehouse でサポートされるデータ型の詳細については、「Fabric Data Warehouse のデータ型」を参照してください。

ヒント

外部ツールを使用してテーブルやクエリを生成する場合 (コード優先のデプロイ手法など)、列のデータ型を慎重に確認してください。文字データ型の長さとクエリは、次のベストプラクティスに従う必要があります。

データ型をデータセマンティクスに一致させる

明確さとパフォーマンスの両方を確保するには、各列のデータ型を、格納するデータの実際の性質と動作に合わせることが重要です。

一時的な値には、文字列として格納するのではなく、 date、 time、または datetime2(n) を使用します。
書式設定 (先頭のゼロなど) が必要な場合を除き、数値には整数型を使用します。
書式設定を維持することが不可欠な場合は、文字型 (char、 varchar) を使用します (たとえば、0 で始まる数値、積コード、ダッシュ付きの数値)。

整数に整数型を使用する

識別子、カウンター、またはその他の整数などの値を格納する場合は、整数型 (smallint、 int、 bigint) を decimal/numeric よりも優先します。整数型は、小数点の右側の数字を許可するデータ型よりも少ないストレージを必要とします。その結果、より高速な算術演算と比較操作が可能になり、インデックス作成とクエリのパフォーマンスが向上します。

Fabric Data Warehouse でサポートされる各整数データ型の値範囲に注意してください。詳細については、 int、bigint、smallint (Transact-SQL) を参照してください。

小数点以下の桁数と数値の有効桁数、および10進数の使用について検討する

decimal/numericを使用する必要がある場合は、列を作成する際に、データに対応できる最小の精度とスケールを選択してください。過剰プロビジョニングの精度により、ストレージ要件が増加し、データの増加に伴ってパフォーマンスが低下する可能性があります。

倉庫の期待される成長とニーズを予測します。たとえば、小数点の右側に 4 桁以下の桁数を格納する場合は、最も効率的なストレージに decimal(9,4) または decimal(19,4) を使用します。
10 進数/列を作成するときは、常に有効桁数と小数点以下桁数を指定してください。 decimalを指定せず(p,s)として定義されたテーブルで作成すると、10進数/列がとして作成されます。有効桁数が 18 の 10 進数では、1 行あたり 9 バイトのストレージが消費されます。 0の小数点以下桁数では、小数点の右側にデータが格納されません。多くのビジネス整数、 smallint、 int、 bigint は、 decimal(18,0)よりもはるかに効率的です。たとえば、9 桁の整数は、1 行あたり 4 バイトのストレージの整数データ型として格納できます。

詳細については、 10 進数と数値 (Transact-SQL) を参照してください。

varchar over char を使用するタイミングを検討する

固定長の埋め込みが明示的に必要な場合を除き、文字列列には char(n) の代わりに varchar(n) を使用します。 varchar 列には、行あたりの実際の文字列長と小さなオーバーヘッドのみが格納され、無駄な領域が削減され、I/O 効率が向上します。

広く変数値があるため、名前、アドレス、説明などの値には varchar(n) を使用します。データ型の長さが実際のデータに対してより正確である場合、統計とクエリコストの見積もりはより正確になります。
文字列が毎回固定長になることがわかっている場合は、 char(n) を使用します。たとえば、文字列000000000を char(9) として格納することは、文字列が常に 0 から始まる正確な 9 個の数字である場合に理にかなっています。
列データ型宣言で n 長さは、ストレージバイトです。 UTF-8 などのマルチバイトエンコード文字セットの場合、Fabric Data Warehouse のエンコード、ラテン文字、数字には 1 バイトのストレージが必要です。ただし、格納に 3 バイトを必要とする日本語文字など、1 バイトを超える Unicode 文字が存在するため、実際に格納される Unicode 文字の数は、データ型の長さ nよりも小さくなります。詳細については、「 char 引数と varchar 引数」を参照してください。

可能な場合は null 許容列を避ける

データモデルで許可されている場合は、列を NOT NULL として定義します。既定では、テーブル内の列で NULL 値を使用できます。 Null 値を許容する列には、次の特性があります。

メタデータのオーバーヘッドが増えます。
クエリの最適化と統計の有効性を低下させることができます。
大規模な分析クエリのパフォーマンスに影響を与える可能性があります。

データウェアハウスへのデータ取り込みと準備作業

コピーへの挿入

T-SQL COPY INTO コマンドは、Azure Data Lake Storage から Fabric Data Warehouse にデータを取り込む場合に推奨される方法です。詳細と例については、「 COPY ステートメントを使用してウェアハウスにデータを取り込む」を参照してください。

最適なパフォーマンスを得るための次の推奨事項を検討してください。

ファイルサイズ: 最大スループットを実現するために、取り込む各ファイルが 100 MB から 1 GB の間が理想的であることを確認します。これにより、インジェストプロセスを最適化し、パフォーマンスを向上させることができます。
ファイルの数: 並列処理とクエリのパフォーマンスを最大化するには、多数のファイルを生成することを目指します。最小ファイルサイズ 100 MB を維持しながら、できるだけ多くのファイルを作成することに優先順位を付けます。
並列読み込み: 複数の COPY INTO ステートメントを並列で実行して、データを異なるテーブルに読み込みます。この方法では、並列処理により ETL/ELT ウィンドウを大幅に削減できます。
容量サイズ: より大きなデータボリュームの場合は、より大きなファブリック容量にスケールアウトして、追加の並列処理とより大きなデータボリュームに対応するために必要な追加のコンピューティングリソースを取得することを検討してください。

Fabric Data Warehouse では、BULK INSERTのシノニムである COPY INTO ステートメントもサポートされています。 BULK INSERTステートメントにも同じ推奨事項が適用されます。

CTAS または INSERT

CREATE TABLE AS SELECT (CTAS) を使用するか、INSERTSELECT FROM Lakehouse のテーブル/ショートカットコマンドと組み合わせて使用します。これらのメソッドは、パイプラインを使用するよりもパフォーマンスが高く効率的であり、より高速で信頼性の高いデータ転送が可能になります。詳細と例については、「 Transact-SQL を使用してウェアハウスにデータを取り込む」を参照してください。

並列処理の数を増やし、より大きなファブリック容量にスケーリングする概念は、スループットを向上させるために CTAS/INSERT 操作にも適用されます。

OPENROWSET を使用して Azure Data Lake Storage または Blob Storage からデータを読み取る

OPENROWSET 関数を使用すると、Azure Data Lake または Azure Blob Storage から CSV または Parquet ファイルを、Warehouse に取り込まずに読み取ります。詳細と例については、「 OPENROWSET 関数を使用してファイルの内容を参照する」を参照してください。

OPENROWSET 関数を使用してデータを読み取る場合は、最適なパフォーマンスを得るための次の推奨事項を検討してください。

Parquet: ファイルのクエリを頻繁に実行する場合は、CSV ではなく Parquet を使用するか、CSV を Parquet に変換してください。 Parquet は、列形式です。データは圧縮されるため、ファイルサイズは同じデータを含む CSV ファイルよりも小さくなります。 Fabric Data Warehouse では、Parquet ファイルを読み取る場合にクエリで必要ない列と行がスキップされます。
ファイルサイズ: 最大スループットを実現するために、取り込む各ファイルが 100 MB から 1 GB の間が理想的であることを確認します。これにより、インジェストプロセスを最適化し、パフォーマンスを向上させることができます。同じサイズのファイルを作成することをお勧めします。
ファイルの数: 並列処理とクエリのパフォーマンスを最大化するには、多数のファイルを生成することを目指します。最小ファイルサイズ 100 MB を維持しながら、できるだけ多くのファイルを作成することに優先順位を付けます。
分割： ワークロードでパーティション列でフィルター処理する場合は、パーティションを異なるフォルダーまたはファイル名に格納してデータをパーティション分割します。
推定： 予想されるパフォーマンスが得られないと感じる場合は、基になるファイル内の行数と一致するように ROWS_PER_BATCH を設定してみてください。
容量サイズ: データボリュームが大きい場合は、より大きな SKU にスケールアウトして、追加の並列処理と大規模なデータボリュームに対応するために必要なコンピューティングリソースを増やすようにすることを検討してください。

トリクル挿入や更新、削除を避ける

Fabric Data Warehouse で効率的なファイルレイアウトと最適なクエリパフォーマンスを確保するには、多数の小さな INSERT、 UPDATE、および DELETE トランザクションを使用しないようにします。これらの行レベルの変更により、操作ごとに新しい Parquet ファイルが生成され、多数の小さなファイルと断片化された行グループが生成されます。この断片化は、次の原因になります。

非効率的なファイルスキャンによるクエリ待ち時間の増加。
ストレージとコンピューティングのコストが高くなります。
バックグラウンド圧縮プロセスへの依存度の向上。

推奨される方法:

Fabric Data Warehouse に書き込むバッチトランザクション。
- たとえば、多数の小さな INSERT ステートメントではなく、データをまとめて事前ステージし、1 つの INSERT ステートメントにデータを挿入します。
一括挿入に COPY INTO を使用し、可能な限りバッチで更新と削除を実行します。
効率的な行グループの形成を確保するために、インポートされた最小ファイルサイズを 100 MB に維持します。
データインジェストの詳細なガイダンスとベストプラクティスについては、「データをウェアハウスに取り込むためのベストプラクティス」を参照してください。

データ圧縮

Fabric Data Warehouse では、データ圧縮は Fabric Data Warehouse のバックグラウンド最適化プロセスであり、小規模で非効率的な Parquet ファイルをより少ない大きなファイルにマージします。多くの場合、これらのファイルは、頻繁にトリクル処理INSERT、UPDATE、またはDELETEによって作成されます。データ圧縮により、ファイルの断片化が軽減され、行グループの効率が向上し、全体的なクエリパフォーマンスが向上します。

Fabric Data Warehouse エンジンは、データ圧縮によって時間の経過と同時に断片化を自動的に解決しますが、プロセスが完了するまでパフォーマンスが低下する可能性があります。データ圧縮は、Fabric Data Warehouse に対するユーザーの介入なしに自動的に実行されます。

データ圧縮は Lakehouse には適用されません。 SQL 分析エンドポイントを介してアクセスされる Lakehouse テーブルの場合は、Lakehouse のベストプラクティスに従い、データが大幅に変更された後に OPTIMIZE コマンドを手動で実行して、最適なストレージレイアウトを維持することが重要です。

データ圧縮の先取り処理

Fabric Data Warehouse は、バックグラウンド圧縮タスクとユーザー操作の間の書き込み/書き込みの競合をインテリジェントかつ積極的に回避します。 2025 年 10 月以降、データ圧縮のプリエンプションが有効になります。

圧縮では、ユーザークエリによって保持されている共有ロックがチェックされます。データ圧縮が開始する前にロックを検出した場合は、待機し、後でもう一度試します。データ圧縮が開始され、コミット前にロックが検出されると、圧縮が中止され、ユーザークエリとの書き込み競合が回避されます。

Fabric データウェアハウスのバックグラウンドデータコンパクションサービスによる書き込み衝突はまだ可能です。たとえば、アプリケーションが明示的なトランザクションを使用し、競合する操作 (INSERT、UPDATE、DELETE) の前に競合しない作業 (MERGE など) を実行する場合など、データ圧縮との書き込み/書き込み競合を作成できます。データの圧縮は正常にコミットされることがありますが、その結果、競合が原因で後から明示的なトランザクションが失敗する可能性があります。書き込み競合や更新競合の詳細については、「Microsoft Fabric の Warehouse テーブルのトランザクション」を参照してください。

ファブリックデータウェアハウスでの V オーダー

V オーダーは、Microsoft Fabric での高速読み取りを可能にする Parquet ファイル形式への書き込み時間の最適化です。 Fabric Data Warehouse の V オーダーでは、テーブルファイルに並べ替えと圧縮を適用することで、クエリのパフォーマンスが向上します。

既定では、すべてのウェアハウスで V オーダーが有効になり、読み取り操作 (特に分析クエリ) が可能な限り高速かつ効率的になります。

ただし、V オーダーは、書き込みが多いワークロードにおいて顕著な、小さなインジェストオーバーヘッドを導入します。このため、V オーダーの無効化は、厳密に書き込みが多く、頻繁なクエリには使用されないウェアハウスに対してのみ考慮する必要があります。倉庫で V オーダーが無効になると、再度有効にできないことに注意してください。

V オーダーを無効にすることを決定する前に、ユーザーはワークロードのパフォーマンスを徹底的にテストして、トレードオフが正当であることを確認する必要があります。一般的なパターンは、高スループットのインジェスト、データ変換のために V オーダーが無効になっているステージングウェアハウスを使用し、基になるデータを V オーダー対応データウェアハウスに取り込んで読み取りパフォーマンスを向上させることです。詳細については、「 Microsoft Fabric の Warehouse での V オーダーの無効化」を参照してください。

テーブルをコピーする代わりにテーブルを複製する

Fabric Data Warehouse のテーブルクローンを使用すると、データをコピーせずにテーブルを迅速かつ効率的に作成できます。コピーをゼロコピーで複製する方法では、テーブルのメタデータのみが複製され、基になるデータファイルは OneLake から直接参照されます。これにより、ユーザーは、完全なデータ重複のオーバーヘッドなしに、ほぼ瞬時に一貫性のある信頼性の高いテーブルコピーを作成できます。

ゼロコピークローンは、開発、テスト、バックアップなどのシナリオに最適で、インフラストラクチャコストの削減に役立つ、高パフォーマンスでストレージ効率の高いソリューションを提供します。

複製されたテーブルは、Row-Level セキュリティ (RLS)、Column-Level セキュリティ (CLS)、動的データマスク (DDM) など、ソースからすべての主要なセキュリティ機能もコピーします。複製後にポリシーを再適用する必要はありません。
複製は、データ保持期間内の特定の時点で作成でき、タイムトラベル機能をサポートします。
複製されたテーブルはソースとは独立して存在し、ソースに加えられた変更は複製に影響せず、複製に対する変更はソースに影響しません。ソースまたは複製は、個別に削除できます。

検索性能

Statistics

統計は、テーブルの列のデータを表す永続化オブジェクトです。クエリオプティマイザーでは、統計を使用して、クエリプランのコストを選択して見積もります。 Fabric Data Warehouse と Lakehouse SQL 分析エンドポイントでは、ヒストグラム統計、平均列長統計、およびテーブルカーディナリティ統計が使用され、自動的に維持されます。詳細については、「 Fabric Data Warehouse の統計」を参照してください。

単一列ヒストグラム統計では、 CREATE STATISTICS および UPDATE STATISTICS T-SQL コマンドがサポートされています。メンテナンス期間中やその他のダウンタイム中など、テーブル変換とクエリワークロードの間に十分な大きな期間がある場合は、これらを活用できます。これにより、 SELECT クエリが最初に統計を更新する必要がある可能性が低くなります。
一般的な列比較でデータ型パリティを維持するテーブルスキーマを定義してみてください。たとえば、 WHERE 句で列が相互に比較される場合や、 JOIN ... ON 述語として使用される場合は、データ型が一致することを確認します。まったく同じデータ型を使用できない場合は、暗黙的な変換に互換性のある同様のデータ型を使用してください。明示的なデータ変換は避けてください。詳細については、「データ型の変換」を参照してください。

ヒント

Lakehouse ユーザーの場合、ACE-Cardinality 統計では、テーブルの Delta ログファイルからの情報を使用して、より正確にすることができます。 Spark で生成された Delta テーブルに、テーブルの行数が含まれているのを確認します: spark.conf.set("spark.databricks.delta.stats.collect", "true")。詳細については、「 Fabric Spark での自動テーブル統計の構成と管理」を参照してください。

Apache Spark ランタイム 3.5.0 より前のタイムスタンプ列で lakehouse テーブルをフィルター処理する場合、タイムスタンプ列の行グループレベルの統計は生成されません。このような統計がないため、Fabric Warehouse などのシステムでは、行グループの削除 (データスキップまたは述語プッシュダウンとも呼ばれます) を適用することが困難になります。これは、クエリの実行中に無関係な行グループをスキップするパフォーマンス最適化です。これらの統計がない場合、タイムスタンプ列を含むクエリをフィルター処理するには、より多くのデータをスキャンする必要があるため、パフォーマンスが大幅に低下する可能性があります。 Fabric で Apache Spark ランタイムをアップグレードできます。 Apache Spark 3.5.0 以降のバージョンでは、タイムスタンプ列の行グループレベルの統計を生成できます。次に、テーブルを再作成し、行グループレベルの統計を生成するためにデータを取り込む必要があります。

コールドキャッシュのパフォーマンス

Fabric Data Warehouse でのクエリの 最初の実行 は、後続の実行よりも予期せず遅くなる可能性があります。これは コールドスタートと呼ばれ、処理のために環境を準備するシステムの初期化またはスケーリングアクティビティによって発生します。

コールドスタートは通常、次の場合に発生します。

データは初めてアクセスされ、まだキャッシュされていないため、OneLake からメモリに読み込まれます。
データに初めてアクセスする場合、クエリの実行は、必要な統計が自動的に生成されるまで遅延されます。
Fabric Data Warehouse は、一定期間非アクティブな状態の後にノードを自動的に一時停止してコストを削減し、自動スケールの一部としてノードを追加します。通常、ノードの再開または作成には 1 秒未満かかります。

これらの操作により、クエリの実行時間が長くなる可能性があります。コールドスタートは部分的である可能性があります。一部のコンピューティングノード、データ、または統計は既に使用可能であるか、メモリにキャッシュされている可能性があります。一方、クエリは他のノードが使用可能になるまで待機します。詳細については、「 Fabric データウェアハウスでのキャッシュ」を参照してください。

queryinsights.exec_requests_history ビューにクエリを実行することで、リモートストレージからメモリにデータをフェッチすることによって発生するコールドスタート効果を検出できます。 data_scanned_remote_storage_mb列を確認します。

data_scanned_remote_storage_mbの 0 以外の値は、コールドスタートを示します。クエリの実行中に OneLake からデータがフェッチされました。その後のビューは、queryinsights.exec_requests_historyで証明可能なほど迅速である必要があります。
data_scanned_remote_storage_mbのゼロ値は、すべてのデータがキャッシュされる完全な状態です。クエリ結果を提供するために、ノードの変更や OneLake からのデータは必要ありませんでした。

Von Bedeutung

最初の実行に基づいてクエリのパフォーマンスを判断しないでください。クエリがコールドスタートの影響を受けたかどうかを判断するには、常に data_scanned_remote_storage_mb を確認してください。後続の実行は、多くの場合、大幅に高速であり、実際のパフォーマンスを表しているため、平均実行時間が短縮されます。

文字列列を含むテーブルに対するクエリ

値に対応できる最小の文字列列長を使用します。 Fabric Warehouse は常に改善されています。ただし、大きな文字列データ型、特に大きなオブジェクト (LOB) を使用すると、パフォーマンスが最適でない場合があります。たとえば、customer_name列のデータ型については、ビジネス要件と予想されるデータを考慮し、n や varchar(n)の代わりに varchar(100)) などのを宣言するときに適切な長さのを使用します。データ型の長さが実際のデータに対してより正確である場合、統計とクエリコストの見積もりはより正確になります。

Fabric Data Warehouse T-SQL では、文字列データ型に適した長さを選択するためのガイダンスを参照してください。
Spark で長さが定義されていない Lakehouse テーブル文字列列は、Fabric Warehouse によって varchar(8000) として認識されます。最適なパフォーマンスを得るために、SparkSQL の CREATE TABLE ステートメントを使用して、文字列列を varchar(n)として定義します。ここで、 n は値に対応できる最大列長です。

トランザクションとコンカレンシー

Fabric Data Warehouse は、トランザクションの整合性、スナップショットの分離、分散コンピューティングを組み合わせて大規模なコンカレンシーと一貫性を実現する、最新のクラウドネイティブアーキテクチャに基づいて構築されています。詳細については、「倉庫テーブルのトランザクション」を参照してください。

Fabric Data Warehouse では、スナップショット分離を使用した ACID 準拠トランザクションがサポートされています。これは、以下のようなことを意味します。

読み取り操作と書き込み操作は、標準の T-SQL (BEGIN TRANSACTION、 COMMIT、 ROLLBACK) を使用して 1 つのトランザクションにグループ化できます。
All-or-nothing セマンティクス: トランザクションが複数のテーブルにまたがる場合、1 つの操作が失敗すると、トランザクション全体がロールバックされます。
読み取り整合性: トランザクション内 SELECT クエリでは、同時書き込みの影響を受けずに、データの一貫性のあるスナップショットが表示されます。

Fabric Warehouseにおけるトランザクション対応:

トランザクション内のデータ定義言語 (DDL): トランザクションブロック内に CREATE TABLE を含めることができます。
データベース間トランザクション: SQL 分析エンドポイントからの読み取りを含め、同じワークスペース内でサポートされます。
Parquet ベースのロールバック: Fabric Data Warehouse は不変の Parquet ファイルにデータを格納するため、ロールバックは高速です。ロールバックは、単に以前のファイルバージョンに戻ります。
自動データ圧縮とチェックポイント処理:データ圧縮では、小さな Parquet ファイルをマージし、論理的に削除された行を削除することで、ストレージと読み取りのパフォーマンスが最適化されます。
自動チェックポイント処理: すべての書き込み操作 (INSERT、 UPDATE、 DELETE) は、新しい JSON ログファイルを Delta Lake トランザクションログに追加します。時間の経過とともに、特にストリーミングまたは高周波インジェストのシナリオでは、数百または数千のログファイルが発生する可能性があります。自動チェックポイント処理では、トランザクションログを 1 つのチェックポイントファイルにまとめることで、メタデータの読み取り効率が向上します。チェックポイント処理を行わないと、すべての読み取りでトランザクションログ履歴全体をスキャンする必要があります。チェックポイント処理では、読み取られたログは最新のチェックポイントファイルとその後のログだけです。これにより、I/O とメタデータの解析が大幅に削減されます(特に、大規模または頻繁に更新されるテーブルの場合)。

圧縮とチェックポイント処理はどちらもテーブルの正常性にとって重要です。特に、実行時間の長い環境やコンカレンシーの高い環境では重要です。

コンカレンシー制御と分離

Fabric Data Warehouse では、スナップショット分離のみが使用されます。 T-SQL を使用して分離レベルを変更しようとすると無視されます。

トランザクションに関するベストプラクティス

明示的なトランザクションを賢明に使用します。常に COMMIT または ROLLBACK。トランザクションを開いたままにしないでください。
- トランザクションの有効期間を短くします。ロックを不必要に保持する実行時間の長いトランザクションは避けてください(特に、DDL を含む明示的なトランザクションの場合)。これにより、システムカタログビュー (SELECT など) のsys.tables ステートメントとの競合が発生し、システムカタログビューに依存する Fabric ポータルで問題が発生する可能性があります。
一時的な競合を処理するために、パイプラインまたはアプリで遅延を伴う再試行ロジックを追加します。
- 指数バックオフを使用して、一時的なネットワーク中断を悪化させる再試行ストームを回避します。
- 詳細については、「再試行パターン」を参照してください。
倉庫内のロックと競合を監視します。
- sys.dm_tran_locksを使用して現在のロックを検査します。

返されるデータセットのサイズを減らす

中間クエリの実行または最終的なクエリ結果のデータサイズが大きいクエリでは、クエリパフォーマンスの問題が発生する可能性があります。返されるデータ・セット・サイズを小さくするには、次の方法を検討してください。

Lakehouse で大規模なテーブルをパーティションします。
返される列の数を制限します。 SELECT * コストがかかる場合があります。
返される行の数を制限します。クライアントアプリケーションではなく、可能な限り多くのデータフィルター処理をウェアハウスで実行します。
- 結合する前にフィルター処理を試み、クエリの実行の早い段階でデータセットを減らしてください。
- カーディナリティの低い列をフィルター処理して、JOIN の前の早い段階で大規模なデータセットを減らします。
- カーディナリティが高い列は、フィルター処理や JOIN に最適です。これらは多くの場合、 WHERE 句で使用され、データをフィルター処理するためにクエリ実行の前の段階で述語が適用される利点があります。
Fabric Data Warehouse では、主キー制約と一意キー制約が適用されないため、これらの制約を持つ列は、必ずしも JOIN の候補として適しているとは限りません。

クエリプランとクエリヒント

Fabric Data Warehouse では、クエリオプティマイザーによってクエリ実行プランが生成され、SQL クエリを実行する最も効率的な方法が決定されます。上級ユーザーは、クエリプランでクエリパフォーマンスの問題を調査するか、クエリヒントを追加して調査することを検討できます。

ユーザーは、SQL Server Management Studio のSHOWPLAN_XMLを使用して、クエリを実行せずにプランを表示できます。
オプションのクエリヒントを SQL ステートメントに追加して、プランの生成前にクエリオプティマイザーに指示を追加できます。クエリヒントを追加するには、クエリワークロードに関する高度な知識が必要であるため、通常は他のベストプラクティスが実装された後に使用されますが、問題は解決しません。

スケーラブルでない操作

Fabric Data Warehouse は、複数のコンピューティングノード間でクエリが実行される超並列処理 (MPP) アーキテクチャに基づいて構築されています。一部のシナリオでは、単一ノードの実行が正当化されます。

クエリプラン全体の実行に必要なコンピューティングノードは 1 つだけです。
プランサブツリーは、1 つのコンピューティングノード内に収めることができます。
クエリセマンティクスを満たすために、クエリ全体またはクエリの一部を 1 つのノードで実行する 必要があります 。たとえば、 TOP 操作、グローバル並べ替え、並列実行の結果を並べ替えて 1 つの結果を生成する必要があるクエリ、最後の手順で結果を結合するクエリなどです。

このような場合、ユーザーは "1 つ以上のスケーラブルでない操作が検出されました" という警告メッセージを受け取ることができ、クエリの実行速度が遅くなったり、長時間実行された後に失敗したりする可能性があります。

クエリのフィルター処理されたデータセットのサイズを小さくすることを検討してください。
クエリセマンティクスで単一ノードの実行が必要ない場合は、など、FORCE DISTRIBUTED PLAN を使用して分散クエリプランを強制してみてください。

SQL 分析エンドポイントにクエリを実行する

SQL 分析エンドポイントを使用すると、データをコピーしたり、ウェアハウスに取り込んだりすることなく、Spark SQL が設定された Lakehouse テーブルに対してクエリを実行できます。

次のベストプラクティスは、SQL 分析エンドポイントを介して Lakehouse 内のウェアハウスデータに対してクエリを実行する場合に適用されます。 SQL 分析エンドポイントのパフォーマンスの詳細については、 SQL 分析エンドポイントのパフォーマンスに関する考慮事項を参照してください。

ヒント

次のベストプラクティスは、Spark を使用して SQL 分析エンドポイントによってクエリできるレイクハウスにデータを処理する場合に適用されます。

Lakehouse テーブルの定期的なテーブルメンテナンスを実行する

Microsoft Fabric では、Warehouse がデータレイアウトを自動的に最適化し、ガベージコレクションとデータの圧縮を実行します。 Lakehouse では、テーブルのメンテナンスをより詳細に制御できます。テーブルの最適化とバキュームが必要であり、大規模なデータセットに必要なスキャン時間を大幅に短縮できます。 Lakehouse でのテーブルのメンテナンスもショートカットにまで及び、パフォーマンスを大幅に向上させることができます。

多数の小さなファイルでレイクハウスのテーブルやショートカットを最適化する

小さなファイルが多数あると、ファイルメタデータを読み取るためのオーバーヘッドが発生します。 Fabric ポータルまたはノートブックで OPTIMIZE コマンドを使用して、小さなファイルを大きなファイルに結合します。ファイルの数が大幅に変わったら、このプロセスを繰り返します。

Fabric Lakehouse でテーブルを最適化するには、Fabric ポータルで Lakehouse を開きます。 エクスプローラーで、テーブルを右クリックし、[メンテナンス] を選択します。 [ メンテナンスコマンドの実行 ] ページからオプションを選択し、[ 今すぐ実行] を選択します。

同じリージョンにある lakehouse テーブルまたはショートカットに対してクエリを実行する

Fabric では、Fabric 容量が配置されている場所の計算リソースが使用されます。独自の Azure Data Lake Storage や OneLake などのデータを別のリージョンでクエリすると、ネットワーク待機時間が原因でパフォーマンスのオーバーヘッドが発生します。データが同じリージョンにあることを確認します。パフォーマンス要件に応じて、ディメンションテーブルなどの小さなテーブルのみをリモートリージョンに保持することを検討してください。

lakehouse のテーブルとショートカットを同じ列でフィルターする

特定の列のテーブル行をフィルター処理することが多い場合は、テーブルのパーティション分割を検討してください。

パーティション分割は、カーディナリティの低い列や、年や日付などの予測可能なカーディナリティを持つ列に適しています。詳細については、「 Lakehouse チュートリアル - パーティションを使用して Lakehouse データを準備して変換し、データを Lakehouse に読み込む」を参照してください。

クラスタリングは、選択度の高い列に適しています。列のパーティション分割以外に、フィルター処理に頻繁に使用する他の列がある場合は、Spark SQL 構文 ZORDER BYで最適化を使用してテーブルをクラスタリングすることを検討してください。詳細については、「 Delta Lake テーブルの最適化」を参照してください。

メタデータビューのクエリ

クエリ実行履歴 (30 日)
- queryinsights.exec_requests_history
- queryinsights.exec_sessions_history
集計された分析情報
- queryinsights.long_running_queries
- queryinsights.よく実行されるクエリ

queryinsights ビューの詳細については、「Fabric データウェアハウスのクエリ分析情報」を参照してください。

クエリライフサイクル DMV

クエリライフサイクル DMV の詳細については、「DMV を使用した接続、セッション、および要求の監視」を参照してください。

フィードバック

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