Power BIを使用する際の”ベストプラクティスを教えて欲しい”というリクエストは非常に多く聞かれます。ベストプラクティスはその人の経験、知識量によって対象となるコンテンツが異なってきますが、今回のPower BIを利用し始めたばかりの人でも即効性の高いものをご紹介したいと思います。
下記Power BIレポートはその全てを詰め込んだものですが、必要に応じてブックマークしておくと良いでしょう。
https://aka.ms/pbibest（別ウィンドウが立ち上がる）
※表示されない場合は、ブラウザを一度更新してみてください
ここで注目すべき重要な点は以下のとおりです。
- Power BIに関するすべてのベストプラクティスを網羅したものではない
- Power BIは非常に広範であり、今回紹介した内容は、主にモデリングおよびレポートの作成に焦点を当てたもので、主にユーザーやBIアナリスト向けの情報
- より包括的に知識を得るためには、Power BIのガイダンスを追加参照することを推奨
実は、上記のレポートだけをご覧いただくだけで、今回の記事は終了となりますが、いくつか追加で説明するとより良い理解が得られるポイントがありますので、それらについても今回の記事でお伝えしたいと考えています。
データソース
データソースは速いものを選べる場合はそれを選ぶべきというのがポイントとなります。通常、Power BIでレポートを作成するには以下のプロセスを辿りますが、初めの段階でBIツールにとってパフォーマンスの高いデータソースを選択できれば、後続の作業は一気に効率的に進むことが期待できます。
レポート内で「Data Source」タブをクリックすると、各データソースからセマンティックモデルへの読み込み速度の結果が表示されます。行数はどのデータソースも同じで、全部で12.6百万行です。ただし、列数は必要な列だけを含む場合が13列、または全ての列を含む場合が27列となります。
ある程度結果は予想できていたのですが、やはり（オンプレミス）SQLデータベースが最も早く、1秒当たりの読み込みパフォーマンスは24万行でした。これは、同じデータ量であるExcelの4.6倍、Excelの読み込み補正で調整した場合の5.8倍も速い結果となっています。CSVはExcelよりも読込パフォーマンスが良いのですが、SQLデータソースと比べるとやはり遅いようです。
ソースデータ分析
BIで分析を解すする前にまずはソースデータを吟味する必要があります。
- どのようなデータソースがあるか
- 対象データのボリューム（テーブル数、行数・列数等）はどれくらいか
- どのような属性（列）が入っているのか
- 行と列の両方において、必要な部分はどこか
- BIとして活用する場合、それらはDimension（フィルターする側）なのか、それともFact（フィルターされる側 = 主に集計される側）なのか
- データの粒度（Granularity）とデータの 濃度（Cardinality）はどれ程か
- データの粒度: 最も細かいPOSデータまでの情報 or 会計データのようなある程度集計された粒度なのか
- データの濃度: 最も重複が少ない列（例: POS列、顧客ID列）はどれか。そのユニークなレコード数はどれくらいか（例: 10万 vs 1,000万では後者をモデリングするのが非常に大変）
Power BIでモデルを最適化する際の基本ルールとして、以下を心に留めておくと、様々な問題をシンプルに解決できることがよくあります。
- BIで使用されていない不要な行や列を入れない（必要なものだけを選択してセマンティックモデルに読み込む）
- 必要でない限り、データの濃度が高い列を極力読み込まない
- 数値列のような読み込む必要がある列では、整数型に変更できないかを考慮
これらの手順を実施するだけでも、セマンティックモデルのサイズが大幅に縮小される可能性が高まります。セマンティックモデルのデータはメモリに配置されますが、データサイズが小さいことはDAXエンジンがスキャンするデータ量が減ることを意味し、結果的にレポートの表示時間が効率的に短縮されることに繋がります。
Power BI Desktopの設定
これらは非常に基本的な設定ですが、これらを行っておくとPower BIの活用がより容易になります。設定については下記記事もご参考ください。
スタースキーマの構築
Power BIでレポートを作成する場合、必ず耳にするのが「スタースキーマ」となります。なぜこれが重要であるかはレポート内の🔗を参考して頂くとして、
Power BIのセマンティックモデルはスタースキーマを目指しましょう
と覚えておくと間違いありません。
中にはどうしてもスタースキーマにできないケースもありますが、そのようなケースはアドバンスなトピックとなってきますので、今回のベストプラクティスではカバーされていません。
日付テーブルを必ず作る
スタースキーマから派生してこちらも最重要ポイントの一つですが、
- 日付テーブルを作ることで様々な日付タイプに対する分析が可能になる
例えば、受注日、発送日、遅延日ベースで異なる指標を構築することができたりします。 - 日付テーブルを作ることで、日付・時間の分析が可能になる（レポート内の説明をご参照）
- 日次ベースの日付テーブル、月次ベースの日付テーブルの両方を作ることができ、用途に応じて活用可能（レポート内の説明をご参照）
- 日付テーブルを使用すると、DAX関数を用いてより高度な時系列分析が可能
このように、日付テーブルはPower BIを上手く活用する上で非常に大事なものとなっています。
DAXメジャー
「DAXが難しい」という意見はPower BIを学ぶ上での主要な障害の1つです。製品チームもこれをしっかり認識しており、テクテク日記でも特に重要なテーマであると考えています。しかし、一旦DAXをマスターすると、その強力な機能を利用して複雑な指標を構築したり、Excelでは難しいとされるメジャーを作成することができます（※最近のExcelは高機能化しており、DAXと同様のことができる可能性もありますが・・）。
DAXは構文を理解する必要があり、また様々な書き方があるため、これがレポートの表示パフォーマンスに影響を与えることがあります。上記のレポートでは一部ですが、留意すべきポイントを記載しています。これらをぜひ全て覚えていただくと良いでしょう。
ネーミングルール
「DAXメジャーの参照 vs テーブルの列参照」の違いを理解し、なぜその違いが生じるのかを把握することは非常に重要です。このルールを理解せずにPower BIを使用している方が多く見受けられますので、改めて確認されることをお勧めしたい。
その他
「その他」が実は重要という可能性もありますが、「レポートデザイン」が簡単に始められるお勧めの1つでしょうか。
