こんにちは、Power BI サポート チームのチャンです。
Power BI でセマンティックモデル（データセット）を作成するときに、別の Power BI セマンティックモデルを DirectQuery で参照しながら、他のセマンティックモデルやインポートのデータを組み合わせて構成する複合モデルが、とても便利でよく使用されますが、一方で制限事項やパフォーマンス観点で注意すべき事項もございますので、今回の記事では詳しくご案内していきます。
重要
本記事は弊社公式ドキュメントの公開情報を元に構成しておりますが、
本記事編集時点と実際の機能に相違がある場合がございます。
最新情報につきましては、参考情報として記載しておりますドキュメントをご確認ください。
目次
- 複合モデルとは
- ソースグループと制限付きリレーションシップ
- 事例①：同じデータソースに対してインポートと DirectQueryの組み合わせ
- 事例②：2-つの-Power-BI-セマンティックモデルの間で作成するリレーションシップ
複合モデル
複合モデルと言いますと、多くの方はインポートモードのデータソースと DirectQuery モードの組み合わせてのセマンティックモデルを想像しますが、実際、2 つ以上の DirectQuery モードのデータを組み合わせる場合にも複合モデルと言います。
2 つ以上の DirectQuery ソースのデータを結合する。
- 例：Power BI セマンティックモデル A と Power BI セマンティックモデル B への接続の組み合わせ
DirectQuery ソースのデータとインポート データを結合する。
- 例：Excel データと SQL Server への Direct Query データの組み合わせ
ソースグループと制限付きリレーションシップ
複合モデルの中で、1 つ非常に重要な概念は「ソースグループ」です。1 つの「ソースグループ」とは、同じデータソースに接続しているテーブルの集合体と言います。
以下が 1 つの「ソースグループ」の例です。
- 1 つの Power BI セマンティックモデル (1 つのセマンティックモデル内に複数データソースからインポートしたテーブル含める場合でも)
- 同じデータソースからインポートしたテーブル（複数テーブルでも）
- 同じデータソースに接続した DirectQuery のテーブル（複数テーブルでも）
上記の例の中、 2 つのソースグループを組み合わせて、2 つのソースグループの間で作成するリレーションシップは、必ず「制限付きリレーションシップ」となります。
以下の画像では、インポート と DirectQuery ソースグループの間に、作成されたリレーションシップが制限付きリレーションシップを示しています。
実際 Power BI Desktop のモデルビューで確認する場合、以下の画像のように、かっこのようなマーク ( ) で表されます。
上記のような制限付きリレーションシップの間で行われる計算やビジュアルのレンダリングに関して、パフォーマンス問題が発生することが多々見られます。
下方によくある事例を 2 つご紹介します。
事例①：同じデータソースに対してインポートと DirectQuery の組み合わせ
事象
同じデータソース（例えば SQL Server）からデータを取得してレポートを作成するとき、ファクトテーブルのデータ量が多い場合、セマンティックモデルのサイズを抑えるために、以下の組み合わせで作成する事例は良く見られます。
- ディメンションテーブル：インポートモード
- ファクトテーブル： DirectQuery モード
しかしながら、上記の組み合わせで作成する場合、インポートモードのテーブルから、DirectQuery モードのテーブルへフィルターをかける場合、以下の画像で示すような、 UNION ALL が多発する非効率なクエリが発行されることがございます。
解決策
上記のクエリが発行すること自体は製品仕様であるため、解消するには、インポートモードと DirectQuery の組み合わせを使用せず、インポートモードの代わりに「デュアルモード」を使用することをおすすめします。
「デュアルモード」を使用することによって、Power BI セマンティック モデルに送信されたクエリのコンテキストに応じて、キャッシュまたは非キャッシュとして機能します。 要するに、インポートモードと DirectQuery モードの良いとろどりができます。
デュアル テーブルの機能的な制約は、実際 DirectQuery テーブルのものと同じです。しかしながら、「デュアルモード」と「DirectQuery モード」を組み合わせたモデルの場合、上述の事象のように、UNION ALL のクエリが発行されることがなく、WHERE 句に想定通りのフィルター条件が含まれるようなクエリが発行されます。
「デュアルモード」を設定するには、まず DirectQuery としてデータソースに接続して、[モデルビュー] で該当のテーブルを選択して、ストレージモードを「デュアル」に変更できます。
事例②：2 つの Power BI セマンティックモデルの間で作成するリレーションシップ
事象
Power BI セマンティックモデルに対して DirectQuery モードで接続して、他のインポートモードのデータソースとの組み合わせや、2 つ以上のセマンティックモデルを組み合わせることはとても便利な機能ではありますが、同時に制限事項もたくさんございます。
以下のシナリオでは注意いただく必要がございます。
- 2 つ以上のセマンティックモデルの間で新たに作成するリレーションシップ
- 1 つのセマンティックモデルと、インポートモードテーブルの間で作成するリレーションシップ
異なるソースグループ間でリレーションシップを作成してレポートを作成する場合、ビジュアルの表示においてメモリ超過やリソース超過といったエラーが発生する可能性がございます。
解決策
その際は、以下の考慮事項に抵触していないかご確認ください。
数値型といったテキスト型ではないキー列の場合：
2 つの異なるソース グループにまたがるリレーションシップを作成する場合、そのリレーションシップのキー列のカーディナリティ（※）は低く抑えるようにします (理想的には 50,000 以下)。
（※）カーディナリティとは、列の一意の値の数 (=DISTINCTCOUNT の数) です。
テキスト型のキー列の場合：
可能な限りテキスト型のキー列を使用することを避けてください。
どうしても、リレーションシップのキー列としてテキスト型の列を使う必要がある場合、カーディナリティ（※） (C) にテキスト型列の平均の長さ (A) を掛けて、フィルターの予想される文字列長を計算します。 A ∗ C < 250,000 のように、予想される文字列長が 250,000 未満であることを確認します。
例：AAAAA, BBBBB, CCCCC という 3 つの一意の値が含まれる列の場合、文字列の平均の長さ (A) が 5 で、カーディナリティ (C) が 3 で、5*3 = 15 となります。
（※）カーディナリティとは、列の一意の値の数 (=DISTINCTCOUNT の数) です。
行数が多いデータや計算が複雑なメジャーを使用する場合：
上述の考慮事項の条件を満たすことが難しい場合、可能な限り参照するソースとなるセマンティックモデル側で、すべての変更を実施するようにしてください。
どうしてもセマンティックモデルを分ける必要の場合、異なるセマンティックモデルで作成する代わりに、異なるデータフローでデータを加工して作成した上で、1 つのセマンティックモデルに取り込んでください。
データフローを使用する場合は、インポートモードとなりますので、本項で記載している制限事項がございません。
本ブログの関連記事
以上、本ブログが少しでも皆様のお役に立てますと幸いでございます。
アンケートご協力のお願い
Japan CSS Support Power BI Blog では、作成する記事やブログの品質向上を目的に、匿名回答でのアンケートを実施しております。
ユーザー様のご意見・ご要望を参考に今後もお役に立てるブログを目指してまいりますので、ぜひご協力いただけますと幸いでございます。
※ 所要時間は1分程度となります。
【ご協力のお願い】Microsoft Japan CSS Power BI Blog ご利用に関するアンケート
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。