次の方法で共有


Power BI セマンティック モデルのテーブル ストレージ モード

Power BI セマンティック モデルのテーブルには、データ ソースに応じて異なるストレージ モードがあります。 ストレージ モードでは、Power BI がレポートのテーブル データをメモリ内に格納するか、ビジュアルが読み込まれるときにデータ ソースからデータを取得するかを制御できます。

テーブル ストレージ モード 使用可能な場合 特典
輸入 ほぼすべてのデータ ソースからの データの取得 (Power Query を使用) を使用した Power BI Desktop および Power BI Web モデリングで使用できます。 レポートにビジュアルをすばやく読み込むため、データのスナップショットをネイティブ ストレージに格納します。 セマンティック モデルまたはテーブルを更新して、データ ソースから最新のデータを取得します。
OneLakeにおけるダイレクトレイク Fabric データ ソース用の OneLake カタログ を使用した Power BI Desktop および Power BI Web モデリングで使用できます。 OneLake デルタ テーブルからデータがスキャンされ、レポートにビジュアルがすばやく読み込まれます。 既定では、最新のデータが読み込まれます。 代わりに、スケジュールされた更新設定ページで自動同期をオフにして、更新時に最新のデータにアクセスします。 更新は、Direct Lake のリフレーミングとも呼ばれます。 Direct Lake at aka.ms/DirectLake の詳細をご覧ください。
SQL上のダイレクトレイク Fabric 項目の SQL 分析エンドポイントの 新しいセマンティック モデル ボタンから使用できます。 OneLake デルタ テーブルからデータがスキャンされ、レポートにすばやく読み込まれます。 ビューが使用されている場合、SQL の詳細アクセスが有効になっている場合、または Direct Lake ガードレールに達した場合、データには DirectQuery ストレージ モードを使用してアクセスされます。
DirectQuery SQL データベースなどの一部のデータ ソースのデータ の取得 (Power Query を使用) を使用して Power BI Desktop で使用できます。 ビジュアルが読み込まれるときにデータ ソースからデータが照会され、セマンティック モデルに格納されません。 このクエリは、ビジュアルで使用される Power BI DAX クエリから、SQL クエリなどのデータ ソースのネイティブ クエリ言語への変換です。
Power BI セマンティック モデルでの DirectQuery Power BI セマンティック モデルに接続し、このモデルに 変更を加えるか 、インポートテーブルまたは DirectQuery テーブルが既に追加されている場合に、Power BI Desktop で使用できます。 新しいモデルからの DAX クエリはソース モデルで実行され、両方のメジャーを使用できます。 リモート モデルの一部の列プロパティは、新しいモデルでオーバーライドできます。 このカスタマイズには、書式指定文字列と表示名が含まれます。 特定のレポートの既存のセマンティック モデルを少し変更する必要がある場合は、このストレージ モードを使用します。
デュアル インポートする DirectQuery テーブルを変換するときに、Power BI Desktop で使用できます。 ダイアログには、残りの DirectQuery テーブルをデュアルに変換するためのオプションが表示されます。 DirectQuery テーブルとインポート テーブルの間のリレーションシップは制限されており、デュアル テーブルは通常のリレーションシップとして維持するのに役立ちます。
ハイブリッド インポート テーブルの増分更新シナリオで使用できます。 テーブルの最新のパーティションを DirectQuery に含め、インポート更新の間に最新のデータを使用できるようにします。 増分更新の詳細については、 増分更新の概要を参照してください。

手記

ライブ接続 は、Power BI Desktop で Power BI セマンティック モデルに接続してレポートを作成するか、Web の Power BI セマンティック モデルからレポートを作成する場合です。 このレポートのローカル セマンティック モデルはありません。 これは 薄いレポートと呼ばれることもあります。 リモート Power BI セマンティック モデルでは、テーブル ストレージ モードのいずれかを使用できます。 レポート作成者はモデル ビューでモデルを表示できますが、使用できる情報は限られています。 作成されたメジャーはレポートに格納されます。

複合セマンティック モデル は、複数のストレージ モードのテーブルを含むセマンティック モデルです。 詳細については、「Power BI Desktopで複合モデルを使用する」を参照してください。

テーブルのストレージ モードの表示

Storage mode プロパティは、各テーブルのプロパティです。

  1. モデル ビューで、テーブルを選択します。

  2. [のプロパティ] ウィンドウで、[詳細] セクションを展開し、[ストレージ モード] ドロップダウンを展開します。

    リレーションシップ ビューのスクリーンショットでは、ストレージ モードを変更するオプションドロップダウンが強調表示されています。

ほとんどのテーブルでは、テーブルのみを追加するとストレージ モードが設定されます。 ストレージ モードは、作成時にテーブルが DirectQuery ストレージ モードの場合にのみ変更できます。 DirectQuery テーブルは、インポートまたはデュアルに変更できます。 このプロパティを設定した後は、DirectQuery に戻すことはできません。 Power BI Desktop での Power BI Web モデリングとライブ編集にはバージョン管理があり、これを使用して変更されたストレージ モードを元に戻すことができます。

手記

Direct Lake on OneLake テーブルは、Fabric ノートブックのセマンティック リンク ラボを使用してインポートするように変換できます。

DirectQuery テーブルとデュアル テーブルに関する制約

デュアル テーブルには、DirectQuery テーブルと同じ機能制約があります。 これらの制約には、計算列の制限付き M 変換と制限付き DAX 関数が含まれます。 詳細については、「DirectQuery の制限事項」を参照してください。

[デュアル] 設定の伝達

すべてのテーブルが Import と DirectQuery をサポートする 1 つのソースからの次のモデルについて考えてみます。

ストレージ モードのリレーションシップ ビューの例のスクリーンショット。

このモデルのすべてのテーブルが最初に DirectQueryに設定されているとします。 その後、SurveyResponse テーブルの ストレージ モードの を [インポート] に変更すると、次の警告ウィンドウが表示されます。

ストレージ モードをインポートに変更した結果を示す警告ウィンドウを示すスクリーンショット。

ディメンション テーブル (CustomerGeography、および Date) を デュアル に設定して、セマンティック モデル内の制限されたリレーションシップの数を減らし、パフォーマンスを向上させることができます。 通常、制限付きリレーションシップには、結合ロジックをソース システムにプッシュできない DirectQuery テーブルが少なくとも 1 つ含まれます。 デュアル テーブルは DirectQuery テーブルまたはインポート テーブルとして機能できるため、この状況は回避されます。

伝達ロジックは、多数のテーブルを含むモデルに役立つよう設計されています。 50 個のテーブルを持つモデルがあり、特定のファクト (トランザクション) テーブルのみをキャッシュする必要があるとします。 Power BI Desktop のロジックでは、デュアルを に設定する必要があるディメンション テーブルの最小セットが計算されるため、計算する必要はありません。

伝達ロジックは、一対多リレーションシップの一方の側にのみ走査されます。

ストレージ モードの使用例

次のストレージ モードのプロパティ設定を適用するとします。

ストレージ モード
Sales DirectQuery
SurveyResponse 輸入
日付 デュアル
顧客 デュアル
地理学 デュアル

これらのストレージ モードのプロパティを設定すると、Sales テーブルのデータ量が大きいと仮定すると、次のような動作になります。

  • Power BI Desktop では、ディメンション テーブル、日付CustomerGeographyがキャッシュされるため、表示するスライサー値を取得すると、初期レポートの読み込み時間が速くなります。

  • Power BI Desktop では、Sales テーブルはキャッシュされません。 Power BI Desktop では、このテーブルをキャッシュしないことで、次の結果が得られます。

    • データ更新時間が短縮され、メモリ消費量が削減されます。
    • Sales テーブルに基づくレポート クエリは、DirectQuery モードで実行されます。 キャッシュの待機時間が発生しないため、これらのクエリには時間がかかる場合がありますが、リアルタイムに近くなります。
  • SurveyResponse テーブルに基づくレポート クエリはメモリ内キャッシュから返されるため、比較的高速です。

キャッシュにヒットするクエリまたはヒットしないクエリ

Power BI Desktop の診断ポートに SQL Profiler を接続する場合は、次のイベントに基づくトレースを実行することで、メモリ内キャッシュにヒットまたはミスしたクエリを確認できます。

  • クエリイベント\クエリ開始
  • クエリ処理\Vertipaq SE クエリの開始
  • クエリ処理\DirectQuery 開始

Query Begin イベントごとに、同じ ActivityID を使用して他のイベントを確認します。 たとえば、DirectQuery Begin イベントがないのに、Vertipaq SE Query Begin イベント がある場合、クエリはキャッシュから応答されます。

デュアル テーブルを参照するクエリは、可能であればキャッシュからデータを返します。それ以外の場合は、DirectQuery に戻ります。

次のクエリは、前の表から続行されます。 これは、デュアル モードの Date テーブルからの列のみを参照します。 したがって、クエリはキャッシュにヒットする必要があります。

日付テーブルを参照するクエリのテキストを示すスクリーンショット。

次のクエリは、DirectQuery モードの Sales テーブル 列のみを参照します。 そのため、キャッシュにはヒット "しません"。

Sales テーブルを参照するクエリのテキストを示すスクリーンショット。

次のクエリは、両方の列を組み合わせるので興味深いものです。 このクエリはキャッシュにヒットしません。 まず、キャッシュから CalendarYear 値を取得し、ソースから SalesAmount 値を取得して結果を結合すると期待されるかもしれませんが、このアプローチは、SUM/GROUP BY 操作をソースシステムに送信するよりも効率的ではありません。 操作がソースにプッシュダウンされた場合、返される行の数ははるかに少なくなる可能性があります。

Date テーブルと Sales テーブルの両方を参照するクエリのテキストを示すスクリーンショット。

手記

この動作は、Power BI Desktop でキャッシュされたテーブルとキャッシュされていないテーブルを組み合わせた場合、多対多リレーションシップ とは異なります。

キャッシュの同期を維持する必要がある

前のセクションに表示されたクエリは、デュアル テーブルがキャッシュにヒットすることがあり、ヒットしない場合があることを示しています。 その結果、キャッシュが古い場合は、異なる値を返すことができます。 クエリの実行では、たとえば、キャッシュされた値と一致するように DirectQuery の結果をフィルター処理することで、データの問題をマスクしようとはしません。 データ フローを把握するのはユーザーの責任であり、それに応じて設計する必要があります。 必要に応じて、ソースでこのようなケースを処理するための確立された手法があります。

デュアル ストレージ モードは、パフォーマンスの最適化です。 ビジネス要件を満たす能力を損なわない方法でのみ使用する必要があります。 別の動作については、Power BI Desktopの 多対多リレーションシップで説明されている手法を使用することを検討してください。

テーブル ビュー

セマンティック モデル内の少なくとも 1 つのテーブルのストレージ モードが インポート またはデュアルに設定されている場合は、[テーブル ビュー] タブが表示されます。

テーブル ビュー アイコンが強調表示されているスクリーンショット。

テーブル ビューでデュアル テーブルとインポート テーブルを選択すると、キャッシュされたデータが表示されます。 DirectQuery テーブルにはデータが表示されません。DirectQuery テーブルを表示できないことを示すメッセージが表示されます。

考慮事項と制限事項

ストレージ モードの現在のリリースと複合モデルとの相関関係には、いくつかの制限があります。

次のライブ接続 (多次元) ソースは、複合モデルでは使用できません。

  • SAP HANA
  • SAP Business Warehouse

DirectQuery を使用してこれらの多次元ソースに接続する場合、別の DirectQuery ソースに接続したり、インポートされたデータと組み合わせたりすることはできません。

複合モデルを使用する場合、DirectQuery の使用に関する既存の制限は引き続き適用されます。 これらの制限の多くは、テーブルのストレージ モードに応じて、テーブルごとに適用されるようになりました。 たとえば、インポートされたテーブルの計算列は他のテーブルを参照できますが、DirectQuery テーブルの計算列は、同じテーブルの列のみを参照するように制限されます。 モデル内のいずれかのテーブルが DirectQuery の場合、モデル全体に他の制限が適用されます。

複合モデルと DirectQuery の詳細については、次の記事を参照してください。