前回はFabricを使用してPower BIのレポートを構築する方法について解説しました。今回は、Power BI Desktopで作成されたデータセットに対してライブ接続を行った場合の留意点について説明をします。データセットは、Excelでいうテーブルに相当しますが、Power BIではより複雑な構造を持つセマンティックモデルを表すものです。このセマンティックモデルは、テーブルやリレーションシップ、DAXメジャーなどを含み、データのまとまりとその構造を定義します。
※注意
「データセット」は別名「セマンティックモデル」に変更となっています。
Datasets renamed to semantic models | Microsoft Power BI Blog | Microsoft Power BI
BI導入プロセス
典型的なPower BIによる構築プロセスは下図のようになります。データソースに対してPower BI DesktopでETLやモデリング、そしてレポートを可視化します。その結果をクラウド環境であるPower BI Serivceへ発行し、発行されたレポートをユーザーが参照して分析し、得られた”洞察”を元にビジネス上の意思決定へと繋げていきます。
このやり方自体は社内に多くのエンドユーザーがいる場合に問題はないのですが、自分で作られたデータセットを参照して、独自のレポートを作りたいというユーザーがいる場合には少しやり方を変える必要があります。
ライブ接続
自分でモデル開発者が作ったデータセットをソースとして、独自のレポートを作る場合はライブ接続を使用します（下図のイメージ）。
Power BI Desktopではホーム > データの取得 > Power BI データセットの順番にクリックしますが、既に構築済のデータセットである必要があり、ここでの構築済というのはリレーションシップやDAXメジャーの定義が済んでいるところまでを含みます。
ライブ接続のメリットは複数ありますが、主に以下のものが挙げられます。
-
リアルタイムデータの表示
ライブ接続を使用すると、データソースが更新されるたびにPower BI Desktopのレポートもリアルタイムで更新されます。これにより、常に最新の情報を確認できます。 -
大規模なデータセットの対応
ライブ接続では、データをPower BI Desktopに取り込む必要がないため、大規模なデータセットにも対応しやすくなります。データの取り込みに時間がかからず、メモリの制限にも制約されません -
データのセキュリティ
ライブ接続を使用する場合、データはデータソースに保管され、Power BI Desktopのファイルにデータが複製されることはありません。これにより、データのセキュリティが強化されます。特に秘密度ラベルが適用されたpbixは自分が所属する組織以外のアカウントからデータへのアクセスができないため、セキュリティの担保が保たれます -
更新の自動化
ライブ接続をPower BI Service（クラウド）に発行する場合、データソースが更新されるとPower BI Service上のレポートも自動的に更新されます。定期的なデータの更新を自動化できます -
軽量なファイルサイズ
ライブ接続を使用することで、Power BI Desktopのファイル（pbix）サイズが大幅に軽減されます。データが直接データソース（クラウド上）にあるため、ファイルにデータが含まれる必要がなくなり、レポートデザイナーはレポート構築に専念しやすくなります
なお、デメリットとしてはデータソースへの接続状態が必要であるため、オフライン環境では使用できないことに留意する必要があります。
ここで前回作ったデータセット（DS_Contoso）へのライブ接続を行ってみます。
- Power BI Desktop > ホーム > データを取得 > Power BI データセット
ちなみに、レポートを作成する際に以下のようなエラーが発生した場合は、同じ形でデータセットを再作成することでエラーを回避できる場合があります。エラーの具体的な原因は不明ですが、Fabricで作成されたDirect Lakeのデータセットはプレビュー機能と関連していると考えられます。
運悪く、前回デモ用に作ったデータセット（DS_Contoso）でこれが起こりましたので、今回は全く同じDS_Contoso_02をソースとします。 - ライブ接続されたPower BI Desktop
以下、①～③について簡単な解説。- レポートビュー、モデルビューの2つのみ
通常のインポートモードとは異なりデータ自体はPower BI サービスに存在するため、データビューはありません。モデルビューは下図のようになりますが、ストレージモードからはDirect Lakeモデルであることが確認できません（ここが現時点非常に混乱しがちな部分で後で詳述）。
- テーブル情報
インポートモードと同じ見た目ですが、ウェブモデルで作ったDAXメジャーをクリックしても、数式バーは表示されず、最初はどのような定義式になっているかを確認できません。
定義式を確認するためには、2つの方法があります。1つは、ウェブオーサリングを使用してPower BI Serviceでモデルを開いて確認することです。もう1つは、Power BI Desktopから確認したい場合です。この場合、以下の手順に従ってウェブからモデルを開き、該当するDAXメジャーのプロパティにある「説明」にメモを残しておく必要があります。
上記記述が完了した後、Power BI Desktopの更新ボタンをクリックすれば、以下のように当該メジャーの説明を見ることができるようになります。
- 接続情報・接続方式の変更
接続情報は接続タイプ（ライブ接続 or DirectQuery接続）とワークスペース名（Demo_Fabric）、そしてデータセット名（DS_Contoso_02）の3つを確認できます。
なお、一番右の「このモデルに変更を加える」をクリックすると、ライブ接続からDirectQueryへの接続方式の変更を注意するダイアログボックスが出現します。
「ローカルモデルの追加」をクリックすると、以下のようにモデリングで既に選択されたテーブルを非選択することができるようになります。
ローカルモデルを追加した場合、既にPower BI Serviceに存在するデータセット（DS_Contoso_02）に対して、例えばExcelで作った予算データを追加して予実比較ができるようになり、ローカルモデル（Excel）とリモートモデル（DS_Contoso_02）による複合モデル（Composite Model）を構築できるようになります。
複合モデルはDirectQuery方式を採用しているため、便利な一方でクエリのパフォーマンスや様々な制限が影響を受ける可能性があります。したがって、複合モデルを構築する際には、以下のガイダンスをよく理解しておくことが重要です。
- レポートビュー、モデルビューの2つのみ
Direct Lakeに対するライブ接続
ライブ接続はPower BI ServiceにあるデータセットやAzure Analysis Services、SQL Server Aanlysis Services等へ接続するものであり、DAXクエリを送って結果をPower BI Desktopにあるレポートで返す作業となります。
ライブ接続はPower BIでは、新たにデータセットを作成せずに既存のPower BI Desktopで作成されたデータセットにレポートを接続できるという点がメリットです。しかし、2023年7月時点では、ストレージモードに新たにDirect Lakeが登場したことにより、混乱が生じやすい状況になっています。
上図の各種ストレージモードは、すべてウェブオーサリングで確認できますが、前述したように、Power BI Desktopのライブ接続からはインポートモードかDirect Lakeモードかを確認することができません。（下図）。
しかし、唯一DirectQueryだけはPower BI Desktopからでも確認ができます。
これだけでも混乱しやすいですが、以下は更にいくつか留意点となります。
- Fabricで作ったDirect LakeはFabric容量が必要になる
こちらはPower BI ProやPower BI PPUのライセンスだけでは、Direct Lakeのデータセットに接続することはできないことを意味します。Power BIワークロードだけを使用する場合は気にする必要はありませんが、Power BIはFabricのコアコンポーネントの1つであるため、多くの人がFabricとPower BIをセットで考えるのが普通になってくると思います。 - Direct Lakeによるフォールバック（Fall back*1）の確認
最も分かりにくく、かつインパクトが大きい部分がこちらになるかもしれません。前回紹介した通り、Direct Lakeは使い方によっては非常に魅力的な機能となる可能性を秘めています。しかし、特定の条件下*2ではDirect LakeはDirectQueryモードにフォールバックしてしまい、クエリパフォーマンスが急激に低下してしまう可能性があります。
2番について、以下に簡単なデモを行います。
- Demo_Fabricワークスペース > LH_Contoso（SQL エンドポイント）
- 以下のステップでビューを作ります
- 上記⑤でビューが作られたことを確認し、モデルビューからFactStoreSalesByDayビューのDate列、StoreKey列とDimCalendar[Date]、DimStore[StoreKey]の間にリレーションシップを作ります
なお、ここで非常に分かりにくいのですが、追加されたFactStoreSalesByDayビューはモデルビュー上はデータモデルの一部ですが、実際にはデルタテーブルではなく、ビュー扱いになってしまうため、2023年7月時点では「新しい Power BIデータセット」から追加することはできません
このビューを含むデータセット（Direct Lakeモード）をライブ接続で可能にするためには、データセット(既定)を使用する必要があります。なお、既にDirect Lakeとしてライブ接続を行っているDS_Contoso_02でもこのビューを追加することはできません。 - 新しいPower BI Desktopを立ち上げ、下記どちらかをクリック（今回は右側を選択）
- レイクハウス (プレビュー)をクリックし、「データセット(既定)」のデータを格納する「LH_Contoso」を選択し、「接続」をクリック
- 以下のように、FactStoreSalesByDayビューを含む「データセット(既定)」で残した全てのテーブルが出現
当然、このままでは不要なテーブルが多くなりますので、SQLエンドポイントで以下のように「既定のデータセットから削除」を使って、不要なテーブルをモデルから消していきます。
その後、もう一度Power BI Desktopへ戻り、「更新」ボタンをクリックすると、対象となるテーブルが消えていることを確認できます。
- モデルビューを見ると以下の通り、モデリングが完了していることを確認
これで準備が整いましたので、最後の確認に入ります。以下2つの簡単なマトリックスを作ります。
Bでは小数点まで表示されていますが、どちらの結果も同じです。なお、Bはビューで作ったテーブルをベースに計算した結果となります（今回、Bでは明示的なメジャーを作成していませんが、パフォーマンスに差はありません）。
パフォーマンス測定
最後の仕上げとして、AとBのパフォーマンス測定を行ってみます。Direct Lakeはまだ発展途上であり、パフォーマンス測定を行うのは時期尚早ではありますが、今回はDirect LakeがDirectQueryにフォールバックすることを確認するためにこれを行います。
通常、パフォーマンス測定にはDAX Studioを使用しますが、残念ながらライブ接続ではPower BI DesktopからDAX Studioを使用することはできません。ライブ接続の状態でDAX Studioを立ち上げようとすると、以下のようにエラーが発生します。
理由は、Power BI Desktopにデータが存在しないためです。通常、このような場合ではPower BI Service側に対してXLMAエンドポイント経由でパフォーマンス測定を行います。しかし、2023年7月時点ではまだXLMAエンドポイントをサポートしておらず、Direct LakeモードでDAX Studioを使ってパフォーマンスの測定をすることができないため、注意が必要です。
そこでPower BI Desktopのパフォーマンスアナライザーだけを使って、パフォーマンス測定を測定してみます。
- 最適化タブ > パフォーマンスアナライザー
- 記録の開始 > ビジュアルを更新します
面白い結果が出ました。同じモデルなのに、以下のような顕著な違いが見られました。
- BよりAのほうが圧倒的にパフォーマンスが良い
- Bのほうは「直接クエリ」=DirectQueryクエリが出現
- 2回目以降の測定でもパフォーマンスに大きな差が生じている
実は、この結果は既に共有したドキュメントに記載されているものですが、
同じモデルでもDirect Lakeの制限事項に抵触した場合（今回はビューの使用）、パフォーマンスが異なってしまう。その原因はDirect LakeがDirectQueryにフォールバックしたことに起因
している、というものです。
さらに、Power BI Desktopを使用した場合、
ライブ接続したデータセットがインポートモードなのか、Direct Lakeモードなのかを判別することができない
ため、ユーザーが誤ってインポートモードだと思い込んでいた場合、ある日を境にパフォーマンスが著しく低下するなどのシナリオも考えられます。そのような場合、ユーザーはPower BIサポートへ問い合わせを行うこともあると思いますが、まずは今回紹介したコンテンツに該当するかどうかを思い出してもらえたらと思います。
今後、より多くの人が同じ考えを持つことになる可能性はありますが、Power BI Desktopにおいてデータセットの接続モードを明示的に表示できる機能が求められるかもしれません。本件は同じFabric CAT*3チームのメンバーにフォローアップをお願いしており、ドキュメントも含めて更新されることに期待しています。
おまけ
FactStoreSalesByDayテーブルがビューであったため、Direct LakeがDirectQueryにフォールバックしてしまいましたが、このテーブルがデルタテーブルでモデルビューから選択できた場合、パフォーマンスはどのように変わるでしょうか？
NotebookでGroup化
デルタテーブルを作成する必要があるので、
デルタテーブル形式でモデリング
- SQLエンドポイント「DS_Contoso」>「モデルビュー」>リレーションシップを構築（下図）
- Power BI Desktopへ戻り、ホーム > 更新 > モデルビュー
上記の通り、ビューで作成されたテーブル以外に、デルタテーブルとして作成されたテーブル（FactStoreSalesByDay_DL）のテーブルが出現しています。 - 3つ目のテーブルを一番下に作り、パフォーマンスを測定
念の為、一旦pbixを閉じて再度開き、キャッシュがクリアされた状態でパフォーマンスアナライザーを使って計測してみます。
結果は予想通り、2番目のテーブル以外はDirect Lakeモードによるクエリパフォーマンスを実現し、2番目のテーブルだけが直接クエリ（DirectQuery）にフォールバックされた状態となったため、クエリパフォーマンスが他の2つのテーブルよりも著しく劣っていることが分かります。
