はじめに
2023年5月に Microsoft Fabric が発表され、データ分析を取り巻く世界が変わる予感がする中ではありますが、前回の Power BI Desktop 編の続きとなる、Power BI サービス編をお送りしていきたいと思います。Power BI サービスからデータソースへ接続する際は、接続モードの他に、オンプレミスデータゲートウェイ経由にしないといけないケースもあるため、そのような場合についてもどれくらいパフォーマンスに影響が出るか検証していきたいと思います。
注意事項(再掲)
本記事の結果は、サンプルケースで測定された検証結果です。実際の利用環境(レポートデザイン、データモデル、データ量、ネットワーク、データソースの種類、同時実行数など)によっては、パフォーマンスに大きな違いが生じる可能性があります。そのため、本記事はあくまで参考程度にとらえていただき、実際のパフォーマンスはご自身の実行環境で試してみることをお勧めします。
今回使用した検証環境
- プラットフォーム :Power BI サービス
※ 今回の手順は、DAX Studio から Power BI サービスのデータセットに、XMLA エンドポイント接続するため、Premium Per User もしくは Premium Per Capacity が必要です - データソース:Azure SQL Database
- 接続モード:
- インポート
- DirectQuery
- DirectQuery(オンプレミスデータゲートウェイ経由)
- ハイブリッド テーブル
- ハイブリッド テーブル(オンプレミスデータゲートウェイ経由)
でレポートを表示した場合のパフォーマンスを測定していきます。
全体図
Azure 基盤 のスペック
-
Azure SQL Database
- モデル : vCore
- コンピューティングレベル : サーバーレス
- サービスレベル : 汎用
- ハードウェアの種類 : Standard シリーズ (Gen5) : 最大仮想コア数 16 で設定
- リージョン : 東日本
-
Azure VirtualMachine (オンプレミスデータゲートウェイ用)
- OS : Windows Server 2022 Datacenter
- サイズ : Standard B8ms (8 vcpu、32GiB メモリ)
- リージョン : 東日本
その他
以下については前回の Power BI Desktop 編と同様です
測定検証パターン
検証パターンとして、インポート、DirectQuery、DirectQuery(オンプレミスデータゲートウェイ経由)、ハイブリッドテーブル、ハイブリッドテーブル(オンプレミスデータゲートウェイ経由)の 5 つのパフォーマンスを比較します。
No | 接続方式 | オンプレミスデータゲートウェイ | データソース |
---|---|---|---|
1 | インポート | Azure SQL Database | |
2 | DirectQuery | Azure SQL Database | |
3 | DirectQuery | 〇 | Azure SQL Database |
4 | ハイブリッド テーブル | Azure SQL Database | |
5 | ハイブリッド テーブル | 〇 | Azure SQL Database |
Power BI サービスでのパフォーマンス測定方法
Power BI サービスでは、Power BI Desktop 編で使用したパフォーマンスアナライザは使えないため、どのような形でパフォーマンス測定をするべきか迷いましたが、以下の方法でパフォーマンス測定することにしました。
- Power BI サービスでのレポートのページ全体の表示時間
- 初回表示(ブラウザの更新ボタンを押下してから表示完了までの時間)
- スライサー変更 (日付の期間を 2018年1月1日~2023年4月30日 → 2017年1月1日~2023年4月30日 に変更)
- 各ビジュアルを表示するために実行される DAX クエリの実行時間
Power BI Desktop 編では、各ビジュアルの表示時間を計測していましたが、今回はページ全体の表示時間のみとします。初回起動時は読み込みなどに時間がかかるため、初回表示とスライサー変更の 2 種類のパフォーマンス測定を行うとともに、それぞれ各ビジュアルの DAX クエリの時間も測定します。
これらを計測するために以下の 2 つのツールを使用します
パフォーマンス測定ツール
-
Microsoft Edge DevTools
-
ページ全体の表示時間を取得
※パフォーマンス機能を利用
-
ページ全体の表示時間を取得
-
DAX Studio
- 各ビジュアル表示ために発行される DAX クエリの実行時間を取得
測定準備
-
DAX Studio を Power BI サービスのデータセットへ接続する
-
Microsoft Edge DevTools (特別な設定無し)
測定手順
-
測定手順(※初回表示(ブラウザ更新)の時間)
-
測定手順(※2 回目表示(スライサー変更)の時間)
- Microsoft Edge DevTools のパフォーマンスの結果画面でクリアボタンを押す
- DAX Studio で、キャッシュのクリアを行う
初回表示時のキャッシュが残っているため、2回目表示測定のために、DAX Studio の 「Home」→ 「Clear Cache」ボタンをクリックしてキャッシュをクリアする
- SQL Database のデータベースのキャッシュクリア
以下のクエリを SSMS などで発行し、SQL Database のクエリキャッシュをクリアする
CHECKPOINT; GO DBCC DROPCLEANBUFFERS; GO
- Microsoft Edge DevTools のパフォーマンスの結果画面でクリアボタンを押す
-
測定手順(※DAX のクエリ実行時間)
検証結果
それでは、上記条件で実行していったパフォーマンス測定結果を以下掲載していきます。
※表示時間の太字はその中での最長時間
1. Power BI サービス - インポート
初回表示(ブラウザ更新)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 7706 ミリ秒 | - |
カード | 47 ミリ秒 | ||
縦棒グラフ | 63 ミリ秒 | ||
地図 | 31 ミリ秒 | ||
折れ線グラフ | 47 ミリ秒 | ||
散布図 | 219 ミリ秒 |
2 回目表示(スライサー変更)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 780 ミリ秒 | - |
カード | 78 ミリ秒 | ||
縦棒グラフ | 78 ミリ秒 | ||
地図 | 47 ミリ秒 | ||
折れ線グラフ | 62 ミリ秒 | ||
散布図 | 188 ミリ秒 |
2. Power BI サービス - DirectQuery
初回表示(ブラウザ更新)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 11409 ミリ秒 | - |
カード | 6110 ミリ秒 | ||
縦棒グラフ | 6156 ミリ秒 | ||
地図 | 4095 ミリ秒 | ||
折れ線グラフ | 3969 ミリ秒 | ||
散布図 | 6156 ミリ秒 |
2 回目表示(スライサー変更)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 6262 ミリ秒 | - |
カード | 5156 ミリ秒 | ||
縦棒グラフ | 4672 ミリ秒 | ||
地図 | 4125 ミリ秒 | ||
折れ線グラフ | 3969 ミリ秒 | ||
散布図 | 4891 ミリ秒 |
3. Power BI サービス - DirectQuery(オンプレミスデータゲートウェイ経由)
初回表示(ブラウザ更新)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 18613 ミリ秒 | - |
カード | 5328 ミリ秒 | ||
縦棒グラフ | 6188 ミリ秒 | ||
地図 | 12281 ミリ秒 | ||
折れ線グラフ | 3578 ミリ秒 | ||
散布図 | 6109 ミリ秒 |
2 回目表示(スライサー変更)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 13709 ミリ秒 | - |
カード | 5817 ミリ秒 | ||
縦棒グラフ | 5786 ミリ秒 | ||
地図 | 12931 ミリ秒 | ||
折れ線グラフ | 3877 ミリ秒 | ||
散布図 | 5220 ミリ秒 |
4. Power BI サービス - ハイブリッド テーブル
初回表示(ブラウザ更新)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 9501 ミリ秒 | - |
カード | 1159 ミリ秒 | ||
縦棒グラフ | 797 ミリ秒 | ||
地図 | 1719 ミリ秒 | ||
折れ線グラフ | 1594 ミリ秒 | ||
散布図 | 2234 ミリ秒 |
2 回目表示(スライサー変更)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 3213 ミリ秒 | - |
カード | 1141 ミリ秒 | ||
縦棒グラフ | 828 ミリ秒 | ||
地図 | 1360 ミリ秒 | ||
折れ線グラフ | 1453 ミリ秒 | ||
散布図 | 2031 ミリ秒 |
5. Power BI サービス - ハイブリッド テーブル(オンプレミスデータゲートウェイ経由)
初回表示(ブラウザ更新)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 10079 ミリ秒 | - |
カード | 1250 ミリ秒 | ||
縦棒グラフ | 891 ミリ秒 | ||
地図 | 1500 ミリ秒 | ||
折れ線グラフ | 1469 ミリ秒 | ||
散布図 | 2141 ミリ秒 |
2 回目表示(スライサー変更)
項目 | ビジュアル | 表示時間 | (うち、DAX クエリ実行時間) |
---|---|---|---|
レポート全体の表示時間 | - | 3771 ミリ秒 | - |
カード | 1297 ミリ秒 | ||
縦棒グラフ | 859 ミリ秒 | ||
地図 | 1594 ミリ秒 | ||
折れ線グラフ | 1609 ミリ秒 | ||
散布図 | 2359 ミリ秒 |
まとめ
接続モード | レポート表示時間(初回表示(ブラウザ更新)) | レポート表示時間(2 回目表示(スライサー変更)) |
---|---|---|
インポート | 7706 ミリ秒 | 780 ミリ秒 |
DirectQuery | 11409 ミリ秒 | 6262 ミリ秒 |
DirectQuery(オンプレミスデータゲートウェイ経由) | 18613 ミリ秒 | 13709 ミリ秒 |
ハイブリッド テーブル | 9501 ミリ秒 | 3213 ミリ秒 |
ハイブリッド テーブル(オンプレミスデータゲートウェイ経由) | 10079 ミリ秒 | 3771 ミリ秒 |
今回の環境では、パフォーマンスとしては、
インポート > ハイブリッド テーブル ≒ ハイブリッド テーブル(オンプレミスデータゲートウェイ経由)> DirectQuery > DirectQuery(オンプレミスデータゲートウェイ経由)
となりました。
Power BI Desktop 編同様、やはりインポートは爆速で、DirectQuery はやや待たされる感じ、ハイブリッド テーブルは中間くらいという結果が出ました。
また、オンプレミスデータゲートウェイについては、DirectQuery は大きく影響が出るのに対し、ハイブリッド テーブルではあまり影響が出なかった点は意外でした。このあたりは環境によっては結果が変わるのかもしれません。
接続モードの選択は、要件やその時の環境によるとは思いますが、こちらの検証結果も一つの参考情報として検討いただければと思います。
補足
Microsoft Fabric では Direct Lake という新しい接続方式が出てきているため、こちらも頃合いをみて検証していきたいと思います。