Power BI の実装計画: データレベルの監査

  • [アーティクル]

注意

この記事は、Power BI 実装計画 シリーズの記事の一部です。 このシリーズでは、主に Microsoft Fabric 内での Power BI のエクスペリエンスに焦点を当てます。 シリーズの概要については、「Power BI 実装計画」を参照してください。

このデータレベルの監査の記事は複数の対象ユーザー向けです。

  • データ作成者とワークスペース管理者: 作成、発行、共有するセマンティック モデル (以前はデータセットと呼ばれていました)、データフロー、データマートの使用状況、採用、パフォーマンスを把握する必要があるユーザー。
  • Power BI 管理者: 組織の Power BI 監視を担当する管理者。 Power BI 管理者は、IT、セキュリティ、内部監査、その他の関連チームと共同で作業することが必要な場合があります。 また、Power BI 管理者は、パフォーマンスのトラブルシューティング時にコンテンツ作成者と共同で作業することが必要になる場合もあります。
  • Power BI 容量管理者: 組織の Premium 容量の監督を担当する管理者。 Power BI 容量管理者は、パフォーマンスのトラブルシューティング時にコンテンツ作成者と共同で作業することが必要になる場合があります。
  • センター オブ エクセレンス、IT、BI チーム: Power BI の監視も担当するチーム。 Power BI 管理者や他の関連チームと共同で作業することが必要になる場合があります。
  • システム管理者:Azure Log Analytics リソースの作成とセキュリティ保護を担当するチームであり、データ ソースを管理するデータベース管理者でもあります。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。 現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。 新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

この記事で扱う概念は、主に 3 つのコンテンツ配信スコープ (具体的にはエンタープライズ BI、部門 BI、チーム BI) 向けに作成されたソリューションに適用されます。 個人向け BI ソリューションの作成者にもこの記事の情報が役に立つ場合がありますが、主な対象読者ではありません。

基になるセマンティック モデルやデータ ソースのパフォーマンスが良好ではない場合、レポートと視覚エフェクトで優れたパフォーマンスを実現することはできません。 この記事では、セマンティック モデル、データフロー、データマートの監査と監視に焦点を当てます。 これは監査と監視シリーズの 2 つ目の記事です。「レポートレベルの監査」の記事で説明されている内容よりもツールと手法が複雑だからです。 ユーザーがレポートを作成する前に、(多くのレポートで再利用するための) 共有セマンティック モデルを作成しておくのが理想的です。 そのため、この記事と「レポートレベルの監査」の記事を併せて読むことをお勧めします。

Power BI セマンティック モデルは Analysis Services の表形式エンジンに基づいて構築されているため、Analysis Services データベースであるかのように、ローカル データ モデル (Power BI Desktop の場合) または Premium セマンティック モデル (Power BI サービスの場合) に接続できます。 そのため、Analysis Services の監査および監視機能の多くは、Power BI Premium セマンティック モデルでサポートされています。

Note

Analysis Services でホストされているモデルの詳細については、「監視の概要」を参照してください。

この記事の残りの部分では、主に Power BI サービスに発行されたモデルに焦点を当てています。

セマンティック モデル イベント ログ

時間の経過と共に、データ作成者と所有者はセマンティック モデルに関する困難にぶつかることがあります。 セマンティック モデルは次のようになる可能性があります。

作成するコンテンツのユーザビリティ、良好なパフォーマンス、採用を確実にするには、管理を担当するデータ資産の使用状況とパフォーマンスを監査することをお勧めします。 データセット イベント ログを使用できます。これは、セマンティック モデルに対して発生したユーザー生成とシステム生成のアクティビティをキャプチャします。 これらは "トレース イベント"、"データセット ログ"、"データセット アクティビティ ログ" とも呼ばれます。 これらは詳細なので、システム管理者は "低レベルのトレース イベント" と呼ぶこともよくあります。

Note

データセット名の変更は Power BI サービスとドキュメントに反映されていますが、イベント ログ操作に関するものなど、変更がまだ行われていないものが存在する可能性があります。

次の場合は、セマンティック モデル トレース イベントを分析することをお勧めします。

  • セマンティック モデルで発生したすべてのアクティビティを監査する。
  • セマンティック モデルのパフォーマンス、メモリ使用量、クエリの効率をトラブルシューティングして最適化する。
  • セマンティック モデルの更新の詳細と期間を調査する。
  • Power Query から送信される Power Query 数式言語 (M クエリ) を監視する。
  • セマンティック モデルに送信される DAX 数式と式 (Analysis Services エンジン) を監視する。
  • ワークロードと、新しいデータと最適なパフォーマンスのバランスを取る必要性に基づいて、正しいストレージ モードが選ばれたかどうかを確認する。
  • 呼び出された行レベルのセキュリティ ロール、対象のユーザー、対象のセマンティック モデルを監視する。
  • 同時使用ユーザー数を把握する。
  • セマンティック モデルを確認する (たとえば、セマンティック モデルを承認する前や、運用環境ワークスペースに発行する前に、データの品質とパフォーマンスを確認するため)。

Power BI セマンティック モデルによって生成されるイベントは、Azure Analysis Services で使用できる既存の診断ログに基づいています。 取り込んで分析できるトレース イベントには多くの種類があります。これらについては、以下のセクションで説明します。

Azure Log Analytics

Azure Log Analytics は Azure Monitor サービスのコンポーネントの 1 つです。 Azure Log Analytics と Power BI は統合されているので、Power BI ワークスペース内のすべてのセマンティック モデルからセマンティック モデル イベントを取り込むことができます。 これは Premium ワークスペースでのみサポートされます。 統合を設定して接続を有効にすると (Power BI Premium ワークスペースの場合)、セマンティック モデル イベントは自動的に取り込まれ、継続的に Azure Log Analytics ワークスペースに送信されます。 セマンティック モデル ログは Azure Data Explorer に格納されます。これは追加専用のデータベースであり、大量で準リアルタイムのテレメトリ データを取り込むために最適化されています。

Power BI Premium ワークスペースは Azure の Log Analytics ワークスペースに割り当てます。 この種類のログを有効にするには、Azure サブスクリプションで新しい Log Analytics リソースを作成する必要があります。

1 つ以上の Power BI ワークスペースからのログは、ターゲット Log Analytics ワークスペースに送信されます。 データを整理するいくつかの方法を次に示します。

  • すべての監査データに対して 1 つのターゲット ワークスペース: すべてのデータを 1 つの Log Analytics ワークスペースに格納します。 これは、同じ管理者またはユーザーがすべてのデータにアクセスする場合に役立ちます。
  • サブジェクト領域ごとに整理されたターゲット ワークスペース: サブジェクト領域別にコンテンツを整理します。 この手法は、さまざまな管理者またはユーザーが Azure Log Analytics から監査データにアクセスできる場合に特に役立ちます。 たとえば、営業データと運用データを分離する必要がある場合などです。
  • Power BI ワークスペースごとに 1 つのターゲット ワークスペース: Power BI ワークスペースと Azure Log Analytics ワークスペースの間に 1 対 1 のリレーションシップを設定します。 これは、機密性が特に高いコンテンツがある場合や、データが特定のコンプライアンスまたは規制要件の対象である場合に便利です。

ヒント

この機能に関するドキュメントとよく寄せられる質問をよく確認し、できることを明らかにして、技術要件を理解してください。 組織内のワークスペース管理者がこの機能を広く使用できるようにする前に、1 つの Power BI ワークスペースで技術的な概念実証 (POC) を行うことを検討してください。

重要

名前は似ていますが、Azure Log Analytics によって取り込まれるデータは Power BI アクティビティ ログと同じではありません。 Azure Log Analytics を使うと、Analysis Services エンジンから詳細レベルのトレース イベントを取り込むことができます。 その唯一の目的は、セマンティック モデルのパフォーマンスの分析とトラブルシューティングを支援することです。 そのスコープはワークスペース レベルです。 逆に、アクティビティ ログの目的は、特定のユーザー アクティビティ (レポートの編集、セマンティック モデルの更新、アプリの作成など) の発生頻度の把握を支援することです。 そのスコープは Power BI テナント全体です。

Power BI テナントで監査できるユーザー アクティビティの詳細については、「テナントレベルの監査」を参照してください。

[Azure Log Analytics connection for workspace administrators] (ワークスペース管理者の Azure Log Analytics 接続) テナント設定を使って、Power BI ワークスペースを既存の Azure Log Analytics ワークスペースに接続できるユーザー (必要なワークスペース管理者ロールも持つユーザー) のグループを制御します。

統合を設定する前に、セキュリティの前提条件を満たす必要があります。 そのため、Azure Log Analytics で必要なアクセス許可も持っている、または要求に応じてそれらのアクセス許可を取得できる Power BI ワークスペース管理者に対してのみ、Power BI テナント設定を有効にすることを検討してください。

ヒント

計画プロセスの早い段階で Azure 管理者と連携してください。新しい Azure リソースを作成する承認を得ることが組織内の課題である場合は特にそうです。 また、セキュリティの前提条件を計画する必要があります。 Azure の Power BI ワークスペース管理者にアクセス許可を付与するか、Power BI の Azure 管理者にアクセス許可を付与するかを決めてください。

Azure Log Analytics によって取り込まれるセマンティック モデル ログには、セマンティック モデル クエリ、クエリ統計、詳細な更新アクティビティ、Premium 容量で消費された CPU 時間などがあります。 Analysis Services エンジンからの詳細レベル ログであるため、データは冗長な可能性があります。 セマンティック モデル アクティビティが多い大規模なワークスペースでは、データ ボリュームが大量になることが一般的です。

Power BI で Azure Log Analytics を使うときのコストを最適化するには:

  • セマンティック モデル アクティビティのトラブルシューティング、テスト、最適化、または調査を積極的に行う場合にのみ、Power BI ワークスペースを Azure Log Analytics に接続します。 接続すると、ワークスペース内のすべてのセマンティック モデルに対してトレースが実行されます。
  • セマンティック モデル アクティビティのトラブルシューティング、テスト、最適化、または調査を積極的に行う必要がなくなったら、Power BI ワークスペースから Azure Log Analytics を切断します。 切断すると、ワークスペース内のすべてのセマンティック モデルで実行されているトレースは終了します。
  • データ インジェスト、格納、クエリに対してかかる Azure Log Analytics の料金に関するコスト モデルを必ず確認してください。
  • Log Analytics には、既定の 30 日間よりも長い期間データを格納しないでください。 これは、通常、セマンティック モデルの分析は即時のトラブルシューティング アクティビティに重点を置いているためです。

Azure Log Analytics に送信されたイベントにアクセスするには、いくつかの方法があります。 使用できるもの:

  • 事前構築済みの Log Analytics for Power BI Semantic Models テンプレート アプリ。
  • Azure Data Explorer (Kusto) 用の Power BI Desktop コネクタ。 Log Analytics に格納されているデータを分析するには、Kusto 照会言語 (KQL) を使います。 SQL クエリの経験がある場合は、KQL が多くの点で似ていることがわかります。
  • Azure Data Explorer の Web ベースのクエリ エクスペリエンス。
  • KQL クエリを実行できる任意のクエリ ツール。

ヒント

セマンティック モデル トレース イベントの量は多いので、データを分析するために DirectQuery モデルを開発することをお勧めします。 DirectQuery モデルを使うと、準リアルタイムでデータのクエリを実行できます。 通常、イベントは 5 分以内に到着します。

詳細については、「Azure 接続の管理」を参照してください。

チェックリスト - Azure Log Analytics を使う計画を立てる場合は、主に次のような決定とアクションを行います。

  • 技術的な POC を検討する: 小規模なプロジェクトを計画して、技術要件、セキュリティ要件、取り込むイベント、ログの分析方法を十分に把握します。
  • Log Analytics と統合するワークスペースを決定する: 分析したいセマンティック モデルを含む Premium ワークスペースを決定します。
  • すべてのワークスペースに対して Log Analytics をフルタイムで有効にするかどうかを決定する: コストを最適化するために、ログを永続的に有効にする必要がある状況 (または特定のワークスペース) があるかどうかを決定します。 トラブルシューティングが行われていないときに、ワークスペースを切断するかどうかを決定します。
  • Log Analytics データを保持する期間を決定する: 30 日の既定値よりも長い保持期間を設定する必要があるかどうかを決定します。
  • 新しい Log Analytics ワークスペースを要求するプロセスを明確にする: Azure 管理者と連携して、Power BI ワークスペース管理者が新しい Log Analytics リソースの要求を送信する方法を明確にします。
  • セキュリティのしくみを決定する: Azure 管理者と連携して、Power BI ワークスペース管理者に Azure Log Analytics ワークスペースに対する権限を付与する方法と、Azure 管理者に Power BI ワークスペースに対する権限を付与する方法では、どちらが実行しやすいかを決定します。 このセキュリティ上の決定を下すには、(コストの最適化のために) ワークスペースを定期的に接続および切断する計画を検討してください。
  • ターゲット Log Analytics ワークスペースを整理する方法を決定する: 1 つ以上の Power BI ワークスペースからのデータを整理するのに適した Azure Log Analytics ワークスペースの数を検討します。 ここで決定した内容を、ログ データにアクセスできるユーザーのセキュリティに関する決定に合わせます。
  • 接続を許可するワークスペース管理者を決定する: Power BI ワークスペースを Log Analytics ワークスペースに接続できるワークスペース管理者のグループを決定します。 この決定に合わせて、[Azure Log Analytics connection for workspace administrators] (ワークスペース管理者の Azure Log Analytics 接続) テナント設定を設定します。
  • Azure Log Analytics リソースを作成する: Azure 管理者と連携して、各 Log Analytics ワークスペースを作成します。 Azure で割り当てられているアクセス許可を確認し、Power BI の構成を問題なく実行できるように更新します。 Azure に格納されているデータが正しい地域にあることを確認します。
  • 各 Power BI ワークスペースの Log Analytics 接続を設定する: Power BI ワークスペース管理者と連携して、各 Power BI ワークスペースの Log Analytics への接続を設定します。 Log Analytics ワークスペースにログ データが正しく流れていることを確認します。
  • データを分析するクエリを作成する: ユース ケースと現在のニーズに基づいて、Log Analytics のデータを分析する KQL クエリを設定します。
  • Power BI ワークスペース管理者向けのガイダンスを含める: 新しい Log Analytics ワークスペースを要求する方法と、Power BI ワークスペースに接続する方法についての情報と前提条件を Power BI ワークスペース管理者に提供します。 また、Power BI ワークスペースを切断するのが適切な場合についても説明します。
  • データを分析するためのガイダンスとサンプル クエリを用意する: ワークスペース管理者が取り込んだデータの分析を簡単に始められるように、KQL クエリを作成します。
  • コストを監視する: Azure 管理者と連携して、Log Analytics のコストを継続的に監視します。

SQL Server プロファイラー

Power BI セマンティック モデル イベントを取り込むには、SQL Server Profiler (SQL Profiler) を使用できます。 これは SQL Server Management Studio (SSMS) のコンポーネントの 1 つです。 Power BI セマンティック モデルへの接続は SSMS でサポートされています。これは、SQL Server に由来する Analysis Services アーキテクチャに基づいているためです。

セマンティック モデルのライフサイクルのさまざまな段階で、SQL Profiler を使用できます。

  • データ モデル開発時: SQL Profiler は、Power BI Desktop のデータ モデルに外部ツールとして接続できます。 この方法は、データ モデルの検証やパフォーマンス調整を行うデータ モデラーに役立ちます。
  • セマンティック モデルが Power BI サービスに発行された後: SQL Profiler は、Premium ワークスペース内のセマンティック モデルに接続できます。 接続に XMLA エンドポイントを使用できるサポート対象のクライアント ツールは多数あり、SSMS はその 1 つです。 この方法は、Power BI サービスで発行済みセマンティック モデルを監査、監視、検証、トラブルシューティング、または調整する場合に便利です。

また、DAX Studio 内で外部ツールとして SQL Profiler を使うこともできます。 DAX Studio を使って、プロファイラー トレースを開始し、データを解析し、結果の書式を設定できます。 DAX Studio を使うデータ モデラーは、多くの場合、SQL Profiler を直接使うよりもこの方法を好みます。

注意

SQL Profiler の使用は、"データのプロファイリング" のアクティビティとは異なるユース ケースです。 Power Query エディターでデータをプロファイルすると、その特性をより深く理解できます。 データ プロファイリングはデータ モデラーにとって重要なアクティビティですが、この記事では扱いません。

次のような場合は、Azure Log Analytics ではなく SQL Profiler を使うことを検討してください。

  • Azure での Azure Log Analytics リソースの使用または作成が組織から許可されていない。
  • Power BI Desktop のデータ モデル (Power BI サービスの Premium ワークスペースに発行されていないもの) のイベントを取り込みたい。
  • (Premium ワークスペースのすべてのセマンティック モデルではなく) 1 つのセマンティック モデルのイベントを短期間取り込みたい。
  • トレース中に特定のイベントのみを取り込みたい ("クエリの終了" イベントのみなど)。
  • トレースの開始と停止を頻繁に行いたい (現在発生しているセマンティック モデル イベントを取り込む必要がある場合など)。

(この記事で前述した) Azure Log Analytics と同様に、SQL Profiler によって取り込まれるセマンティック モデル イベントは、Azure Analysis Services で使用できる既存の診断ログに基づいています。 ただし、使用できるイベントにはいくつか違いがあります。

ヒント

Analysis Services の監視に SQL Profiler を使う方法は、多くの書籍、記事、ブログ記事で取り上げられています。 その情報のほとんどは、Power BI セマンティック モデルの監視に関連しています。

重要

また、SQL Profiler を使って、Power BI サービスから基のデータ ソース (たとえば、SQL Server リレーショナル データベース) に送信されるクエリを監視することもできます。 ただし、リレーショナル データベースをトレースする機能は非推奨です。 Analysis Services エンジンへの接続はサポートされており、非推奨では "ありません"。 Analysis Services 拡張イベントを理解していて、使いたい場合は、SSMS から Power BI Desktop のデータ モデルに接続できます。 ただし、Power BI Premium ではサポートされていません。 そのため、このセクションでは、標準の SQL Profiler 接続のみに焦点を当てます。

[Allow XMLA endpoints and Analyze in Excel with on-premises datasets] (XMLA エンドポイントを許可し、オンプレミス セマンティック モデルを使って Excel で分析する) テナント設定を使うと、XMLA エンドポイントを使って Power BI サービス内のセマンティック モデルのクエリや保守を実行できるユーザー (共同作成者、メンバー、または管理者のワークスペース ロール、または個々のセマンティック モデルに対するビルド アクセス許可も割り当てられているユーザー) のグループを制御できます。 XMLA エンドポイントの使用の詳細については、「高度なデータ モデル管理」使用シナリオを参照してください。

注意

また、SQL Profiler を使って、特定の DAX 式のデバッグやトラブルシューティングを行うこともできます。 SQL Profiler は、外部ツールとして Power BI Desktop に接続できます。 DAX 式の中間結果を表示するには、"DAX 評価ログ" イベント クラスを探します。 このイベントは、モデル計算で EVALUATEANDLOG DAX 関数を使うと生成されます。

この関数は、開発とテストの目的でのみ使われます。 データ モデルを運用環境ワークスペースに発行する前に、データ モデルの計算からは削除する必要があります。

チェックリスト - SQL Profiler を使う計画を立てる場合は、主に次のような決定とアクションを行います。

  • SSMS または DAX Studio できるユーザーを決定する: SQL Profiler を使用できるように、SSMS や DAX Studio のインストールを組織内のすべての Power BI コンテンツ作成者に許可するかどうかを決定します。 依頼に応じてこれらの補助ツールをインストールするか、組織内の承認済みデータ作成者の場合にインストールされる標準セットのソフトウェアの一部をインストールするかを決定します。
  • Power BI Desktop の [外部ツール] メニューに SQL Profiler を追加する: データ作成者が SQL Profiler を頻繁に使う場合は、そのようなユーザーの Power BI Desktop の [外部ツール] メニューに自動的に追加するように IT 部門に依頼します。
  • XMLA エンドポイントを使用できるユーザーを決定する: XMLA エンドポイントを使って発行済みセマンティック モデルへの接続をすべてのユーザーに許可するか、承認済みデータ作成者のみに制限するかを決定します。 この決定に合わせて、テナント設定 [XMLA エンドポイントとオンプレミスのセマンティック モデルによる "Excel で分析" の許可] を設定します。
  • データを分析するためのガイダンスとサンプル クエリを用意する: データ作成者向けにドキュメントを作成し、セマンティック モデルの監査と監視の推奨方法を理解できるようにします。 一般的なユース ケースのガイダンスを用意し、トレース データの収集と分析を簡単に始められるようにします。

データ モデルのメタデータ

Power BI セマンティック モデルは Analysis Services エンジンに基づいて構築されているため、データ モデルのメタデータのクエリを実行できるツールを利用できます。 メタデータには、テーブル名、列名、メジャー式など、データ モデルに関するすべてが含まれています。

動的管理ビュー

Analysis Services 動的管理ビュー (DMV) では、データ モデルのメタデータのクエリを実行できます。 DMV を使うと、ある時点のデータ モデルを監査、文書化、最適化することができます。

具体的には次のことができます。

  • モデルで使われるデータ ソースを監査する。
  • モデル内でメモリの消費量が最も多いオブジェクトを検出する。
  • 列データをどの程度効率的に圧縮できるかを判断する。
  • モデル内で使われていない列を見つける。
  • アクティブなユーザー セッションと接続を監査する。
  • モデルの構造を確認する。
  • 計算テーブル、計算列、メジャー、行レベル セキュリティ (RLS) 規則で使われている DAX 式を確認する。
  • オブジェクトとメジャー間の依存関係を特定する。

ヒント

DMV は、セマンティック モデルの "現在の状態" に関する情報を取得する。 DMV から返されるデータは、ある時点で発生していることのスナップショットと考えてください。 逆に、(この記事で前述した) セマンティック モデル イベント ログでは、トレース接続がアクティブだったときにセマンティック モデルに対して発生した "アクティビティ" に関する情報を取得します。

SSMS は DMV クエリを実行するためによく使われるツールです。 また、Invoke-ASCmd PowerShell コマンドレットを使って、DMV のクエリを実行する XMLA スクリプトを作成して実行することもできます。

Power BI コミュニティではサードパーティ ツールと外部ツールも人気があります。 これらのツールは、ドキュメントが公開されている DMV を使ってアクセスを簡略化し、DMV から返されるデータを操作しています。 その一例が DAX Studio です。DMV にアクセスできる明示的な機能が含まれています。 DAX Studio には、[View Metrics] (メトリックの表示) という機能も組み込まれています。これは一般に Vertipaq Analyzer と呼ばれます。 Vertipaq Analyzer は、データ モデル内のテーブル、列、リレーションシップ、パーティションの構造とサイズを分析するためのユーザー インターフェイスを備えています。 また、データ モデルのメタデータを .vpax ファイルにエクスポート (またはインポート) することもできます。 エクスポートされたファイルには、データ モデルの構造とサイズに関するメタデータのみが含まれ、モデル データは格納されていません。

ヒント

データ モデルに関する支援が必要な場合は、.vpax ファイルを誰かと共有することを検討してください。 そうすれば、モデル データをその相手と共有することはありません。

セマンティック モデルのライフサイクルのさまざまな段階で DMV を使用できます。

  • データ モデル開発時: 好みのツールから、Power BI Desktop のデータ モデルに外部ツールとして接続できます。 この方法は、データ モデルの検証やパフォーマンス調整を行うデータ モデラーに役立ちます。
  • セマンティック モデルが Power BI サービスに発行された後: 好みのツールから、Premium ワークスペース内のセマンティック モデルに接続できます。 接続に XMLA エンドポイントを使うサポート対象のクライアント ツールは多数あり、SSMS はその 1 つです。 この方法は、Power BI サービスで発行済みセマンティック モデルを監査または検証する場合に役立ちます。

ヒント

独自の DMV クエリを (たとえば、SSMS で) 作成する場合、DMV はすべての SQL 操作をサポートしているわけではないことに注意してください。 また、一部の DMV は Power BI ではサポートされていません (Power BI ではサポートされていない Analysis Services サーバー管理者のアクセス許可が必要なため)。

[Allow XMLA endpoints and Analyze in Excel with on-premises datasets] (XMLA エンドポイントを許可し、オンプレミス セマンティック モデルを使って Excel で分析する) テナント設定を使うと、XMLA エンドポイントを使って Power BI サービス内のセマンティック モデルのクエリや保守を実行できるユーザー (共同作成者、メンバー、または管理者のワークスペース ロール、または個々のセマンティック モデルに対するビルド アクセス許可も割り当てられているユーザー) のグループを制御できます。

XMLA エンドポイント、サードパーティ ツール、外部ツールの使用の詳細については、「高度なデータ モデル管理」使用シナリオを参照してください。

ベスト プラクティス アナライザー

Best Practice Analyzer (BPA) は Tabular Editor の機能です。これは Power BI コミュニティで広く受け入れられているサードパーティ ツールです。 BPA には、データ モデルの品質、整合性、パフォーマンスを監査するのに役立つカスタマイズ可能な規則のセットが含まれています。

ヒント

BPA を設定するには、Microsoft が GitHub で提供しているベスト プラクティス規則のセットをダウンロードしてください。

BPA が役に立つのは、主に、パフォーマンスの問題を軽減できるような最適ではない設計上の決定を検出することで、モデルの整合性を高める場合です。 組織のさまざまな領域にセルフサービス データ モデラーが分散している場合に便利です。

BPA は、データ モデルの監査と管理にも役立ちます。 たとえば、データ モデルに行レベルのセキュリティ (RLS) ロールが含まれているかどうかを確認できます。 また、すべてのモデル オブジェクトに説明があるかどうかを検証することもできます。 これが役に立つのは、たとえば、データ モデルにデータディクショナリを確実に含めることが目標である場合です。

BPA を使って設計上の問題を特定し、センター オブ エクセレンスでトレーニングや文書化がさらに必要かどうかを判断する際に役立てることができます。 ベスト プラクティスと組織のガイドラインについてデータ作成者を教育するための措置を講じることもできます。

ヒント

BPA が検出できるのは、ある特性 (行レベルのセキュリティなど) の "存在" であることに留意してください。 ただし、正しく設定されているかどうかを判断するのは難しい場合があります。 そのため、対象分野の専門家による確認が必要になる場合があります。 逆に、特定の特性が "存在しない" からといって、必ずしも悪い設計とは限りません。データ モデラーが特定の設計を作成するのは正当な理由があるかもしれません。

チェックリスト - データ モデルのメタデータにアクセスする計画を立てる場合は、主に次のような決定とアクションを行います。

  • SSMS をインストールできるユーザーを決定する: 発行済みセマンティック モデルに接続できるように、SSMS のインストールを組織内のすべての Power BI コンテンツ作成者に許可するかどうかを決定します。 依頼に応じてインストールするか、組織内の承認済みデータ作成者の場合にインストールされる標準セットのソフトウェアの一部としてインストールするかを決定します。
  • サードパーティ ツールをインストールできるユーザーを決定する: ローカル データ モデルや発行済みセマンティック モデルを監視できるように、サードパーティ製ツール (DAX Studio や Tabular Editor など) のインストールを組織内のすべての Power BI コンテンツ作成者に許可するかどうかを決定します。 依頼に応じてインストールするか、組織内の承認済みデータ作成者の場合にインストールされる標準セットのソフトウェアの一部としてインストールするかを決定します。
  • ベスト プラクティス規則を設定する: 組織内のデータ モデルをスキャンできる Best Practice Analyzer 規則を決定します。
  • XMLA エンドポイントを使用できるユーザーを決定する: XMLA エンドポイントを使ってセマンティック モデルへの接続をすべてのユーザーに許可するか、承認済みデータ作成者のみに制限するかを決定します。 この決定に合わせて、テナント設定 [XMLA エンドポイントとオンプレミスのセマンティック モデルによる "Excel で分析" の許可] を設定します。
  • コンテンツ クリエイターにガイダンスを提供する: セマンティック モデルの推奨される分析方法を理解できるように、データ作成者向けドキュメントを作成します。 一般的なユース ケースについてガイダンスを提供し、DMV の結果の収集や分析、Best Practice Analyzer の使用を簡単に始められるようにします。

データ モデルとクエリのパフォーマンス

Power BI Desktop には、データ作成者がデータ モデルをトラブルシューティングし、調査する際に役立つツールがいくつか含まれています。 これらの機能の対象は、Power BI サービスに発行する前にデータ モデルを検証し、パフォーマンスを調整するデータ モデラーです。

パフォーマンス アナライザー

Power BI Desktop で使用できるパフォーマンス アナライザーでデータ モデルのパフォーマンスを監査および調査します。 パフォーマンス アナライザーは、レポート作成者が個々のレポート要素のパフォーマンスを測定する際に役立ちます。 ただし、パフォーマンスの問題の根本原因はデータ モデルの設計に関連しているのが一般的です。 このため、パフォーマンス アナライザーを使うと、セマンティック モデル作成者にもベネフィットがあります。 レポートとセマンティック モデルの作成を担当するコンテンツ作成者が異なる場合、パフォーマンスの問題をトラブルシューティングするときに連携が必要になることがあります。

ヒント

DAX Studio を使うと、パフォーマンス アナライザーで生成されたログ ファイルをインポートして分析できます。

パフォーマンス アナライザーの詳細については、「レポートレベルの監査」を参照してください。

クエリ診断

Power BI Desktop で使用できるクエリ診断で Power Query のパフォーマンスを調査します。 トラブルシューティング時や、Power Query エンジンの動作を把握する必要がある場合に便利です。

クエリ診断からは、次のような情報が得られます。

  • エラー メッセージに関する追加の詳細 (例外が発生した場合)。
  • データ ソースに送信されるクエリ。
  • クエリ フォールディングが発生しているかどうか。
  • クエリによって返された行数。
  • データ更新操作中に発生した可能性がある速度低下。
  • バックグラウンド イベントとシステム生成クエリ。

探しているものに応じて、集計、詳細、パフォーマンス カウンター、データ プライバシー パーティションのいずれかまたはすべてのログを有効にすることができます。

Power Query エディターでセッション診断を開始できます。 有効にすると、診断トレースが停止されるまで、クエリと更新の操作が収集されます。 診断が停止されるとすぐに、クエリ エディターにデータが直接設定されます。 Power Query を使って "診断" グループ (フォルダー) を作成し、そこにいくつかのクエリを追加することができます。 そうすると、標準の Power Query 機能を使って診断データを表示および分析できるようになります。

また、Power BI Desktop の [オプション] ウィンドウの [診断] セクションでトレースを有効にすることもできます。 ログ ファイルは、ローカル コンピューターのフォルダーに保存されます。 Power BI Desktop を閉じると、その時点でトレースは停止され、これらのログ ファイルにデータが設定されます。 Power BI Desktop を閉じると、任意のプログラム (テキスト エディターなど) でログ ファイルを開いて表示することができます。

クエリの評価とフォールディング

Power Query は、クエリ評価 (クエリ プランを含む) を理解するために役立つさまざまな機能をサポートしています。 また、クエリ フォールディングが発生しているのがクエリ全体かクエリ内の手順の一部かを判断するのにも役立ちます。 クエリ フォールディングは、パフォーマンス調整の最も重要な側面の 1 つです。 データ ソースを監視するときに、Power Query から送信されたネイティブ クエリを確認する場合にも役立ちます (この記事で後述します)。

Premium メトリック アプリ

トラブルシューティング時には、Power BI Premium 容量管理者と連携することが役立つ場合があります。 容量管理者は、Power BI Premium 使用率およびメトリック アプリにアクセスできます。 このアプリは、容量で発生するアクティビティに関する豊富な情報を提供できます。 その情報は、セマンティック モデルの問題のトラブルシューティングに役立ちます。

ヒント

Premium 容量管理者は、追加のユーザー (容量管理者以外) にアクセス権を付与して、Premium メトリック アプリにアクセスできるようにすることができます。

Premium メトリック アプリは、内部セマンティック モデルと初期レポート セットで構成されています。 Power BI Premium 容量 (P SKU) または Power BI Embedded (A SKU) 容量の準リアルタイム監視を実行するのに役立ちます。 過去 2 週間から 4 週間分のデータが含まれています (メトリックによって異なります)。

Premium メトリック アプリを使って、セマンティック モデルのトラブルシューティングと最適化を行います。 たとえば、メモリ占有領域が大きいセマンティック モデルや、CPU 使用率が日常的に高いセマンティック モデルを特定できます。 また、容量サイズの上限に近づいているセマンティック モデルを見つけるときにも便利なツールです。

チェックリスト - データ モデルとクエリのパフォーマンスを監視するために使う方法を検討する場合は、主に次のような決定とアクションを行います。

  • セマンティック モデル クエリのパフォーマンス目標を特定する: 優れたセマンティック モデルのパフォーマンスとは何かを十分に理解します。 特定のクエリ パフォーマンス目標を要求するタイミングを決定します (たとえば、レポートをサポートするクエリは 5 秒以内にレンダリングする必要があるなど)。 その場合、組織内のデータ作成者に確実に目標を伝達します。
  • セマンティック モデル更新のパフォーマンス目標を特定する: 特定のデータ更新目標を要求するタイミングを決定します (たとえば、15 分以内、午前 5 時前にデータ更新操作を完了するなど)。 その場合、組織内のデータ作成者に確実に目標を伝達します。
  • サポート チームを教育する: 内部のユーザー サポート チームが診断機能を理解し、Power BI ユーザーに支援が必要なときにサポートできるようにします。
  • サポートするチームとデータベース管理者をつなぐ: 各データ ソースの正しい管理者に問い合わせる方法をサポート チームに周知します (たとえばクエリ フォールディングのトラブルシューティング時)。
  • Premium 容量管理者と連携する: Premium 容量または Power BI Embedded 容量に割り当てられたワークスペースに存在するセマンティック モデルをトラブルシューティングするには、容量管理者と連携します。 必要に応じて、Premium メトリック アプリへのアクセスを要求します。
  • コンテンツ作成者にガイダンスを提供する: トラブルシューティング時に取るべき措置を理解できるように、データ作成者向けのドキュメントを作成します。
  • トレーニング資料に含める: 優れたパフォーマンスのデータ モデルを作成する方法について、データ作成者向けガイダンスを用意します。 優れた設計の習慣を早期に身につけられるように支援します。 適切な設計上の決定を下す方法をデータ作成者に教えることに重点を置きます。

データ ソースの監視

場合によっては、Power BI が接続する特定のデータ ソースを直接監視する必要があります。 たとえば、ワークロードが増加しているデータ ウェアハウスがあり、パフォーマンスの低下がユーザーから報告されている場合などです。 通常、データベース管理者またはシステム管理者がデータ ソースを監視します。

次の目的でデータ ソースを監視できます。

  • データ ソースにクエリを送信しているユーザーを監査する。
  • データ ソースにクエリを送信しているアプリケーションを監査する (Power BI など)。
  • どのクエリ ステートメントが、いつ、どのユーザーによって、データ ソースに送信されたかを確認する。
  • クエリの実行にかかる時間を決定する。
  • シングル サインオン (SSO) を使っている場合、ソース システムによって行レベルのセキュリティがどのように呼び出されるかを監査する。

監視結果を分析した後に、Power BI コンテンツ作成者が実行すべきアクションは多数あります。 例を次に示します。

  • できるだけ効率的になるように、データ ソースに送信されるクエリを調整して改良する。
  • データ ソースに送信されるネイティブ クエリを検証して調整する。
  • データ モデルにインポートされる列数を減らす。
  • データ モデルにインポートされる高精度、高カーディナリティの列を削除する。
  • データ モデルにインポートされる履歴データの量を減らす。
  • データ ソースの需要が分散するように Power BI のデータ更新時間を調整する。
  • 増分データ更新を使ってデータ ソースの負荷を軽減する。
  • 複数のセマンティック モデルを共有セマンティック モデルに統合して、Power BI のデータ更新回数を減らす。
  • 自動ページ更新設定を調整して更新頻度を上げることで、データ ソースの負荷を軽減する。
  • 計算を簡略化して、データ ソースに送信されるクエリの複雑さを軽減する。
  • データ ストレージ モードを変更し (たとえば、DirectQuery ではなくインポート モード)、データ ソースに常にかかるクエリ負荷を軽減する。
  • クエリ削減手法を使って、データ ソースに送信されるクエリ数を削減する。

システム管理者は他のアクションも実行できます。 例を次に示します。

  • Power BI データフローなどの中間的なデータ レイヤーを導入する (データ ウェアハウスが実行可能な選択肢でない場合)。 Power BI コンテンツ作成者は、データ ソースに直接接続するのではなく、データフローをデータ ソースとして使用できます。 中間データ レイヤーでは、データソース システムにかかる負荷を軽減できます。 また、データ準備ロジックを一元化できるというベネフィットもあります。 詳細については、「セルフサービス データ準備」使用シナリオを参照してください。
  • データ ソースの場所を変更して、ネットワーク待機時間の影響を軽減する (たとえば、Power BI サービス、データ ソース、ゲートウェイに同じデータ リージョンを使います)。
  • データ ソースを最適化し、Power BI のデータをより効率的に取得できるようにする。 一般的な手法として、テーブル インデックスの作成、インデックス付きビューの作成、永続化されたコンピューティング列の作成、統計の維持、インメモリまたは列ストア テーブルの使用、具体化されたビューの作成などがあります。
  • 元の運用環境データベースではなく、データ ソースの読み取り専用レプリカを使うようにユーザーに指示する。 高可用性 (HA) データベース戦略の一環として、レプリカを使用できる場合があります。 読み取り専用レプリカの利点の 1 つは、ソース システムでの競合を減らせることができます。

データ ソースの監視に使用できるツールと手法は、テクノロジ プラットフォームによって異なります。 たとえば、データベース管理者は、Azure SQL Database と SQL Server データベースの監視に拡張イベントまたはクエリ ストアを使用できます。

場合によっては、Power BI はデータ ゲートウェイ経由でデータ ソースにアクセスします。 ゲートウェイは、Power BI サービスから特定の種類のデータ ソースへの接続を処理します。 ただし、ゲートウェイはデータに接続するだけではありません。 ゲートウェイには、マシン上で処理とデータ変換を実行するマッシュアップ エンジンが含まれています。 また、Power BI サービスに効率的かつセキュリティで保護された方法で送信できるように、データを圧縮および暗号化する機能もあります。 そのため、管理されていない、または最適化されていないゲートウェイがパフォーマンスのボトルネックの原因になる可能性があります。 ゲートウェイの監視については、ゲートウェイ管理者に相談することをお勧めします。

ヒント

Power BI 管理者は、完全なテナント インベントリ (系列を含む) をコンパイルし、アクティビティ ログのユーザー アクティビティにアクセスできます。 系列とユーザー アクティビティを関連付けることで、管理者は使用頻度が高いデータ ソースとゲートウェイを特定できます。

テナント インベントリとアクティビティ ログの詳細については、「テナント レベルの監査」を参照してください。

チェックリスト - データ ソースを監視する計画を立てる場合は、主に次のような決定とアクションを行います。

  • 具体的な目標を決定する: データ ソースを監視する場合、達成する必要があることの具体的な内容と、トラブルシューティングの目標を明確にします。
  • データベース管理者と連携する: 特定のデータ ソースを監視する場合は、データベース管理者またはシステム管理者と連携して支援を受けます。
  • ゲートウェイ管理者と連携する: データ ゲートウェイを経由して接続するデータ ソースの場合は、トラブルシューティング時にゲートウェイ管理者と連携します。
  • サポートするチームとデータベース管理者をつなぐ: 各データ ソースの正しい管理者に問い合わせる方法をサポート チームに周知します (たとえばクエリ フォールディングのトラブルシューティング時)。
  • トレーニングとガイダンスを更新する: 組織のデータ ソースを操作する方法について、データ作成者向けの重要な情報とヒントを含めます。 何か問題が発生した場合の対処方法に関する情報を含めます。

データ更新の監視

データ更新操作には、基となるデータ ソースから Power BI セマンティック モデル、データフロー、またはデータマートへのデータのインポートが含まれます。 データ更新操作をスケジュールするか、オンデマンドで実行することができます。

サービス レベル アグリーメント

一般的に、IT 部門はサービス レベル アグリーメント (SLA) を使ってデータ資産に対する期待を文書化します。 Power BI の場合、重要なコンテンツまたはエンタープライズレベルのコンテンツに SLA を使うことを検討してください。 一般的に、セマンティック モデル内の更新されたデータをユーザーが使用できるようになる時期を含めます。 たとえば、すべてのデータ更新は毎日午前 7 時までに完了する必要があるという SLA を設定できます。

セマンティック モデル ログ

Azure Log Analytics または SQL Profiler (この記事で前述) のセマンティック モデル イベント ログには、セマンティック モデルで起こっていることの詳細情報が含まれています。 取り込まれるイベントには、セマンティック モデルの更新アクティビティなどがあります。 イベント ログは、セマンティック モデル更新をトラブルシューティングし、調査する必要がある場合に特に便利です。

Premium 容量セマンティック モデル

Power BI Premium 容量でホストされているコンテンツがある場合、データ更新操作を監視する機能がより充実しています。

  • 管理ポータルの Power BI 更新の概要ページには、更新履歴の概要が表示されます。 この概要には、更新期間とエラー メッセージに関する情報が表示されます。
  • Power BI Premium の使用率およびメトリック アプリにも、役に立つ更新情報が表示されます。 Power BI Premium 容量 (P SKU) または Power BI Embedded (A SKU) 容量の更新アクティビティを調査する必要がある場合に便利です。

強化されたセマンティック モデル更新

コンテンツ作成者は、強化された更新とグループの更新データセット Power BI REST API を使うことで、プログラムでセマンティック モデルの更新を開始できます。 強化された更新を使う場合、履歴、現在、保留中の更新操作を監視できます。

データ更新のスケジュール監視

Power BI 管理者は、テナント内のデータ更新スケジュールを監視して、特定の期間 (たとえば午前 5 時から午前 7 時の間は、データ更新が特に混雑する時間帯である可能性があります) に同時にスケジュールされている更新操作が多数あるかどうかを判断できます。 管理者は、メタデータ スキャン API (スキャナー API と呼ばれます) からセマンティック モデル更新スケジュール メタデータにアクセスするアクセス許可を持っています。

Power BI REST API

重要なセマンティック モデルの場合、データ更新の問題を監視する手段はメール通知だけに頼らないでください。 データ更新履歴を中央のストアにまとめ、監視、分析、対処できるようにすることを検討してください。

データ更新履歴は、次の方法で取得できます。

ヒント

レポートやダッシュボードで最新のデータを使用できるように、セマンティック モデルの更新履歴を監視することを強くお勧めします。 また、SLA が達成されているかどうかを把握するためにも役立ちます。

チェックリスト - データ更新の監視を計画する場合は、主に次のような決定とアクションを行います。

  • 具体的な目標を決定する: データ更新を監視する場合、達成する必要があることの具体的な内容と、監視のスコープを明確にします (たとえば、運用環境のセマンティック モデル、認定済みセマンティック モデルなど)。
  • SLA の設定を検討する: データの可用性セットとデータ更新スケジュールの実行時期を設定するために、SLA が役に立つかどうかを決定します。
  • データベースとゲートウェイの管理者と連携する: データベースまたはシステム管理者、ゲートウェイ管理者と連携して、データ更新の監視やトラブルシューティングを行います。
  • サポート チームへの知識の伝達: データ更新の問題が発生したときに、コンテンツ作成者を支援する方法をサポート チームに周知します。
  • トレーニングとガイダンスを更新する: 組織のデータ ソースと共通のデータ ソースのデータを更新する方法について、データ作成者向けの重要な情報とヒントを含めます。 データ更新の管理方法に関するベスト プラクティスと組織の設定を含めます。
  • 通知用のサポート メール アドレスを使う: 重要なコンテンツについては、サポート メール アドレスを使うように更新通知を設定します。
  • 一元化された更新監視を設定する: Power BI REST API を使ってデータの更新履歴をまとめます。

データフローの監視

Power Query Online で Power BI のデータフローを作成します。 前述のクエリ パフォーマンス機能、Power Query 診断の多くが適用されます。

必要に応じて、内部ストレージではなくデータフロー ストレージ (bring-your-own-storage と呼ばれます) に Azure Data Lake Storage Gen2 を使うようにワークスペースを設定できます。 bring-your-own-storage を使う場合、ストレージ アカウントのメトリックを監視できるように、テレメトリを有効にすることを検討してください。 詳細については、「セルフサービス データ準備」使用シナリオと「高度なデータ準備」使用シナリオを参照してください。

Power BI REST API を使ってデータフロー トランザクションを監視できます。 たとえば、[Get Dataflow Transactions] (データフロー トランザクションの取得) API を使ってデータフロー更新の状態を確認できます。

Power BI アクティビティ ログを使って Power BI データフローのユーザー アクティビティを追跡できます。 詳細については、「テナントレベルの監査」を参照してください。

ヒント

データフロー設計を最適化するために採用できるベスト プラクティスは多数あります。 詳細については、「データフローのベスト プラクティス」を参照してください。

データマートの監視

Power BI のデータマートには、データフロー、マネージド データベース、セマンティック モデルなど、いくつかの統合コンポーネントが含まれています。 各コンポーネントの監査と監視については、この記事の前述のセクションを参照してください。

Power BI アクティビティ ログを使って Power BI データマートのユーザー アクティビティを追跡できます。 詳細については、「テナントレベルの監査」を参照してください。

関連するコンテンツ

このシリーズの次の記事では、テナントレベルの監査について学習します。