Power BI の複合モデル: インポートと DirectQuery の混合

長年にわたり、Power BI の実践者は、インポート モード (高速ですが、データは最後の更新時と同じくらい新鮮です) か、DirectQuery (常に最新ですが、潜在的に遅く、クエリが制限されています) を選択する必要がありました。複合モデルは、両方のストレージ モードを 1 つのモデル内で共存できるようにすることで、この計算を変更しました。モードの境界を越えた関係が可能になりました。

この機能により、以前は不可能だったシナリオが可能になります。ダッシュボードには、インポート パーティションからの昨日の完全なトランザクション履歴と、DirectQuery ソースからの今日のリアルタイム データが表示され、すべてオンデマンドでクエリされるライブ Salesforce 商談テーブルに結合されます。複合モデルがどのように機能するか、そして複合モデルが解決するよりも多くの問題を引き起こす場合は、高度な Power BI 実践者にとって必須の知識です。

重要なポイント

• 複合モデルは、単一のセマンティック モデル内でインポート、DirectQuery、およびデュアル ストレージ モードを混合します。
• インポート モードは、履歴データに対して VertiPaq 圧縮とインメモリ クエリ パフォーマンスを提供します
• DirectQuery モードはリアルタイムでソースをクエリします - 鮮度は優れていますが、パフォーマンスはソースに依存します
• デュアル モード テーブルは、クエリ コンテキストに応じてインポートまたは DirectQuery として機能します。
• ストレージ モードの境界を越える関係によりクエリが複雑になり、パフォーマンスの問題が発生する可能性があります
• 複合モデルの集計テーブルにより、DirectQuery クエリのパフォーマンスが大幅に向上します
• Power BI データセットの DirectQuery (チェーン) により、共有セマンティック モデル上に複合モデルを構築できるようになります
• インポート テーブルと DirectQuery テーブルの間の制限された関係により、特定の DAX 関数が制限される

---

ストレージ モード: インポート、DirectQuery、およびデュアル

複合モデルを理解する前に、各ストレージ モードを個別に理解する必要があります。

インポート モード は、ソース システムから Power BI のメモリ内 VertiPaq ストレージ エンジンにデータを読み込みます。データは圧縮 (多くの場合 10:1 以上) され、分析クエリを非常に高速に実行する列形式データとして保存されます (最大数億行のデータセットに対するほとんどのクエリで通常はミリ秒)。制限事項: データは、最後にスケジュールされた更新または手動で更新されたときと同じくらい新鮮になります。

DirectQuery モード は、ユーザーがレポートを操作するたびに、ソース システムにリアルタイムでクエリを実行します。 Power BI エンジンは、DAX クエリをネイティブ ソース クエリ (リレーショナル データベースの SQL など) に変換し、ソースに対して実行します。データは常に最新ですが、パフォーマンスはソース システムのクエリ パフォーマンスに完全に依存します。インデックスが適切に作成された専用の分析データベースは、DirectQuery クエリを適切に処理します。トランザクション負荷が高い OLTP 運用データベースでは、遅くて一貫性のない結果が生成される可能性があります。

デュアル モードは、複合モデルで利用できる特別なハイブリッドです。デュアルモード テーブルはインポート (VertiPaq にロードされたデータ) として物理的に保存されますが、クエリ コンテキストで必要な場合は DirectQuery 経由でクエリを実行することもできます。これは主に、インポート ファクト テーブルと DirectQuery ファクト テーブルの両方との関係に参加する必要がある共有ディメンション テーブルに使用されます。

---

複合モデルを使用する場合

複合モデルは特定のシナリオに適しています。より単純なアーキテクチャが要件を満たしている場合には、正当化できない複雑さが追加されます。

次の場合に複合モデルを使用します。

次の場合は複合モデルを使用しないでください

• 完全なインポート モデルは十分に高速に更新され、データ遅延は許容範囲内です (ほとんどの場合)。
• DirectQuery ソースがクエリの負荷を処理できない (運用 OLTP データベース)
• 複雑な DAX 計算が必要です - 複合モデルは特定の DAX 関数を制限します
• 行レベルのセキュリティはストレージ モードの境界を越える必要がある (複雑な実装)

---

ストレージモードの構成

Power BI Desktop では、ストレージ モードはテーブルごとに設定されます。 「モデル」ビューでテーブルを右クリック→「プロパティ」→「詳細」→「ストレージモード」の順にクリックします。

DirectQuery に大きなファクト テーブルがあり、インポートにディメンションがある一般的な複合モデルの場合:

1. FactSales を設定 → ストレージ モード: DirectQuery
2. DimDate を設定 → ストレージ モード: デュアル (インポート クエリと DirectQuery クエリの両方を処理)
3. DimProduct を設定 → ストレージ モード: インポート (小さなテーブル、完全にキャッシュ)
4. DimCustomer を設定 → ストレージ モード: デュアル (クロスソース関係で使用)
5. RealtimeSales (今日のデータ) を設定 → ストレージ モード: DirectQuery

テーブルを DirectQuery として構成するか、ストレージ モードを変更すると、Power BI は関係と潜在的な制限に関する警告を表示します。これらを注意深く確認してください。これらは、モデルの動作が純粋なインポート モデルと異なる可能性がある部分を示しています。

---

複合モデルの関係

異なるストレージ モードのテーブル間の関係は、同じモードの関係とは異なる動作をします。これらの違いを理解することは、正しい結果を生成するモデルを構築するために重要です。

通常のリレーションシップ は 2 つのテーブルを接続し、「多」側が「1」側を使用してフィルタリングできるようにします。インポート モデルでは、両方のテーブルがメモリ内にあり、リレーションシップはメモリ内で高速に実行されます。 1 つのインポート テーブルと 1 つの DirectQuery テーブルを持つ複合モデルでは、この関係により 1 つのテーブルのテーブル スキャンが発生し、それがもう 1 つのテーブルのフィルター処理に使用され、大規模なクロスモード クエリが生成される可能性があります。

制限されたリレーションシップは、DirectQuery テーブルがインポート テーブルと多対多のリレーションシップを持つ場合、または他の特定のクロスモード シナリオで自動的に作成されます。制限されたリレーションシップは双方向フィルターをサポートせず、特定の DAX 関数 (たとえば、リレーションシップ フィルター パスに依存する関数) を制限します。 Power BI では、モデル ビュー内の限定された関係が実線ではなく点線でレポートされます。

クロスソース リレーションシップ は、まったく異なるデータ ソースのテーブルを接続します (例: DirectQuery 経由で接続された SQL Server のテーブルと、別の DirectQuery 接続経由で接続された Salesforce のテーブル)。これらのリレーションシップでは、一方の側がデュアルモード テーブルである必要があります。Power BI は、リレーションシップの一方の側をメモリ内で実体化し、もう一方の側に結合できる必要があります。

これらの関係タイプの実際的な影響: 純粋なインポート モデルで正しく機能する DAX メジャーは、複合モデルで予期しない結果またはエラーを引き起こす可能性があります。ストレージ モードを変更した後は、すべての測定値、特に USERELATIONSHIP、CROSSFILTER、リレーションシップ関連のフィルター関数を使用した CALCULATE、および関連テーブルの集計を含む測定値を慎重にテストしてください。

---

集計テーブル: コア複合モデル パターン

最も価値のある複合モデル パターンは、大規模な DirectQuery ファクト テーブルと、より高い粒度でデータを事前に要約するインポート モードの集計テーブルを組み合わせます。

問題: DirectQuery の 5 億行の売上ファクト テーブルは、ほとんどのソース システムにとって対話的にクエリするには大きすぎます。ソースは負荷の高い集計クエリを実行するため、すべてのグラフに 10 秒以上かかります。

解決策: ファクトを日次/月次/製品カテゴリ単位に集計する概要テーブルを事前に作成し、その概要テーブルを Power BI にインポートします。ほとんどのクエリ (月次、四半期、またはカテゴリ レベル) は高速インポート集計にヒットします。個々のトランザクション レベルにドリルダウンするクエリのみが DirectQuery に戻ります。

集計のセットアップ:

まず、データ ウェアハウスに集計テーブルを作成します。

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

このテーブルを Power BI にインポートし、ストレージ モードを インポート に設定します。

次に、Power BI で集計を構成します。

• SalesByDayProduct を右クリック → 集計の管理
• 各列を詳細テーブルとの関係および集計関数 (合計、平均、カウントなど) にマッピングします。
• 「集計」列を設定します (SalesAmount → Sum は FactSales[SalesAmount] → Sum にマップされます)

Power BI のクエリ エンジンは、可能な場合には自動的にクエリを集計テーブルにルーティングし、集計では提供されない行レベルの詳細がクエリに必要な場合にのみ、DirectQuery 詳細テーブルにフォールバックするようになりました。

パフォーマンスの結果は劇的です。以前は 15 秒かかっていたカテゴリレベルおよび時間レベルの集計が 1 秒未満で返されるようになり、個々のトランザクションにドリルダウンするオプションも引き続き利用可能です。

---

Power BI データセットの DirectQuery

Power BI では、Power BI データセット (「複合モデルとのライブ接続」または単に「共有データセット上の複合モデル」とも呼ばれます) 用の DirectQuery が導入されました。これにより、開発者は、新しいテーブル、計算メジャー、ローカル インポート データを追加しながら、既存の公開された Power BI データセットを DirectQuery ソースとして使用する新しいレポートまたはデータセットを作成できます。

主要な使用例: 組織には、中核となる財務データと販売データをカバーする認定されたエンタープライズ セマンティック モデルがあります。特定の分析に取り組んでいるチームは、認定されたエンタープライズ モデルを変更せずに、ローカル データ (プロジェクト コードを含む CSV ファイル、ターゲットを含む Excel ファイル) を追加する必要があります。 Power BI データセットの DirectQuery を使用して、DirectQuery 経由でエンタープライズ モデルを参照する複合モデルを作成し、ローカル テーブルをインポート データとして追加します。

これにより、次のような管理された分析アーキテクチャが可能になります。

• 中央データ チームが認定されたエンタープライズ データセットを維持します
• ビジネス チームは、一貫性のない個別のモデルを作成することなく、ローカル コンテキストを使用してこれらのデータセットを拡張します。
• エンタープライズ モデルは、共有指標の信頼できる唯一の情報源であり続けます

制限事項: Power BI データセットの DirectQuery は、通常の DirectQuery のすべての制限事項を継承しています。一部の DAX 関数は制限されており、複合モデルを介して伝播するには行レベルのセキュリティを適切に構成する必要があり、ソース データセットへの接続によりクエリ処理のレイヤーが追加されます。

---

複合モデルのパフォーマンスの最適化

コンポジットモデルは、純粋な輸入モデルよりも慎重なパフォーマンスチューニングが必要です。次の最適化は最も効果的です。

クロスモード クエリの削減: ストレージ モードの境界を越えるすべてのリレーションシップ トラバーサルにより、待ち時間が追加されます。ディメンション テーブルをデュアル モード (クロスモード トラバーサルなしでインポート クエリと DirectQuery クエリの両方に対応できる) として維持し、ほとんどのクエリが単一モード内に留まるようにモデルを構造化することで、これらを最小限に抑えます。

ソースでの事前集計: Power BI でより効率的に実行できる集計を DirectQuery ソースに要求しないでください。レポートが実際に必要とする粒度で事前に集計するビューまたはマテリアライズド ビューをソース データベースに構築します。

パフォーマンス アナライザーを使用してクエリ プランを監視する: Power BI Desktop で、[表示] → [パフォーマンス アナライザー] を選択すると、各ビジュアルの DAX クエリと後続のソース クエリ (DirectQuery の場合) にかかった時間が記録されます。これにより、どのビジュアルが遅いのか、また遅いクエリが DAX レイヤーにあるのかソース クエリ レイヤーにあるのかが明らかになります。

クエリ削減設定を使用する: Power BI Desktop → [オプション] → [クエリ削減] で、スライサーとフィルターに適用ボタンを追加するオプションを有効にします。これにより、すべてのスライサー操作でソース クエリが即座に実行されなくなります。これは、各クエリにネットワークとソースの実行遅延がある DirectQuery レポートの場合に特に重要です。

DirectQuery 接続の数を制限する: 複合モデル内の異なる DirectQuery ソースごとに、個別の接続プールが作成されます。可能な場合は、DirectQuery ソースを 1 ～ 2 つに制限します。 3 つを超えると、モデルが大幅に複雑になり、パフォーマンス上の問題が発生する可能性があります。

---

複合モデルの行レベルのセキュリティ

複合モデルの行レベル セキュリティ (RLS) は、特に DirectQuery テーブルとの関係があるインポート テーブルで RLS が定義されている場合、慎重な計画が必要です。

RLS フィルターを持つユーザーがレポートをクエリすると、Power BI はフィルターを適切なテーブルに適用します。フィルター処理されたテーブルがインポート モードで、DirectQuery テーブルとの関係がある場合、Power BI はインポート フィルターを DirectQuery ソースに送信できるフィルターに変換する必要があります。これはほとんどの場合に機能しますが、複雑なフィルター階層では予期しない結果が生じる可能性があります。

ベスト プラクティス: (DirectQuery ファクト テーブルではなく) インポート モードのディメンション テーブルで RLS を定義します。フィルターはリレーションシップを通じてディメンションからファクトに伝播します。これは確実に機能します。 RLS を DirectQuery テーブルに直接定義することは可能ですが、テストとデバッグは困難です。

Power BI データセットの DirectQuery を使用する複合モデルの場合、ソース データセットで定義された RLS は、そのデータセットがクエリされるときに自動的に適用されます。追加の RLS は複合モデル層で定義できます。この階層化された RLS アプローチでは、フィルターが正しく複合されていることを確認するための慎重なテストが必要です。

---

よくある質問

まったく異なるデータベース プラットフォームからのデータを複合モデル内で混合できますか?

はい。複合モデルには、SQL Server (DirectQuery)、Salesforce (DirectQuery)、Azure Blob Storage ファイル (インポート)、および Snowflake (DirectQuery) のテーブルを同時に含めることができます。各ソースは独自の接続を維持します。異なるソースからのテーブル間のリレーションシップには、クロスソース結合を容易にするために少なくとも 1 つのデュアルモード テーブルが必要です。ソースを追加するたびにパフォーマンスと複雑さが増加します。ほとんどの実装では、ソースを 2 ～ 3 つに制限することが現実的です。

複合モデルではど​​の DAX 関数が機能しませんか?

一部の DAX 関数は、DirectQuery テーブルを含む複合モデルでは制限されているか、動作が異なります。限定されたリレーションシップで機能しない関数には、SUMMARIZE (特定のコンテキストで)、TOPN (DirectQuery テーブル上)、および一部のタイム インテリジェンス関数が含まれます。 USERELATIONSHIP は機能しますが、クロスモード クエリが発生する可能性があります。制限の完全なリストは、Microsoft の Power BI ドキュメントの「DirectQuery の制限」に記載されています。 DirectQuery テーブルを追加した後は、すべての重要な対策をテストすることを強くお勧めします。

増分更新は複合モデルでどのように機能しますか?

増分更新は、複合モデル内のインポート モード パーティションに適用されます。 DirectQuery として構成されたテーブルは増分更新を使用せず、対話のたびにリアルタイムでソースに対してクエリを実行します。最も一般的な組み合わせは、現在の期間のデータに対して DirectQuery を使用しながら、インポート モードの履歴パーティションに対して増分更新を使用することです。これがハイブリッド テーブル機能であり、単一テーブル内の複合モデリングの特定の形式です。

複合モデルと純粋なインポートのパフォーマンスへの影響は何ですか?

DirectQuery コンポーネントを含む複合モデルは、同等のクエリに対する同等の純粋なインポート モデルよりも常に遅くなります。パフォーマンスのギャップは、ソース システムのパフォーマンスと、DirectQuery とインポート パーティションにヒットするクエリの割合によって異なります。適切に設計された集計テーブルを使用すると、ほとんどのユーザー クエリはインポート集計にヒットし、1 秒以内に返されるため、パフォーマンスは許容範囲内になります。 DirectQuery の詳細にドリルダウンするクエリは、ソースのパフォーマンスに応じて 3 ～ 15 秒かかる場合があります。

複合モデルを使用する必要がありますか、それともより頻繁な更新をスケジュールする必要がありますか?

「ほぼリアルタイム」が許容されるほとんどの使用例では、より頻繁な更新 (インポート モードの場合は 15 分ごと) で十分です。 DirectQuery を使用した複合モデルは非常に複雑になります。(a) 分または秒まで最新のデータが必要な場合、(b) データセットが大きすぎて増分更新を行っても利用可能なウィンドウ内で更新できない場合、または (c) 単一のウェアハウス更新に統合できないソースからのデータを結合する必要がある場合にのみ使用してください。

---

次のステップ

複合モデルは、洗練された Power BI アーキテクチャのための強力なツールですが、パフォーマンスと正確性の落とし穴を避けるために慎重な設計が必要です。最も成功した実装は、デフォルトのアーキテクチャとしてではなく、特定の正当なシナリオに複合モデルを使用します。

ECOSIRE の Power BI データ モデリング サービス には、複合モデルの設計、集計テーブルの実装、パフォーマンスの最適化が含まれます。複合モデルが特定のデータの鮮度とパフォーマンス要件に適したソリューションであるかどうかを評価するには、お問い合わせください。