細かいところに悪魔が潜んでいる：ボックスから飛び出してPower BIのチャンピオンになろう

悪魔が潜む細かな要素：Power BIのチャンピオンになるためのヒント

Power Biは「無名のヒーロー」でいっぱいです！その中の1つであるAnalyticsパネルは、ビジュアルタイプを変更することと組み合わせることで、Power BIレポートのパフォーマンスを大幅に改善するのに役立ちました。

数週間前、私はクライアントのPower BIレポートのパフォーマンスチューニングに取り組んでいました。レポートページの表示が非常に遅い（15秒以上）です。少し背景をお伝えしますと、このレポートはSSAS Tabular 2016でホストされているタブラーモデルへのライブ接続を使用しています。

一行もDAXコードを変更せずに、レポートページのパフォーマンスを2倍以上高速化できたと言ったらどうでしょう？！

読み続けると、非常に頻繁に細部に悪魔がいることと、考え方を広げることがどれほどあなたを真のPower BIチャンピオンにするのに役立つかがわかります：）

上記のイラストを簡単に説明します。左側のスライサーからユーザーの選択を表す4本の線が表示されるLine and clustered column chartビジュアルがあります。列は総売上高です。データは年ごとと製品ごとに分解されています。各行はDAXを使用して計算されています（ところで、SSAS 2016にはSELECTEDVALUE関数はありません）。

Performance Analyzerをオンにし、DAXクエリを取得し、DAX Studioで実行しました：

• 自律生成AIとオートコンプリートの違いを愛するようになった方法
• 経験がなくてもデータアナリストになる方法
• ジョージア工科大学の研究者が「ChattyChef」という料理レシピデータセットを紹介し、料理体験を革新します

ご覧の通り、クエリの実行には13.5秒かかります（キャッシュをクリアしてから実行）。そのうちの大部分の時間は、Formula Engine内で費やされました（76%）。これは重要です、なぜならこの結果を改善されたバージョンのレポートページと比較するからです。

では、このシナリオを最適化するために経験豊富なPower BI開発者は何をするでしょうか？DAXを書き直すのでしょうか？間違いです！

DAXロジックを変更せずにできることを見てみましょう！

ご存知のように、Power BIには評価が低い機能、あるいは「無名のヒーロー」とも言える機能があります。それがAnalyticsパネルです。

私たちのほとんどは明らかに、Power BIの開発時間の大部分を他の2つのパネル（データと書式）で過ごしています。ですので、この第3のパネルについて知らないPower BI開発者がどれほど多いかに驚くかもしれません。また、知っていても、ほとんど使っていないかもしれません。

詳細には立ち入りませんが、このパネルを使用すると、Min、Max、Average、Medianライン、エラーバーなどの追加の解析要素をビジュアルに追加できます。ビジュアルの種類によっては、すべてのオプションが利用できない場合もあります！そして、これが私のユースケースで重要でした。

Analyticsパネルを開いたところ、エラーバーのみが利用可能でした：

基本的には、このアイデアは、これらの4つの行がビジュアル自体の数字に基づいて変化しない（スライサーの選択に基づいた定数の値を持つ）ために、アナリティクスパネルの定数線機能を活用することです。 Lineとクラスタ化された列のチャートビジュアルには定数線がないため、ビジュアルを複製して通常のクラスタ化列チャートに変更しましょう。

ご覧の通り、「数字」はここにありますが、ラインが欠けています。アナリティクスパネルに切り替えて、スライサーの選択に基づいたDAXメジャーに基づいて4つの定数線を作成しましょう。

最初のステップは、定数線を追加することです。次に、ラインのプロパティを展開し、値として「fX」ボタンを選択し、定数線の値を式に基づいて設定できるようにします（この場合、それはDAXメジャーによって生成された式です）。4つのラインについても同様のプロセスを繰り返します。

再度お伝えしますが、DAXコードには何も触れていませんのでご注意ください！

Y軸をオフにしたら、私の「双子」のビジュアルは次のようになります：

ほとんど同じですね？

では、このビジュアルのパフォーマンスを確認しましょう：

オリジナルのものよりも5秒以上高速です！以前のDAX Studioのスクリーンショットと注意深く比較すると、ストレージエンジンのクエリ数は前回とまったく同じであり（SEの時間もほぼ同じ）、ストレージエンジンはデータを取得するために行う作業量もまったく同じであることがわかります。

鍵となる違いは、フォーミュラエンジンの時間です。元のビジュアルでは、合計クエリ時間の75％がFEで費やされていましたが、今回は60％未満に削減されています。

なぜそうなるのか、およびフォーミュラエンジンによって生成される2つのクエリプランの主な違いは何かを見るために興味を持ちました。

2つのクエリプランの「唯一」の違いは、遅いバージョンでは2つの仮想テーブルが作成されていました。1つはビジュアル内の「列」の値を計算するためのもの（_ScopedCoreI0）、もう1つは同じビジュアルのラインの値を計算するためのものです（_ScopedCoreDM0）。最後に、これら2つのテーブルはNATURALLEFTOUTERJOIN関数を使用して結合されました。

高速バージョンでは、ラインの値を計算する2番目のテーブルはありません。さらに、ラインの値を計算するメジャーはIGNORE関数でラップされており、SUMMARIZECOLUMNS式の評価から非空行が除外されるようにタグ付けされています。

まとめ

見ていただいた通り、ビジュアルのタイプを変更し、「無名のヒーロー」であるアナリティクスパネルを使用することで、このシナリオでのパフォーマンスが大幅に改善されました。人々が「魔鬼は細部に宿る」と言うのも偶然ではありません。だからこそ、箱の外の考え方は創造的な解決策につながることがしばしばあります。

読んでいただきありがとうございます！

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!