テクテク日記

テクテク=テクノロジー&一歩ずつ(テクテク)

Power BIのパフォーマンスガイドライン

いろいろ忙しくて、ブログの更新が滞ってしまっていましたが、今回はPower BIに関するパフォーマンスに焦点を当てたガイドラインについてお話ししたいと思います。今回の記事は、BI開発者やPower BI Desktopを使用してレポートを作成するセルフサービスBIユーザーを対象としています。

Power BIにおけるパフォーマンスについては、さまざまな側面が考えられますが、大まかに以下の2つに分けて考えることができます。

その他にも細かい要因や側面が存在しますが、Power BIにおけるパフォーマンスを考える際には、これらの2つが最も重要かつ顕著な要因であると考えられます。

※注意
「データセット」は別名「セマンティックモデル」に変更となっています。
Datasets renamed to semantic models | Microsoft Power BI Blog | Microsoft Power BI

パフォーマンスガイドライン

Power BIを活用する多くのユーザーや企業は、BI構築の初期段階でパフォーマンスマネジメントに関するガイドラインを考慮に入れない傾向があります。その理由として、以下の要因が考えられます。

  • 最初に作成したレポートのデータ量が小さい
    初めは少量のデータを使用してレポートを作成することが一般的です。この場合、パフォーマンスの問題はあまり顕在化せず、パフォーマンスの最適化が後回しにされることがある
  • モデルが比較的簡単
    初期段階ではデータモデルが単純であることが多いため、パフォーマンスの懸念が低く、最適化の必要性を感じにくいことがある
  • 同時接続ユーザー数が限定的
    最初は少数のユーザーがシステムにアクセスすることが一般的であり、負荷が低いため、パフォーマンスの問題があまり顕在化しないことがある
  • パフォーマンスガイドラインを最初から織り込んでいない
    初期段階では、シンプルなレポートやダッシュボードを作成することが主要な焦点となり、パフォーマンスの最適化に割り当てる時間やリソースが限られており、ここまで入念に計画していない

しかし、これらの要因が当てはまる場合でも、将来的にデータ量やユーザー数が増加し、より複雑なモデルや要求が生まれる可能性があります。そのため、初期段階からパフォーマンスに関するガイドラインを考慮に入れ、将来の拡張性を考えることが重要です。パフォーマンスの最適化は、後から修正するよりも初期段階で取り組むほうが効果的であり、適切な設計とベストプラクティスの導入が必要です。

ガイドライン

① ベースラインの構築

② 時系列でモニターを行う

③ 問題を特定し、優先順位付けを行う

④ 診断と改善

⑤ 防止策を設置

⑥ ①に戻り・・・また⑤へ

というループを回していくことになりますが、ベースラインを作る部分がかなり重要となります。

パーソナルBIとエンタープライズBI

Power BIでガイドラインを作るためには、以下の2つのユースケースに気をつける必要があります。

  1. パーソナルBI(セルフサービスBI)
  2. エンタープライズBI

パーソナルBIのケースにおけるPower BIは、個人または少数のユーザーが自分たちのデータを分析し、レポートを作成するために使用されます。主な特徴は以下です。

  • ユーザー数が限られている
  • データのアクセス権限やデータソースの管理は個人または小規模なチームで行われることが多い
  • レポートの更新やメンテナンスは限られたリソースによって行われる

一方、エンタープライズBIはPower BIは組織全体で戦略的なBI機能を提供し、IT部門が中心となって管理・運用されます。特徴として以下のものが挙げられます。

  • IT部門やSME(領域専門家: Subject Matter Expert)がBIプロジェクトを主導し、多くの関係者が参加する
  • BI開発者、Power BI管理者、レポート開発者、アナリストなど、異なる役割のチームが協力してBIの構築・開発を進める
  • セキュリティ、データガバナンス、パフォーマンスの最適化など、組織全体の要件を満たすために包括的なガイドラインとプロセスが必要

規模別に分けるのは難しいですが、パーソナルBI(セルフサービスBI)は数十人程度、エンタープライズBI(チーム型BI)は数百名~という目安でしょうか。

これらのユースケースに合わせてガイドラインを作成することは非常に重要です。パーソナルBIでは、使いやすさと迅速なデータアクセスが重要であり、ユーザーサポートの側面も考慮する必要があります。一方、エンタープライズBIでは、セキュリティ、データ品質、パフォーマンス最適化、適切なガバナンスが特に重要です。各ケースに適したガイドラインを整備することで、Power BIプロジェクトの成功に貢献します。

そして当然ですが、パーソナルBIと比較して、エンタープライズBIには注意すべき点が多く存在し、上述したPMC(Performance Management Cycle)の設定が非常に重要です。なお、BIの世界ではよく管理型セルフサービスBI(マネージドBI)を目指すべきであると言われており、下図がこのコンセプトとなります。

上記の図式は、データとレポートのオーナーシップがIT部門とユーザー部門のどちらで保持されるかを示しており、最もリスクを低減し、柔軟性を維持できるハイブリッド型の「管理型セルフサービスBI」が、企業規模の大きい会社に適していると言われています。

BI規模によるパフォーマンスに対する考え方

規模の小さなBI構築が、モデリングが最適化されていない状況でもPower BIのレポート表示パフォーマンスに大きな影響を及ぼさない可能性があることは事実です。規模が小さい場合、データ量がそれほど多くないことが一般的であり(例: 数百万件のデータまで)、問題が現れるまで最適化が不要であることもあります(例: モデリングが適切でなく、非効率なDAXメジャーによってレポートの表示パフォーマンスが遅くなったなど)。

しかし、規模が小さくても、最適なアプローチを取ることは重要です。なぜなら、今後の大規模プロジェクトにおける無駄なコストを削減できるだけでなく、自身のBI開発スキルを向上させる機会にもなるためです。常に最適なモデルを追求し、最善のアプローチを模索することが大切です。

一方で、規模の大きなBIプロジェクトでは、ユーザー数が増えるにつれてレポートの表示パフォーマンスが低下する可能性が高いため、初期段階で最適なアプローチを取ることが特に重要です。例えば、1つのFactテーブルだけでデータモデルを構築したり、CALCULATE引数にFactテーブルを使ってフィルターしたり、DAX式に過度にIFを使用したりすると、後でパフォーマンス問題が発生する可能性があります。これらの問題を事前に考慮し、BIレポートの開発サイクルにパフォーマンスに関するガイドラインを組み込むことが不可欠です。

ガイドラインを設定する

異なるデータ量を持つレポートが異なるクエリパフォーマンスを示すのは当然のことです。合理的な期待値をベースラインとして設定し、これを基準にしてパフォーマンスの評価を行うことは重要です。

Power BIにおいて、同じレポートが異なるユーザーで異なるパフォーマンスを示す場合、事前にガイドラインを設定しておくことは非常に有益です。これにより、パフォーマンスの良し悪しを客観的に比較し、問題の特定や改善に向けたアクションを取る際に役立ちます。また、ベースラインを設定することで、システムの変化やアップグレードがパフォーマンスに与える影響を監視し、必要に応じて調整できるようになります。

ガイドラインの設定は、パフォーマンスのトラブルシューティングや最適化において非常に役立つ手段であり、Power BIプロジェクトの成功に寄与します。

以下はいくつか役に立つガイドラインとなります。

  • ベースラインの決定方法について、同じシナリオに基づく複数のデータポイントからの平均値を取得する方法を活用
    • 通常、ベースメジャーを使用してこれを実施しますが、特に重要な指標がある場合は、それを考慮に入れることが重要です。また、重要な指標が複雑なメジャーで構築されている場合、レポートの表示方法(結果の表示方法や粒度など)によってパフォーマンスが大きく異なることがあります。
      たとえば、マトリックステーブルで分類別に表示した場合と最も詳細な品目レベルまで計算させた結果を表示する場合とでは、パフォーマンスに大きな違いが生じる可能性があります。このような場合、許容可能な応答時間を事前に定義し、本番運用時にユーザー数やデータ量が増加し、パフォーマンスが低下した場合に、モデリングDAX、またはレポートの表示方法を変更すべきかどうかの判断を行います(下図)。
      分類まで表示

      詳細まで表示

      ご覧の通り、「詳細まで表示」させた場合の分析エンジンがスキャンする行数は多くなり、結果として掛かった時間も「分類まで表示」よりも長くなっています。この例はPower BIのレポートが遅いとSOSを出す場合の典型的な例の1つとなります。
  •  データセットと各ページに関するガイドラインを設ける
    • データセットに関しては、データの更新にかかる時間を最適化し、各ページにおいては表示の粒度を考慮します。上述で述べた通りですが、ページにおいて、データポイントが少なくシンプルな場合、パフォーマンスは速くなりますが、粒度が細かいページが存在する場合は注意が必要です。特に、同じメジャーが使用され、粒度が細かいレポートの表示パフォーマンスが遅い場合、DAXメジャーやビジュアルの数に問題がある可能性が高いと言えます
  • Power BI DesktopとPower BIサービスに発行されたレポートのパフォーマンスを比較する
    • 通常、問題が発生するのは後者であることが多いですが、よくアドバイスされている1つは、Power BIサービスのレポートが遅い場合、「まずはPower BI Desktopにおけるレポートのパフォーマンスを確認すること」になります
  • Power BIにおいて、RLS(Row-Level Security、行レベルのセキュリティ)の設定の有無

    • RLSはデータのアクセスを制御するために使用され、データセットに異なるセキュリティ規則が適用されている場合、パフォーマンスの違いが生じる可能性があります。RLSが適用されている場合、異なるベースラインを設定することが検討されるべきです。なぜなら、RLSによって異なるユーザーグループに異なるデータが表示され、それによってクエリやデータモデルのパフォーマンスに変動が生じるためです

  • Power BIサービスにあるレポートの場合、異なる時間帯や地域別(ネットワーク環境)別にベースラインを設定する
    • 特に混雑する時間帯にレポートの表示が遅い場合、以下の施策が必要かもしれません
      • 容量SKUの増加
      • レポートの最適化
      • キャッシングの活用
      • スケジュールとモニタリング
      • レポートの分割
  • 変更前と変更後のレコードをキープしておくこと
    • これを行っておくことで、大規模な変更がモデルやレポートに加えられた場合、時系列ベースで変更の影響を評価し、Before vs Afterの比較が可能になります

最後に

上記のアプローチは、レポートに限らず、他のアイテム(たとえば、データセットの更新など)にも適用できますが、ベストなコンディションを作り出すためには、週ごとのパフォーマンスレビューを実施することをお勧めします。