Power BIについて話す際、最終的に取り上げられるテーマは必ず「パフォーマンス」です。レポートの表示パフォーマンス、それに影響を与えるクエリパフォーマンス、また、データをPower BIセマンティックモデルに複製する際のパフォーマンスなど、さまざまなパフォーマンスに関連するトピックがあります。今回はPower BIにはパフォーマンスをトラッキングする機能である「パフォーマンスアナライザー」について詳しく解説したいと思います。
パフォーマンスアナライザーの概要
Power BIの公式ドキュメントにパフォーマンスアナライザーについての記載がしっかりありますので、使い方や簡単な用語解説については下記をまず参考にして頂きたいと思います。
パフォーマンスアナライザーはユーザーの操作を記録し、各レポートビジュアルごとにDAXクエリやDirectQueryを含むレポートの動作を詳細に分析できます。恐らく多くの方が活用しているように、最も一般的な使用法は以下の通りかと考えられます。
目的: 遅いDAXメジャーを特定する
方法: 目星をつけたビジュアルを探し出し、クエリをコピーしてDAX Studioで測定（類似記事）
ステップ:
DAXクエリをコピーするところまでしか動画はありませんが、一般的にはこの手法を用いてパフォーマンスの低いDAXクエリを特定していくことになります。期間（ミリ秒、正しい翻訳は「時間」）は英語ではDuration (ms）ですが、数値が高い程、パフォーマンスが悪いことを意味します。1ms = 1秒の1/1000ですので、500であった場合、0.5秒となります。通常、DAXクエリが60ms以下であれば誤差とされており、例えば40msと60msは同程度のパフォーマンスと考えることができます。
ただし、このような方法でパフォーマンスアナライザーを使用することは推奨されていますが、これだけを見ても現実の状況を完全に反映しているわけではありません。つまり、Power BI Desktopでのテスト結果は、実際の運用環境ではデータ量、ソースローディング、同時アクセス数、セキュリティの設定（RLSなど）、地理的な要因、オンプレミスデータゲートウェイなどの様々な要素によって結果が大きく異なる可能性があります。したがって、Power BIサービス上のレポートのパフォーマンスは、Power BI Desktopで計測した時のパフォーマンスとこれらの条件によって異なる可能性があることに留意してください。
Power BIにおけるキャッシュ
Power BIにおけるキャッシュ（もしくはキャッシング）は良く知られているものですが、少し解説します。キャッシングは、数十年にわたりコンピューティングで使用されてきた確立されたメカニズムであり、頻繁に使用されるシナリオのパフォーマンスを向上させるためのシンプルな手段として、一部の実行結果をローカルに保存して高速に再利用する方法です。
下図はビジュアルが更新された場合、キャッシュ前とキャッシュ後をパフォーマンスアナライザーで調べた結果です。b（キャッシュあり）のほうが、a（キャッシュなし）よりも何倍もパフォーマンスが良くなっているのが分かります。
この後、図の一番上にある「ビジュアルを更新します」をクリックした場合、結果はaではなく、bに近い結果になります。キャッシュされた状態ではどうやってもパフォーマンスを正しく見ることが難しくなりますので、前述のDAX Studioでキャッシュをクリアして測定（リンク先⑥のステップを実行）する必要があるわけです。
Power BI Desktopでキャッシュをクリアした状態でパフォーマンスアナライザーを使用するには以下のステップに従う必要があります。
- Power BI Desktopで空のタブを作る
- そのタブに移動し、pbixを保存して閉じる
- 閉じたpbixを開く（空白タブが表示される）
- パフォーマンスアナライザーを立ち上げ、「記録の開始」をクリック
- 対象のタブに移動する（ビジュアルが全て自動で更新される）
ここまでの作業は手間がかかりますが、Power BI Desktopでは、調査したいレポートページがアクティブになった段階でPower BIレポートが更新されるため、キャッシュを除外した状態（コールドキャッシュ）で結果を見るにはこれまでの手順は不可欠です。動画を見ることで理解しやすくなるかもしれませんので、GIACからもこれらのステップを確認できます。
様々なアクションをトラッキング
レポートのパフォーマンスを向上させるために特定の要因を見つけることが一つの有効な手段ですが、さらに、パフォーマンスアナライザーは実際にユーザーが実施した操作を記録してくれます。以下その概要となります。
- ページの変更
Power BIのタブやカスタムナビゲーションを活用した際にページ変遷をした記録
- クロスハイライト（クロス強調表示）
Power BIでビジュアルの要素をクリックした際にクロスハイライトされた他のビジュアルの更新
- スライサーの変更
スライサーの値が変更された際にトリガーされるが、Query Reductionを使用した場合、適用を押してキャプチャを有効にする必要がある
- フィルターの変更
レポートのフィルターが変更された場合に記録され、Query Reductionの挙動はスライサーと同じ
- ビジュアル毎にキャプチャできるもの
- DAXクエリ
- DirectQuery（直接クエリ）
- ビジュアルの表示
- その他
DAX Query（DAX query）
Power BIのビジュアルは、ピボットテーブルの概念に従ってグループ化された結果（文字列や数値の集合）となります。これらのビジュアルを構成するためにはDAXクエリが必要であり、これはPower BIレポートのパフォーマンスに重要な影響を与えます。DAXクエリはクエリを発行する必要がある時にだけ表示され、ビジュアルから発行されたクエリがAnalysis Service Engine（ASエンジン = Power BIの分析エンジン）が結果を返すまでの時間を示してくれます。結果に影響する要因にはデータソースまでのユーザーの物理的な距離も含まれます。
直接クエリ（Direct query）
DirectQueryのデータソースに対応している場合にだけ表示されます。ASエンジンがデータソースに対して外部クエリを発行し、その結果を受け取るまでの時間が計測されます。SQL Server Profilerから確認できるASエンジンDirectQueryクラスイベントのタイミングと一致します。
モデルが最適化され、データ量が少なく、データソースまでの遅延がないなどの状況では、DAXクエリとDirectQuery（直接クエリ）の結果はほぼ同じになりますが、中にはDAXクエリの実行時間がDirectQueryよりも大幅に長くなるケースがあることがあります。
Chrisが書いたブログにその事象が記述されていますが、技術的にディープダイブが必要なコンテンツとなっています。
ビジュアルの表示（Visual display）
「ビジュアルの表示」はビジュアル（視覚効果）がスクリーン上で結果を表示するまでにかかる時間です。これには外部オブジェクト（例: 画像、複雑なカスタムビジュアル、ジオコーディング等）を取得するための時間も含まれます。カスタムビジュアルやデータポイントの多いマップビジュアルの頻繁な利用によって、この段階での処理に費やされる時間が長くなることがあります。
その他（Other）
ビジュアルの表示以外のアクティビティは「その他」に含まれます。例えば、クエリの準備や他のバックグラウンド処理にかかる時間、また他のビジュアルの完了を待つ時間も含まれます。ページに新しいビジュアルを追加するたびに、各ビジュアルごとに「その他」としての数値が増加します。必ずしも悪いことではないが、これによりビジュアルヘビーなレポートになり、"もっさり感"が強まる可能性が高くなります。
従って、下図のようにDAXクエリのパフォーマンスが良くても、「その他」の時間が大きくなっている場合には注意が必要となります。
特に1つのタブに複数のオブジェクト（例: 図形、画像、スライサー、チャート・テーブルビジュアル等）が配置されている場合、「他のビジュアルの完了を待つ時間」が肥大化するため、可能な限りオブジェクトを減らすことが肝要となります。明確な目安を示すことは難しいですが、1つのタブに30-50ものビジュアルが配置されていた場合、レポートのパフォーマンスが顕著に低下する可能性が高くなります（特にクエリを発行するビジュアルの場合）。
その他、パフォーマンスアナライザーに関する説明は下記SQLBIの記事が分かりやすいでしょう。
DAXクエリビューで実行
昨年末からDQV（DAX Query View）が登場し、パフォーマンスアナライザーから直接DQVへDAXクエリを展開できるようになりました。
パフォーマンスアナライザーを使用する理由は、先述の通り、DAX Studioにクエリを貼り付け、パフォーマンスチューニングを行うことでした。したがって、上図の機能自体があまり役に立たないのかと思いましたが、実際にクリックしてみるとそうでもないことが分かりました。
以下は、テーブルを更新したDAXクエリですが、先頭に「pageTitle列が空白以外」（記事タイトル <> 空白）というフィルターが適用されていることを発見しました。これはビジュアルレベルのフィルターであり、ビジュアルごとに気づかないフィルターが適用されていることを見つけるのに役立ちそうです。
今回はパフォーマンスアナライザーの概要について解説しました。次回は、パフォーマンスアナライザーで検知した「その他」の”謎”について詳細に説明していきたいと思います。
