Microsoft Fabric の Synapse Data Warehouse のパフォーマンス ガイドライン
適用対象: 
Microsoft Fabric のウェアハウス
これらは、Microsoft Fabric の Warehouse のパフォーマンスを理解するのに役立つガイドラインです。 この記事では、注目すべきガイダンスと重要な記事を示します。 Microsoft Fabric の Warehouse は、ワークロード管理、同時実行性、ストレージ管理などのアクティビティがプラットフォームによって内部的に管理される SaaS プラットフォームです。 この内部パフォーマンス管理に加えて、適切に設計されたウェアハウスに対してパフォーマンスの高いクエリを開発することによって、パフォーマンスを向上させることもできます。
コールド ラン (コールド キャッシュ) のパフォーマンス
ローカル SSD とメモリを使用したキャッシュは自動的に行われます。 クエリの最初の 1 - 3 回の実行は、後続の実行よりも著しく遅くなります。 コールド ランのパフォーマンスに問題がある場合、次の方法を試すことでコールド ランのパフォーマンスを向上させることができます:
初回実行時のパフォーマンスに重大な問題がある場合は、手動で統計を作成してみてください。 統計 記事を参照して、統計の役割について理解を深め、クエリのパフォーマンスを向上させる手動統計を作成する方法を確認してください。 初回実行時のパフォーマンスに重大な問題がない場合は、自動統計の使用ができます。自動統計は、最初のクエリで生成され、以降も継続的に実行されます (基になるデータが大幅に変更されない限り)。
Power BI を使用している場合は、可能な限り Direct Lake モードを使用してください。
パフォーマンスを監視するためのメトリック
現在、監視ハブには Warehouse が含まれていません。 Data Warehouse を選択した場合、ナビゲーション メニューから監視ハブにアクセスできなくなります。
ファブリック管理者は、キャパシティ使用率およびメトリック レポートにアクセスして、Warehouse を含むキャパシティの使用率を追跡する最新情報を確認できるようになります。
動的管理ビュー (DMV) を使用してクエリの実行を監視する
動的管理ビュー (DMV) を使用して、Warehouse 内の接続、セッション、要求の状態を監視できます。
統計
Warehouse は、クエリ エンジンを使用して、特定の SQL クエリの実行プランを作成します。 クエリを送信すると、クエリ オプティマイザーは考えられるすべてのプランを列挙し、最も効率的な候補を選択しようとします。 どのプランが最小のオーバーヘッドを必要とするかを判断するには、エンジンが各オペレーターで処理される可能性のある作業量または行の量を評価できる必要があります。 次に、各プランのコストに基づいて、推定作業量が最も少ないプランが選択されます。 統計は、クエリ オプティマイザーがこれらのコストを見積もることができるようにする、データに関する関連情報を含むオブジェクトです。
また、最適なクエリ プランを確実に構築できるようにするには、データのロードまたは更新のたびに統計を手動で更新することもできます。
統計の詳細と、自動的に作成された統計を拡張する方法については、「Fabric データ ウェアハウスの統計」を参照してください。
データ インジェストのガイドライン
Warehouse へのデータの取り込みには 4 つのオプションがあります。
- COPY (Transact-SQL)
- データ パイプライン
- データフロー
- クロスウェアハウス インジェスト
どのオプションが最適かを判断し、データ インジェストのベスト プラクティスを確認するには、「データの取り込み」を参照してください。
INSERT ステートメントをバッチにグループ化する (トリクル挿入を回避する)
以下の例に示すような INSERT ステートメントを使用して小さなテーブルを 1 回だけ読み込むことが、ニーズに応じて最適な方法である可能性があります。 ただし、1 日を通して数千から数百万もの行を読み込む必要がある場合、シングルトンの INSERT は最適ではありません。
INSERT INTO MyLookup VALUES (1, 'Type 1')
これらのトリクル読み込みシナリオを処理する方法のガイダンスについては、「データ取り込みのベスト プラクティス」を参照してください。
トランザクション サイズを最小限に抑える
INSERT、UPDATE、DELETE の各ステートメントはトランザクションで実行されます。 失敗した場合は、それらをロールバックする必要があります。 ロールバック時間が長くならないようにするには、トランザクション サイズをできる限り最小限に抑えます。 トランザクション サイズを最小限に抑えるには、INSERT、UPDATE、DELETE の各ステートメントを複数に分割します。 たとえば、INSERT に 1 時間かかると予測される場合は、INSERT を 4 つに分割できます。 その結果、それぞれの実行時間は 15 分に短縮されます。
テーブルに保持したいデータを書き込むには、DELETE を使用するのではなく、CTAS (Transact-SQL) を使用することを検討してください。 CTAS にかかる時間が同じ場合でも、トランザクション ログが最小限に抑えられ、必要なときにすばやく取り消すことができるため、CTAS の方が安全に実行できます。
クライアント アプリケーションと Microsoft Fabric を併置する
クライアント アプリケーションを使用している場合は、クライアント コンピューターに近いリージョンで Microsoft Fabric を使用していることを確認してください。 クライアント アプリケーションには、たとえば、Power BI Desktop、SQL Server Management Studio、Azure Data Studio などがあります。
スター スキーマ データ設計を活用する
スター スキーマ は、データを ファクト テーブル と ディメンション テーブル に編成します。 これにより、高度に正規化された OLTP システムからのデータを非正規化し、トランザクション データとエンタープライズ マスター データを共通のクレンジングされ検証されたデータ構造に取り込むことで、分析処理が容易になります。また、クエリ時の結合が最小限に抑えられ、読み取られる行数が減り、集計とグループ化の処理が容易になります。
Warehouse 設計のガイダンスの詳細については、「データ ウェアハウスのテーブル」を参照してください。
クエリ結果セットのサイズを減らす
クエリ結果セットのサイズを縮小することは、大きなクエリ結果によって発生するクライアント側の問題を回避するのに役立ちます。 このブラウザー ベースの UI ではこれらの問題を回避するために、SQL クエリ エディターの結果セットは最初の 10,000 行に制限されています。 10,000 行を超える行を返す必要がある場合は、SQL Server Management Studio (SSMS) または Azure Data Studio を使用します。
パフォーマンスに最適なデータ型を選択する
テーブルを定義するときは、データをサポートしている最小のデータ型を使用します。これにより、クエリのパフォーマンスが向上します。 この推奨事項は、CHAR 列と VARCHAR 列では重要です。 列の最長の値が 25 文字の場合は、列を VARCHAR(25) として定義します。 既定の長さですべての文字列を定義しないようにしてください。
可能であれば、整数ベースのデータ型を使用します。 SORT、JOIN、および GROUP BY 操作は、文字データよりも整数で速く完了します。
サポートされているデータ型と詳細については、「データ型」を参照してください。
SQL 分析エンドポイントのパフォーマンス
SQL 分析エンドポイントのパフォーマンスに関する情報と推奨事項については、「SQL 分析エンドポイントのパフォーマンスに関する考慮事項」を参照してください。