Microsoft Fabric
Azure Blob Storage
Microsoft Entra ID
Power BI
この記事では、オンプレミスのデータ ウェアハウスからクラウド環境にデータを転送し、ビジネス インテリジェンス (BI) モデルを使用してデータを処理する方法について説明します。 このアプローチは、最終的な目標として、またはクラウドベースのコンポーネントを使用した完全な最新化への最初のステップとして使用できます。
このガイダンスは、 Microsoft Fabric のエンド ツー エンドのシナリオに基づいています。 オンプレミスの SQL サーバーからデータを抽出するオプションは複数あります。たとえば、Fabric Data Factory パイプライン、ミラーリング、コピー ジョブ、および SQL の Fabric リアルタイム イベントストリーム変更データ キャプチャ (CDC) などです。 抽出後、データは分析のために変換されます。
Architecture
このアーキテクチャの Visio ファイル をダウンロードします。
Workflow
次のワークフローは、前の図に対応しています。
データ ソース
- Azure の SQL Server データベースには、ソース データが含まれています。 オンプレミス環境をシミュレートするために、このシナリオのデプロイ スクリプトによって Azure SQL データベースが構成されます。 AdventureWorks サンプル データベースをソース データ スキーマとサンプル データとして使います。 詳細については、「SQL Serverとの間でデータをコピーおよび変換する」を参照してください。
インジェストとデータ ストレージ
Fabric OneLake は、組織全体の単一の統合された論理データ レイクです。 この SaaS には、データ エンジニアリング の Lakehouse ワークロード用の Fabric Lakehouse 、データ ウェアハウス ワークロード用 の Fabric Warehouse 、大量の時系列データセットとログ データセット用 の Fabric Eventhouse など、さまざまなデータ ストレージ オプションが用意されています。
Fabric Data Factory パイプライン を使用すると、さまざまなタスクを大規模に実行できる複雑な抽出、変換、読み込み (ETL) ワークフロー、およびデータ ファクトリ ワークフローを構築できます。 制御フロー機能は、ループと条件を提供するワークフロー ロジックを構築できるデータ パイプラインに組み込まれています。 このアーキテクチャでは、メタデータ駆動型フレームワークにより、大規模な複数のテーブルの増分インジェストが可能になります。
Fabric Data Factory ミラーリング を使用すると、複雑な ETL プロセスを回避し、既存の SQL Server 資産を Fabric の残りのデータと統合できます。 既存の SQL Server データベースを Fabric OneLake に直接継続的にレプリケートできます。 Fabric Data Factory コピー ジョブを使用すると、パイプラインを必要とせずに、ソースからコピー先にデータを簡単に移動できます。 データ転送は、バッチコピーと増分コピーの組み込みパターンを使用して構成でき、スケーラブルなパフォーマンスをサポートします。
ファブリック イベントストリームは 、CDC 抽出を使用して、仮想マシン (VM) でホストされている SQL Server データベースからの高スループットでリアルタイムのデータ インジェストを提供します。 このパターンは、リアルタイムのダッシュボードとアラートを必要とするユース ケースに適しています。
分析とレポート
- このシナリオのデータ モデリングアプローチでは、エンタープライズ モデル と BI セマンティック モデルを組み合わせています。 ファブリック SKU は、Power BI セマンティック モデルのコンピューティングを提供します。 Power BI は、Import、DirectQuery、または Direct Lake 接続を介してデータにアクセスできます。
Components
azure SQL Database は、Azure でホストされる PaaS SQL サーバーです。 このアーキテクチャでは、SQL Database はソース データを提供し、移行シナリオのデータ フローを示します。
OneLake は、組織全体で構造化データと非構造化データの両方を格納するための、統合されたクラウドベースのデータ レイクです。 このアーキテクチャでは、OneLake は中央ストレージ レイヤーとして機能します。 Fabric Lakehouse、Fabric Warehouse、Fabric Eventhouse、ミラー化されたデータベースなどの成果物を使用して、分析とレポートのためにさまざまな種類のデータを保持および整理します。
Fabric Data Warehouse は、大規模なデータセットのデータ ウェアハウス ワークロードをホストする SaaS オファリングです。 このアーキテクチャでは、Fabric Data Warehouse はディメンション データセットの最終的なストアとして機能し、分析とレポートをサポートします。
Power BI は、Fabric コンピューティングでホストされているビジネス インテリジェンス ツールです。 このシナリオでは、データの表示と視覚化が行われ、ビジネス ユーザーは Fabric Data Warehouse やその他のソースからのデータに基づいてダッシュボードやレポートを操作できます。
Microsoft Entra ID は、認証と承認のフローをサポートするマルチクラウド ID とネットワーク ソリューション スイートです。 このアーキテクチャでは、Microsoft Entra ID は、Power BI および Fabric リソースに接続するユーザーに安全なアクセスを提供します。
シナリオの詳細
このシナリオでは、組織には大規模なオンプレミス データ ウェアハウスを含む SQL データベースがあります。 組織は、Fabric を使用してデータを取り込んで分析し、Power BI を通じて分析分析情報をユーザーに提供したいと考えています。
このアーキテクチャを使用する場合
さまざまな方法を使用して、エンタープライズ ビジネス インテリジェンスのビジネス要件を満たすことができます。 現在のテクノロジへの投資、人間のスキル、最新化のタイムライン、将来の目標、サービスとしてのプラットフォーム (PaaS) とサービスとしてのソフトウェア (SaaS) のどちらを好むかなど、さまざまな側面によってビジネス要件が定義されます。
次の設計方法を検討してください。
Fabric と Azure Databricks。Azure Databricks と Power BI に既存の投資があり、Fabric を使用して最新化したいお客様向け
Azure SQL エコシステムと Fabric を使用する中小企業向けのエンタープライズ BI
SaaS ソリューションを希望するお客様向けの Fabric 上のエンド ツー エンドのデータ ウェアハウス
この記事のアーキテクチャでは、エンタープライズ セマンティック モデルの永続的なレイヤーとして Fabric Lakehouse または Fabric Warehouse を使用し、ビジネス インテリジェンスに Power BI を使用することを前提としています。 この SaaS アプローチでは、さまざまなビジネス要件や好みに柔軟に対応できます。
Authentication
Microsoft Entra ID は、Power BI ダッシュボードとアプリに接続するユーザーを認証します。 シングル サインオン (SSO) は、Fabric ウェアハウスおよび Power BI セマンティック モデルのデータにユーザーを接続します。 承認はソースで行われます。
段階的な読み込み
自動化された ETL または ELT プロセスを実行する場合は、前回の実行以降に変更されたデータのみを読み込む必要があります。 このプロセスは 増分読み込みと呼ばれます。 これに対し、フル ロードではすべてのデータが読み込まれます。 増分読み込みを実行するには、変更されたデータを識別する方法を決定します。 高基準値 値アプローチを使用できます。このアプローチでは、ソース テーブル内の日付/時刻列または一意の整数列の最新の値を追跡します。
SQL Server で テンポラル テーブル を使用できます。 テンポラル テーブルは、データ変更履歴を格納するシステム バージョン管理されたテーブルです。 データベース エンジンは、各変更履歴を別々の履歴テーブルに自動的に記録します。 履歴データに対してクエリを実行するには、FOR SYSTEM_TIME 句をクエリに追加します。 内部的には、データベース エンジンは履歴テーブルのクエリを実行しますが、この処理はアプリケーションにとって透過的です。
テンポラル テーブルではディメンション データがサポートされており、時間の経過と同時に変化する可能性があります。 ファクト テーブルは通常、システム バージョン履歴を保持することは意味のない、販売などの不変トランザクションを表します。 代わりに、トランザクションには通常、トランザクションの日付を表す列があります。 この列は、基準値として使用できます。 たとえば、AdventureWorks データ ウェアハウスでは、SalesLT.* テーブルには LastModified フィールドがあります。
次の手順では、ELT パイプラインの一般的なフローについて説明します。
ソース データベースの各テーブルについて、最後の ELT ジョブが実行されたときのカットオフ時間を追跡します。 この情報をデータ ウェアハウスに格納します 初期設定では、すべての時間が
1-1-1900に設定されます。データのエクスポート手順では、カットオフ時間がパラメーターとしてソース データベース内のストアド プロシージャのセットに渡されます。 これらのストアド プロシージャは、カットオフ時間の後に変更または作成されたすべてのレコードに対してクエリを実行します。 例のすべてのテーブルには
ModifiedDate列を使用できます。データの移行が完了したら、カットオフ時間を格納するテーブルを更新します。
データ パイプライン
このシナリオでは、データソースとして AdventureWorks サンプル データベースを使います。 増分データ読み込みパターンにより、最新のパイプライン実行後に変更または追加されたデータのみが読み込まれます。
メタデータ駆動型インジェスト フレームワーク
Fabric Data Factory パイプライン内 のメタデータ駆動型インジェスト フレームワーク は、リレーショナル データベースに含まれるすべてのテーブルを段階的に読み込みます。 この記事では、データ ウェアハウスをソースと見なしますが、ソースとして Azure SQL データベースに置き換えることができます。
透かしの列を選択します。 新しいレコードまたは変更されたレコードを追跡するのに役立つ、ソース テーブル内の 1 つの列を選択します。 通常、この列には、行が追加または更新されるときに増加する値 (タイムスタンプや ID など) が含まれます。 この列の最大値を 基準値 として使用して、中断した場所を把握します。
最後の基準値を格納するテーブルを設定します。
次のアクティビティを含むパイプラインを構築します。
2 つのルックアップ アクティビティ。 最初のアクティビティは、最後の基準値 (前回停止した場所) を取得します。 2 番目のアクティビティは、新しい基準値を取得します (今回は停止します)。 両方の値がコピー アクティビティに渡されます。
基準値列の値が古い水印と新しい水印の間にある行を検索するコピー アクティビティ。 その後、データ ウェアハウスから新しいファイルとして lakehouse にこのデータをコピーします。
新しい基準値を保存して、次のパイプライン実行の開始点を決定するストアド プロシージャ アクティビティ。
次の図は、完成したパイプラインを示しています。 詳細については、「 インジェストの増分」を参照してください。
Fabric データ ウェアハウスにデータを読み込む
コピー アクティビティは、SQL データベースから Fabric データ ウェアハウスにデータをコピーします。 この例の SQL データベースは Azure 内にあり、ファブリック ポータルの [接続とゲートウェイの管理] で設定された接続を使用します。
Fabric Data Factory パイプラインを使用する
Fabric Data Factory のパイプラインでは、増分読み込みパターンを完了するために、順序付けられた一連のアクティビティを定義します。 手動トリガーまたは自動トリガーによってパイプラインが開始されます。
データの変換
変換が必要な場合は、 Fabric データフロー を使用して、データを整形する低コードの AI 支援 ETL 変換を設計します。 Fabric データフローは、Power Query エンジンに依存してこれらの変換を適用し、結果を Fabric Data Warehouse に書き込みます。
運用環境では、 Fabric ノートブック を使用して、Apache Spark によって駆動される分散コンピューティング フレームワークを使用して、大規模なデータセットに適した ETL 変換を実装します。
注
ネイティブ実行エンジンを使用して、データ エンジニアリングまたは ETL ワークロードを実行します。
Power BI と Fabric 容量を使用してデータにアクセスし、モデル化し、視覚化する
Power BI のファブリック容量では、Azure データ ソースに接続するための複数のストレージ モードがサポートされています。
輸入： メモリ内クエリのために Power BI セマンティック モデルにデータを読み込みます。
DirectQuery: データをメモリに読み込まずにリレーショナル ストレージに対して直接クエリを実行します。
複合モデル: 一部のテーブルのインポート モードと、同じデータセット内の他のテーブルの DirectQuery を組み合わせます。
Direct Lake: OneLake に格納されているデルタ テーブルを Fabric ワークスペース セマンティック モデルから照会します。 データを必要に応じてメモリに読み込むことで、大規模なテーブルの対話型分析用に最適化されています。
このシナリオでは、データ量が少なく、モデルの複雑さが少ないため、DirectQuery ダッシュボードを使用します。 DirectQuery は、基になるコンピューティング エンジンにクエリを委任し、ソースのセキュリティ機能を使用します。 DirectQuery により、結果は常に最新のソース データと一致します。
インポート モードでは、クエリの待機時間を最小限に抑えることができます。 次の要因に該当する場合は、インポート モードを検討してください。
- このモデルは、Power BI のメモリ内に完全に収まります。
- 更新間のデータ待機時間は許容されます。
- ソース システムと最終的なモデルの間で複雑な変換が必要です。
この場合、ユーザーは Power BI の更新に遅延なしで最新のデータへのフル アクセスを必要とし、Power BI データセットの容量を超えるすべての履歴データが必要です。 Power BI データセットでは、容量サイズに応じて 25 GB から 400 GB を処理できます。 専用 SQL プール内のデータ モデルは既にスター スキーマにあり、変換は必要ないため、DirectQuery が適切な選択肢です。
Power BI を使用して、大規模なモデル、ページ分割されたレポート、デプロイ パイプラインを管理します。 組み込みの Azure Analysis Services エンドポイントを利用します。 独自の価値提案を備えた専用 の容量 を持つこともできます。
BI モデルが拡大したり、ダッシュボードの複雑さが増したりすると、複合モデルに切り替えたり、ハイブリッド テーブル 介して参照テーブルの一部をインポートしたり、事前集計データをインポートしたりできます。 インポートされたデータセットに対して Power BI 内で クエリ キャッシュ を有効にしたり、ストレージ モード プロパティ デュアル テーブル を使用したりできます。
複合モデル内では、データセットは仮想パススルー レイヤーとして機能します。 ユーザーが視覚エフェクトを操作すると、Power BI によって Fabric Data Warehouse に対する SQL クエリが生成されます。 Power BI は、効率に基づいてメモリ内ストレージと DirectQuery ストレージのどちらを使用するかを決定します。 エンジンは、インメモリから DirectQuery に切り替えるタイミングを決定し、ロジックを Fabric データ ウェアハウスにプッシュします。 クエリ テーブルのコンテキストに応じて、キャッシュされた (インポートされた) 複合モデルまたはキャッシュされていない複合モデルとして機能できます。 メモリにキャッシュするテーブルを選択したり、1 つ以上の DirectQuery ソースのデータを結合したり、DirectQuery ソース データとインポートされたデータを結合したりできます。
Fabric データ ウェアハウスまたは lakehouse で DirectQuery を使用する場合は、次のアクションを実行します。
Fabric Z オーダーと V オーダー を使用して、差分形式ファイル内の基になるテーブル データのストレージを最適化することで、クエリのパフォーマンスを向上させます。
Fabric Lakehouse の具体化されたビュー を使用して、テーブルのようにデータを事前計算、格納、管理します。 具体化されたビュー内のすべてのデータまたはデータのサブセットを使用するクエリでは、定義されたマテリアライズド ビューを直接参照して使用しなくても、より高速なパフォーマンスを実現できます。
考慮事項
これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。
Reliability
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
信頼性 に関 する記事では、可用性ゾーンを通じたリージョンの回復性や、リージョン間の復旧とビジネス継続性など、Fabric が信頼性をサポートする方法について説明します。 Fabric では、容量設定のページにディザスター リカバリー スイッチが用意されています。 Azure リージョンのペアリングが Fabric サービスのプレゼンスと一致する場所で使用できます。 ディザスター リカバリー容量の設定を有効にすると、OneLake データの ディザスター リカバリー機能 としてリージョン間レプリケーションが有効になります。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
クラウドの最新化により、データ侵害、マルウェア感染、悪意のあるコードインジェクションなどのセキュリティ上の問題が発生します。 不十分なセキュリティ対策によって大きな問題が発生する可能性があるため、懸念事項に対処できるクラウド プロバイダーまたはサービス ソリューションが必要です。
このシナリオでは、ネットワーク、ID、プライバシー、承認の制御など、階層化されたセキュリティ制御を組み合わせて使用することで、最も要求の厳しいセキュリティの問題に対処します。 Fabric データ ウェアハウスには、ほとんどのデータが格納されます。 Power BI は、SSO を使用して DirectQuery 経由でデータにアクセスします。 認証には Microsoft Entra ID を使用します。 また、プロビジョニングされたプール内のデータ承認に対する広範なセキュリティ制御もあります。
次の一般的なセキュリティ上の懸念事項を考慮してください。
どのデータを表示できるかを定義します。
データ侵害リスクを軽減するために、データが連邦政府、地方、および会社のガイドラインに準拠していることを確認します。 Fabric には、セキュリティをサポートし、コンプライアンスを促進するための包括的な データ保護機能 が用意されています。
OneLake セキュリティ は、親アイテムまたはワークスペースのアクセス許可から継承された異なるアクセス許可を持つ OneLake データへのすべてのアクセスを制御します。
ワークスペース は、アイテムを作成および管理するための共同作業環境です。 ワークスペース ロールは、このレベルで管理できます。
項目 は、1 つのコンポーネントにまとめられた一連の機能です。 データ項目は、OneLake を使用してデータをそのアイテム内に格納できるようにするアイテムのサブタイプです。 アイテムはワークスペース ロールからアクセス許可を継承しますが、追加のアクセス許可を持つ場合もあります。 アイテム内のフォルダーは、
Tables/やFiles/などのデータの格納と管理に使用されます。
ユーザーの ID を確認する方法を決定します。
ネットワークとデータの整合性、機密性、アクセスを保護するネットワーク セキュリティ テクノロジを選択します。
- ネットワーク セキュリティ オプションを使用して Fabric を セキュリティで保護 します。
脅威を検出して通知するツールを選択します。
- Fabric には、脅威検出が組み込まれていない。 Microsoft Purview コンプライアンス マネージャーの組み合わせを使用してアラートを設定し、監査ログを確認してユーザー アクティビティを追跡することをお勧めします。
Fabric OneLake でデータを保護する方法を決定します。
- Microsoft Purview Information Protection の秘密度ラベルを使用して、Fabric 上のデータを保護することができます。 一般、社外秘、高機密などのラベルは、機密情報を保護するために Word、PowerPoint、Excel などの Microsoft Office アプリで広く使用されています。 データ ソースからビジネス ユーザーまで、Fabric を通過するアイテム間でデータが自動的にフォローされます。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
このセクションでは、ソリューションで使用されるさまざまなサービスの価格の詳細について説明し、サンプル データセットを使用してこのシナリオに対して行われた決定について説明します。 Azure 料金計算ツールで開始構成を使用し、シナリオに合わせて調整します。 Fabric SKU の詳細については、「 Fabric の価格の概要」を参照してください。 Fabric の全体的な消費量の見積もりを生成する方法の詳細については、 Fabric 容量推定ツールを参照してください。
ファブリックのスケーラブルなアーキテクチャ
Fabric は、コンピューティング レベルとストレージ レベルを個別にスケーリングするために使用できる、ほとんどのワークロード用のサーバーレス アーキテクチャです。 コンピューティング リソースでは、使用量に基づいてコストが発生します。 これらのリソースは、オンデマンドでスケーリングまたは一時停止できます。 ストレージ リソースでは GB あたりのコストが発生するため、データを取り込むにつれてコストが増加します。
ファブリック ファクトリ パイプライン
3 つの主要コンポーネントがパイプラインの価格に影響を与えます。
オーケストレーションのデータ パイプライン アクティビティ: コストを最適化するには、並列フローを実装してオーケストレーションの合計時間を短縮します。
コンピューティング用のデータフロー Gen2: コストを最適化するには、不要なデータをフィルター処理し、増分抽出を処理することで ETL パイプラインを簡略化します。
コピー ジョブまたはコピー アクティビティのデータ移動: コストを最適化するには、増分抽出を使用してコピー ジョブを構成し、コピー アクティビティのスループットを調整します。
詳細については、Data Factory の価格にある「価格メーター」 タブを参照してください。
価格は、コンポーネントまたはアクティビティ、頻度、オーケストレーションに関連付けられている全体的なコンピューティングによって異なります。 パイプラインの活動やコピージョブから発生するデータ移動には、コストが発生します。 ただし、 ファブリック ミラーリング によるデータ移動に関連するコンピューティングは無料であり、ミラー化されたデータのストレージ コストは容量サイズまで解放されます。 たとえば、F64 容量を購入した場合、ミラーリング専用の 64 テラバイト (TB) の無料ストレージを受け取ります。 OneLake ストレージは、無料ミラーリング ストレージの制限を超えた場合、または容量が一時停止された場合に課金されます。
ファブリック ワークロード決定ガイド
この 決定ガイド を使用して、Fabric ワークロードのデータ ストアを選択します。 OneLake 内の統合ストレージでは、すべてのオプションを使用できます。
Fabric Lakehouse または Fabric Warehouse の SQL エンドポイントには、分析用のアドホック クエリを実行する機能が用意されています。 また、Power BI セマンティック モデルでデータのインポートまたは直接クエリを実行することもできます。 レイクハウスまたはウェアハウスに関連するコストは、SQL エンドポイントに対する SQL クエリの CU 消費量 と同じです。 コストを最適化するには、Fabric Lakehouse で Z オーダーと V オーダーを 実装してクエリのパフォーマンスを向上させます。 Data Warehouse の場合は、小さなバッチを読み取るためにクエリを最適化します。
OneLake ストレージ
OneLake ストレージは、使用されたデータの GB あたりの従量課金制料金で課金され、Fabric 容量ユニット (CU) は消費されません。 レイクハウスやデータウェアハウスなどの Fabric アイテムは、OneLake Storage を使用します。 詳細については、「Fabric の 価格」を参照してください。
OneLake のコストを最適化するには、 論理的 な削除ストレージ内のデータを含む未使用のデータを定期的に削除し、読み取り/書き込み操作を最適化することで、ストレージ ボリュームの管理に重点を置きます。 OneLake ストレージはコンピューティングとは別に課金されるため、Fabric 容量メトリック アプリで使用状況を監視することが重要です。 1 か月間の平均日次使用量に基づいて計算されるストレージ コストを削減するには、格納されるデータの量を最小限にすることを検討してください。
Power BI
このシナリオでは、要求の厳しい分析ニーズに対応するために、パフォーマンスの強化が組み込まれた Power BI ワークスペース を使用します。 コストを最適化するには、インポート モード抽出の 増分更新 を実装します。 可能な場合は、大規模なデータセットをレポートするための Direct Lake モードを実装して、Fabric 容量の全体的な負荷を軽減します。
詳細については、Power BI の価格 を参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
Azure DevOps リリース パイプラインと GitHub Actions を使用して、複数の環境にわたる Fabric ワークスペース成果物のデプロイを自動化します。 詳細については、「 Fabric ワークスペースの継続的インテグレーションと継続的デリバリー」を参照してください。
各ワークロードを個別のデプロイ テンプレートに配置し、ソース管理システムにリソースを格納します。 テンプレートは、継続的インテグレーションおよび継続的デリバリー (CI/CD) プロセスの一部としてまとめて、または個別にデプロイできます。 この方法により、自動化プロセスが簡略化されます。 このアーキテクチャには、主に次の 4 つのワークロードがあります。
- データ ウェアハウスと関連リソース
- Data Factory パイプライン
- ダッシュボード、アプリ、データセットなどの Power BI 資産
- オンプレミスからクラウドへのシミュレートされたシナリオ
ワークロードをステージングすることを検討します。 ワークロードをさまざまなステージにデプロイします。 次のステージに進む前に、各ステージで検証チェックを実行します。 この方法では、制御された方法で運用環境に更新プログラムをプッシュし、予期しないデプロイの問題を最小限に抑えます。 ブルーグリーンデプロイ 使用し、カナリアリリース 戦略を して、ライブ運用環境を更新します。
ロールバック戦略を使用して、失敗したデプロイを処理します。 たとえば、デプロイ履歴から以前に成功したデプロイを自動的に再デプロイすることができます。 Azure CLI で
--rollback-on-errorフラグを使用します。Fabric 容量の使用量を包括的に監視するために、Fabric 容量メトリック アプリを使用します。 ワークスペースの監視を使用して、Fabric ワークスペーステレメトリログの詳細な監視を行います。
Fabric 容量見積もりツールを使用して、Fabric 容量のニーズを見積もります。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
この記事では、 Fabric F64 容量 を使用して BI 機能を示します。 Fabric の専用 Power BI 容量は、F64 から最大 SKU サイズの範囲です。 詳細については、「Fabric の 価格」を参照してください。
必要な容量を確認するには、次のアクションを実行します。
容量の負荷 を評価します。
継続的な監視のために、Fabric 容量メトリック アプリ をインストールします。
ワークロード関連の 容量最適化手法使用することを検討してください。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要著者:
- ビブ・アチャリヤ |プリンシパル クラウド ソリューション アーキテクト
その他の共同作成者:
- Jim McLeod | クラウド ソリューション アーキテクト
- Miguel Myers | シニア プログラム マネージャー
- ガリーナ・ポリアコワ |シニア クラウド ソリューション アーキテクト
- ジョージ・スティーブンス |ソリューション エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。