次の方法で共有


Synapse Data Warehouse での課金と使用状況のレポート

適用対象:✅ Microsoft Fabric の SQL 分析エンドポイントおよびウェアハウス

この記事では、Microsoft Fabric の Synapse Data Warehouse のコンピューティング使用状況レポートについて説明します。これには、ウェアハウスに対する読み取りと書き込みのアクティビティ、および レイクハウスの SQL 分析エンドポイントでの読み取りアクティビティが含まれます。

Fabric の容量を使用すると、使用料金は、Azure portal で Microsoft Cost Management のサブスクリプションの下に表示されます。 Fabric の課金について理解するには、「Azure の請求書で Fabric の容量を把握する」を参照してください。

現在および過去のクエリ アクティビティの監視に関する詳細は、「Fabric Data Warehouse での監視の概要」を参照してください。

許可

Fabric では、購入した容量 SKU に基づいて、すべての Fabric ワークロード間で共有される容量ユニット (CU) のセットを利用できます。 サポートされているライセンスの詳細については、「Microsoft Fabric ライセンス」を参照してください。

''容量'' は、特定の時点で使用できるリソースの専用セットです。 容量では、アクティビティを実行したり、出力を生成したりするリソースの機能が定義されます。 リソースによって、異なる時間に CU が消費されます。

Fabric Synapse Data Warehouse の容量

容量ベースの SaaS モデルでは、Fabric データ ウェアハウスは、購入した容量を最大限に活用し、使用状況を可視化することを目的としています。

データ ウェアハウスによって使用される CU には、ウェアハウスに対する読み取りおよび書き込みアクティビティ、およびレイクハウスの SQL 分析エンドポイントでの読み取りアクティビティが含まれます。

簡単に言うと、1 ファブリック容量ユニット = 0.5 ウェアハウス仮想コアです。 たとえば、ファブリック容量 SKU F64 には 64 容量ユニットがあり、これは 32 個のウェアハウス仮想コアに相当します。

コンピューティングの使用状況レポート

Microsoft Fabric Capacity Metrics アプリ では、すべての Fabric ワークロードの容量使用状況を 1 か所で可視化できます。 管理者は、アプリを使用して、容量、ワークロードのパフォーマンス、および購入した容量と比較した使用量を監視できます。

最初に、Microsoft Fabric Capacity Metrics アプリをインストールするには、容量管理者である必要があります。 インストールすると、組織内のすべてのユーザーが、アプリを表示するためのアクセス許可を付与または共有できるようになります。 詳細については、Microsoft Fabric Capacity Metrics アプリのインストールに関する記事を参照してください。

アプリをインストールしたら、[Select item kind:] (項目の種類の選択:) ドロップダウン リストから [Warehouse] を選択します。 これで、[Multi metric ribbon chart] (マルチ メトリック リボン グラフ) グラフと [Items (14 days)] (項目 (14 日間)) データ テーブルに Warehouse アクティビティのみが表示されます。

Microsoft Fabric Capacity Metrics アプリの [Fabric Capacity Metrics] コンピューティング ページのアニメーション GIF。

ウェアハウスの操作カテゴリ

テナント全体で、ワークロード カテゴリ別にユニバーサル コンピューティングの容量使用状況を分析できます。 使用状況は、合計容量ユニット秒 (CU) で追跡されます。 表示されている表は、過去 14 日間の使用状況の集計を示しています。

ウェアハウスと SQL 分析エンドポイントは、どちらも SQL コンピューティングを使用するため、その両方がメトリック アプリの [ウェアハウス] の下にロールアップされます。 このビューに表示される操作カテゴリは次のとおりです。

  • [ウェアハウス クエリ]: ウェアハウス内での、ユーザー生成またはシステム生成によるすべての T-SQL ステートメントに対するコンピューティング料金。
  • [SQL 分析エンドポイント クエリ]: SQL 分析エンドポイント内での、ユーザー生成またはシステム生成によるすべての T-SQL 分析ステートメントに対するコンピューティング料金。
  • [OneLake Compute] (OneLake コンピューティング): OneLake に格納されているデータのすべての読み取りと書き込みに対するコンピューティング料金。

次に例を示します。

Microsoft Fabric Capacity Metrics アプリのデータ ウェアハウスの操作カテゴリのスクリーンショット。

タイムポイント探索グラフ

Microsoft Fabric Capacity Metrics アプリのこのグラフは、購入した容量と比較したリソースの使用率を示しています。 使用率 100% は、容量 SKU の完全なスループットを表し、すべての Fabric ワークロードで共有されます。 これは黄色の点線で表されます。 グラフで特定のタイムポイントを選ぶと、[探索する] ボタンが有効になり、詳細なドリルスルー ページが開きます。

Microsoft Fabric Capacity Metrics アプリの [探索] ボタンのスクリーンショット。

一般的には、Power BI と同様に、操作は [対話型] または [バックグラウンド] として分類され、色で示されます。 ウェアハウス カテゴリのほとんどの操作は、アクティビティの 24 時間の平滑化を利用するために "バックグラウンド" として報告され、最も柔軟な使用状況パターンを実現します。 データ ウェアハウスをバックグラウンドとして分類すると、CU 使用率のピーク時にスロットリングがトリガーされる頻度が減ります。

タイムポイント ドリル スルー グラフ

Microsoft Fabric Capacity Metrics アプリの タイムポイント ドリルスルー グラフのスクリーンショット。

Microsoft Fabric Capacity Metrics アプリの次の表は、特定の時点での使用率の詳細ビューを示しています。 30 秒ごとに特定の SKU によって提供される容量が、対話型操作とバックグラウンド操作の内訳とともに表示されます。 対話型操作テーブルは、その時点で実行された操作のリストを表します。

バックグラウンド操作テーブルには、選択した時点よりかなり前に実行された操作が表示されるように見える場合があります。 これは、バックグラウンド操作が 24 時間で平滑化されるためです。 たとえば、テーブルには、選択された時点で実行され、まだ平滑化されているすべての操作が表示されます。

このビューの主なユース ケースは次のとおりです。

  • 操作をスケジュールまたは実行したユーザーの識別: 値には、"User@domain.com"、"System"、または "Power BI Service" のいずれかが表示されます。

    • ユーザーが生成するステートメントの例としては、T-SQL クエリや Fabric ポータルでのアクティビティ (SQL クエリ エディターや Visual Query エディターなど) の実行などがあります。
    • "System" で生成されるステートメントの例としては、メタデータ同期アクティビティや、クエリの実行を高速化するために実行されるその他のシステム バックグラウンド タスクなどがあります。
  • 操作状態の識別: 値には、"Success"、"InProgress"、"Cancelled"、"Failure"、"Invalid"、"Rejected" のいずれかが表示されます。

    • "Cancelled" 状態は、完了前に取り消されたクエリです。
    • "Rejected" 状態は、リソースの制限により発生する場合があります。
  • 多くのリソースを消費した操作の識別: テーブルを 合計 CU(s) の降順で並べ替えて最も負荷の高いクエリを見つけた後に、操作 ID 使用して操作を一意に識別します。 これは分散ステートメント ID であり、動的管理ビュー (DMV) やクエリ分析情報などの他の監視ツールで、sys.dm_exec_requestsdist_statement_idquery insights.exec_requests_historydistributed_statement_id など、エンド ツー エンドの追跡可能性を確保するために使用します。 例 :

    次の T-SQL クエリの例では、sys.dm_exec_requests 動的管理ビューのクエリ内で操作 ID を使用します。

    SELECT * FROM sys.dm_exec_requests 
    WHERE dist_statement_id = '00AA00AA-BB11-CC22-DD33-44EE44EE44EE';
    

    次の T-SQL クエリでは、queryinsights.exec_requests_history ビューのクエリで操作 ID を使用します。

    SELECT * FROM queryinsights.exec_requests_history 
    WHERE distributed_statement_id = '00AA00AA-BB11-CC22-DD33-44EE44EE44EE`;
    

課金の例

次のクエリがあるとします。

SELECT * FROM Nyctaxi;

デモンストレーションの目的で、課金メトリックが 100 CU 秒蓄積されると仮定します。

このクエリのコストは、"CPU 秒 x CU あたりの価格" です。 この例では、CU あたりの価格が $0.18/時間であるとします。 1 時間は 3,600 秒です。 したがって、このクエリのコストは (100 x 0.18)/3600 = $0.005 になります。

この例で使用した数値は、デモンストレーションのみを目的としており、実際の課金メトリックではありません。

考慮事項

使用状況レポートに関する以下のような微妙な違いが考えられます。

  • [複数データベース間のレポート作成]: T-SQL クエリが複数のウェアハウスで (またはウェアハウスと SQL 分析エンドポイントをまたいで) 結合される場合、使用料は送信元のリソースに対して報告されます。
  • システム カタログ ビューと動的管理ビューに対するクエリは、課金対象です。
  • Fabric Capacity Metrics アプリで報告される [期間] フィールドは、情報提供のみを目的としています。 ステートメントの実行時間が反映されます。 所要時間には、SQL クエリ エディターのような Web アプリケーションまたは SQL Server Management StudioAzure Data Studio のようなクライアント アプリケーションに結果をレンダリングするのにかかかる完全なエンド ツー エンドの所要時間は含まれていない可能性があります。

次のステップ