逆引きで学ぶPower BI

Power BIを構築していくにあたり、大事なポイントは複数あります。
Power BI Desktopなどを使用してレポートを作成し始めるところから、チームに実装し、それを組織に広げていく。さらに開発者を増やし、分析者を育成する。

Microsoft Learnの中から大事だなと思ったポイントを抜き出してみました。
「おっ、これは😯」と思う一文があれば、ドキュメントに飛び、全文を読んでみてください。

本記事は「Microsoft Power BI Advent Calendar 2023」、1日目の記事です。
https://qiita.com/advent-calendar/2023/powerbi

いいね！ 👍 よろしくお願いします！

市民開発者とプロの開発者が協力し、~中略~ 目的のソリューションを構築することができます。

最初はPower BIを含むPower PlatformのLearnから。
市民開発者だけではなく、プロ開発者も巻き込めると目的達成が早くなりそうですね。

Power Platform を利用することで、組織はこれらすべての課題に簡単に対処できるようになります。 このソリューションにより、ローコード ツールに加えて、エンタープライズ レベルのアプリケーション開発ツールを使用し、共同で作業することができます。 市民開発者とプロの開発者が協力し、これらのアプリケーションを日々使用するユーザーのニーズを考慮して、目的のソリューションを構築することができます。

現場の技術者は、職務の遂行に機械部品が必要となるシナリオに直面することがあります。 その部品の在庫があり、作業を続けられるように部品を簡単にリクエストできる状況が理想的です。 しかし、多くの場合このプロセスにはボトルネックがあります。 最初に技術者からリクエストを送信する必要があります。 そして、在庫責任者からの返事を待ちますが、結局部品の在庫がないと判明する場合もあります。

データ視覚化ソリューションを作成する典型的なワークフローは、 Power BI Desktop が出発点となります。

なにはともあれ、Power BI Desktopに詳しくならないと、Power BIは始まりませんね！

データ モデルとレポートを作成したら、レポートをパブリッシュしたり、ビジネス ユーザーが対話することができる Power BI サービスというクラウド サービスにそれらをパブリッシュします。 Web ブラウザーを使用して、このサービスでデータの基本的なモデリングとレポート編集を直接行うこともできますが、これの機能は Power BI Desktop ツールと比較して制限があります。 このサービスを使用して、レポートがあるデータ ソースの更新をスケジュールしたり、レポートを他のユーザーと共有することができます。 関連するレポートを 1 つの使いやすい場所にまとめるダッシュボードとアプリを定義することもできます。

可能な限り多くの処理をデータ ソースに委任する

Power Query クエリがリレーショナル ソースからデータを取得すると、一部のソースでネイティブ SQL クエリを使用することができます。

Power BIにはデータソースが必要です。SQLデータベースなどのRDBの多くが処理の委任に対応しています。

よくある間違いは、テーブルの既定のビューをフィルター処理しないことです。

つまり、1 億を超えるすべての行が表示されます。 これらの行のデータはメモリに読み込まれ、更新のたびに圧縮解除されます。 この処理により、メモリの需要が大量に発生します。 解決策: "上位 N" のフィルターを使用して、テーブルに表示される項目の最大数を減らします。 項目の最大数は、ユーザーが必要とする数より大きくする (10,000 など) ことができます。 その結果、エンドユーザー エクスペリエンスが変わることはありませんが、メモリ使用量が大幅に低下します。 そして、最も重要なこととして、パフォーマンスが向上します。

10 GB のソース データが約 1 GB のサイズに圧縮されることを期待できます

データをインポートすると、データサイズが1/10程度まで圧縮されます。逆に、圧縮率がそこまでいかない場合は、データの持ち方に課題がある可能性があります。

インポート モデルは、VertiPaq ストレージ エンジンによって圧縮および最適化されてからディスクに格納されるデータと共に読み込まれます。 ソース データがメモリに読み込まれると、10 倍の圧縮が見られる可能性があるため、10 GB のソース データが約 1 GB のサイズに圧縮されることを期待できます。 さらに、ディスクに永続化すると、さらに 20% を削減できます。

概念的には、モデルは多次元構造を形成します

分析モデルを使用すると、分析をサポートするためにデータを構造化できます。 モデルは、関連するデータ テーブルに基づいており、分析またはレポートの対象である数値 ("メジャー" と呼ばれる) と、それらを集計するエンティティ ("ディメンション" と呼ばれる) を定義します。

スター スキーマは、リレーショナル データ ウェアハウスで広く採用されている成熟したモデリング手法です。

Power BIのメジャーはモデルがスタースキーマになっている前提で設計されています。

スター スキーマは、リレーショナル データ ウェアハウスで広く採用されている成熟したモデリング手法です。 モデラーは、モデル テーブルを "ディメンション" または "ファクト" として分類する必要があります。

一般に、単一のモデル テーブルの利点は、複数のモデル テーブルの利点を上回ります。

非正規化も視野に入れましょう。

スノーフレーク ディメンションは、単一のビジネス エンティティの正規化されたテーブルのセットです。 たとえば、Adventure Works では、商品がカテゴリとサブカテゴリ別に分類されます。 製品がサブカテゴリに割り当てられ、その後、サブカテゴリがカテゴリに割り当てられます。

Power BI Desktop では、スノーフレーク ディメンションの設計を模倣したり (おそらく、ソース データで行われているため)、ソース テーブルを単一のモデル テーブルに統合 (非正規化) したりするように選択できます。 一般に、単一のモデル テーブルの利点は、複数のモデル テーブルの利点を上回ります。 最適な決定は、データの量とモデルの使いやすさの要件によって異なる場合があります。

データ分析式 (DAX) のタイム インテリジェンス関数 を使用するには、前提条件となるモデル要件があります。

日付テーブル、作成していますか？

モデルには少なくとも 1 つの "日付テーブル" が必要です。 日付テーブルとは、次の要件を満たすテーブルです。

[自動の日付/時刻] オプションは、カレンダー期間を操作する場合と、時間に関して単純なモデル要件がある場合にのみ有効にすることをお勧めします。

既定でONだけど‥

[自動の日付/時刻] オプションは、カレンダー期間を操作する場合と、時間に関して単純なモデル要件がある場合にのみ有効にすることをお勧めします。

逆ディメンジョン

ファクトテーブルの列をフィルターに使用することは非推奨です。

ファクトの種類のテーブルの列をフィルター処理またはグループ化に使用する場合は、それらを個別のテーブルとして使用できるようにすることを検討できます。 こうすることで、フィルター処理またはグループ化に使用する列を、ファクト行の要約に使用する列から分離させることができます。 この分離により次のことが可能になります。

多対多ディメンションの種類のテーブルを直接関連付けることはお勧めしません。

多対多ファクト 誤解のないように言うと、この設計手法は一般的にはお勧めできません。

多対多のリレーションシップは非推奨です。

一般に、双方向のリレーションシップの使用は最小限に抑えることをお勧めします

双方向のリレーションシップどういう動作をするのか慎重に検証をする必要があります。

一般に、双方向のリレーションシップの使用は最小限に抑えることをお勧めします。 これらはモデルのクエリ パフォーマンスに悪影響を及ぼす場合があり、またレポート ユーザーに混乱をもたらす可能性があります。

BLANK を値に変換しない

ここからはDAXの推奨項目。

このような場合、代わりにゼロのような値を返したいと考えるかもしれません。 この設計が効率的かつ実用的であるかどうかを慎重に判断することをお勧めします。

フィルター引数として FILTER を使用しない

CALCULATE関数の使い方でよくでてくる問題ですね。

最良のパフォーマンスを得るには、可能な限り、ブール式をフィルター引数として使用することをお勧めします。

そのため、FILTER 関数は必要な場合にのみ使用してください。 それは複雑な列の比較のフィルター処理を行う場合に使用できます。

VALUES の代わりに SELECTEDVALUE を使用する

SELECTEDVALUE関数が使えるようになるまではVALUES関数などを組み合わせて実現していました。

SELECTEDVALUE 関数を使用することをお勧めします。 これにより、この記事で説明されているパターンと同じ結果を、より効率的かつ円滑に得ることができます。

COUNT の代わりに COUNTROWS を使用する

テーブルの行をカウントする必要がある場合は、常に COUNTROWS 関数を使用することをお勧めします。

Power BI Desktop のモデルからレポートを分離する

レポートとモデルの分離というのは常に考えないといけない問題です。

次の場合には、モデルとレポートの開発を別々の Power BI Desktop ファイルに分割する方が理にかなっています。

• データ モデルの作成者とレポートの作成者が異なる
• 現在、または将来、モデルが複数のレポートのソースになることがわかっている

Power BI は数兆行のデータをシームレスに処理できると聞いたことがあるかもしれませんが、~中略~ 実現できていないのではないでしょうか。

数億行で動作が重くなっているのは、何かに原因がありそうです。
すべてをPower BIで行おうとすると破綻します。

Power BI でのリアルタイム ソリューションとは、1 秒から 15 分の待ち時間で最新の結果を生成するものです。 待ち時間が 15 分を超える場合、Power BI は従来のデータ更新手法を使って管理できます。 待ち時間の遅延が 1 秒以下でなければならない場合、Power BI は適していません。

Power BI は数兆行のデータをシームレスに処理できると聞いたことがあるかもしれませんが、独自の Power BI テナントではそれを実現できていないのではないでしょうか。

BI 戦略の策定は、BI のイニシアチブとソリューションから最も大きなビジネス価値を得るために不可欠です。

ここからはビジネス実装の話が続きます。
Power BI Desktopを開く前にやることがたくさんあります。

初めて Microsoft Fabric または Power BI に移行する、あるいはこれらを実装する: 明確な BI 戦略を持つことは、新しいプラットフォームまたはツールの実装を成功させるために不可欠です。

• Microsoft Fabric または Power BI の使用が大幅に増加している: BI 戦略は有機的な導入に明確さと構造をもたらし、リスクを軽減しながらユーザーを有効化するのに役立ちます
• データドリブンな組織になる、またはデジタル変革を実現することを目指している: BI 戦略は、組織を最新化し、競争上の優位性を得るために不可欠です
• ビジネスまたは技術上の大きな変化が起こっている: BI 戦略を計画することで、組織が変化を障害としてではなく、推進力として使用できるようになります
• ビジネス戦略を再評価している: ビジネス戦略は BI 戦略に影響を与えるものでなければなりません。同じように、BI 戦略がビジネス戦略の変更につながる可能性があります。 組織のゴールを達成するには、すべての戦略の足並みを揃える必要があります

エグゼクティブ スポンサーを特定して関与させる

経営陣からのサポートがあるとないでは大きく変わりますよね。

ビジネス データのニーズ、BI のゴール、優先事項に対処する目標を明らかにする必要がある

このBIを作るのは何のためか？

達成したい内容の高レベルの説明としてゴールを定義します。 一方、目標は、ゴールを達成するのに役立つ具体的で実用的な目標です。 ゴールは目的の将来の状態を表しますが、目標はそこに到達するためのパスを表します。

要件を収集し、ソリューション設計を定義

Power BIも立派なシステムです。作る人はエンジニアです。

BI 戦略は、データと分析を実装、使用、管理するための計画です。 BI 戦略を定義するには、まず BI の戦略的計画から始めます。 戦略的計画は、BI の目標と優先順位を特定するのに役立ちます。

"センター オブ エクセレンス (COE) " が必要である

社内に組織をつくることも重要です。

拡張シナリオを成功させるには、部門は "一定額を支払う" 必要があります

お金もかかるよねってことです。

データ カルチャ

あなたの組織にデータカルチャはありますか？

データ カルチャの構築は、分析の導入に密接に関連し、多くの場合、組織のデジタル変革の重要な側面となります。 "データ カルチャ" という用語は、組織によって異なる方法で定義できます。

チャンピオンネットワーク

BI構築に積極的に関与してくれている人を特定しましょう。

"実践共同体" は、互いに自主的にやり取りして助け合う、共通の関心を持つ人々のグループです。 Microsoft Fabric などのツールを使用して効果的な分析を生成することは、組織全体にわたって人々をまとめることができる、共通の関心です。

ビジネス アラインメントは継続的なプロセスです。

ビジネス目的は絶えず進化するため、ソリューションとイニシアチブは時間の経過と共に変化することを理解する必要があります。 データおよび BI のプロジェクトの要件が厳格であり、変更できないと想定しないでください。 要件の変更に苦労している場合は、要件収集プロセスに効果がない、あるいは柔軟性がないことを示している可能性があります。また、開発ワークフローに定期的なフィードバックが十分に組み込まれていないことも考えられます。

ユーザーに問題が発生している場合に、解決するためにどのようなオプションがあるか把握していますか?

変更に対する抵抗に対処することは重要です

新しいものを導入しようとしたときに抵抗は必然です。

変更に対する抵抗に対処することは重要です。なぜなら、導入と生産性に多大な悪影響を及ぼす可能性があるからです。 変更に対する抵抗に対処する場合は、次のアクションとアクティビティを検討します。

終わり

Power BIのLearnには参考になる記事がたくさーん掲載されています。定期的に目を通して、アップデートしていきましょう！