次の方法で共有

Power BI サービスのセマンティック モデル モード

この記事では、Power BI セマンティック モデル モードの技術的な説明を提供します。 これは、外部ホスト型 Analysis Services モデルへのライブ接続を表すセマンティック モデルと、Power BI Desktop で開発されたモデルにも適用されます。 この記事では、各モードの根拠と、Power BI 容量リソースに与える可能性のある影響を強調しています。

3 つのセマンティック モデル モードは次のとおりです。

インポート モード

インポート モードは、セマンティック モデルの開発に使用される最も一般的なモードです。 このモードは、メモリ内クエリにより高速なパフォーマンスを実現します。 また、モデリング担当者に対する設計の柔軟性と、特定の Power BI サービス機能 (Q&A、Quick Insights など) のサポートも提供します。 これらの長所により、新しい Power BI Desktop ソリューションを作成するときの既定のモードです。

インポートされたデータは常にディスクに格納されることを理解しておくことが重要です。 クエリまたは更新を行うときは、データを Power BI 容量のメモリに完全に読み込む必要があります。 メモリ内でモデルをインポートすると、非常に高速なクエリ結果を得ることができます。 また、インポート モデルがメモリに部分的に読み込まれるという概念がないことを理解することも重要です。

更新すると、データは圧縮および最適化され、VertiPaq ストレージ エンジンによってディスクに格納されます。 ディスクからメモリに読み込まれると、10 倍の圧縮を確認できます。 そのため、10 GB のソース データを約 1 GB のサイズに圧縮できることを期待するのが妥当です。 ディスク上のストレージ サイズは、圧縮サイズから 20% 削減できます。 サイズの違いは、Power BI Desktop のファイル サイズと、ファイルのタスク マネージャーのメモリ使用量を比較することで決定できます。

設計の柔軟性は、次の 3 つの方法で実現できます。

  • データ ソースの種類や形式に関係なく、データフローや外部データ ソースからデータをキャッシュすることで、データを統合します。
  • データ準備クエリの作成時には、M 関数と呼ばれる Power Query M 数式言語のセット全体を使用します。
  • ビジネス ロジックを使用してモデルを拡張するときに 、データ分析式 (DAX) 関数のセット全体を適用します。 計算列、計算テーブル、メジャーのサポートがあります。

次の図に示すように、インポート モデルでは、サポートされている任意の数のデータ ソース型のデータを統合できます。

インポート モデルが任意の数の外部データ ソース型のデータを統合できることを示す図。

ただし、インポート モデルには魅力的な利点がありますが、欠点もあります。

  • Power BI がモデルのクエリを実行する前に、モデル全体をメモリに読み込む必要があります。これは、特にインポート モデルの数とサイズが大きくなるにつれて、使用可能な容量リソースに負荷をかけることができます。
  • モデル データは最新の更新と同じだけであるため、インポート モデルは通常はスケジュールに基づいて更新する必要があります。
  • 完全更新では、すべてのテーブルからすべてのデータが削除され、データ ソースから再読み込みされます。 この操作は、Power BI サービスとデータ ソースの時間とリソースの面でコストがかかる場合があります。

注

Power BI では、テーブル全体の切り捨てと再読み込みを回避するために、増分更新を実現できます。 サポートされているプランやライセンスなど、詳細については、 セマンティック モデルの増分更新とリアルタイム データに関するページを参照してください。

Power BI サービス リソースの観点から見ると、モデルのインポートには次のものが必要です。

  • クエリまたは更新時にモデルを読み込むための十分なメモリ。
  • データ更新用の処理リソースおよび追加メモリリソース。

DirectQuery モード

DirectQuery モードは、インポート モードの代わりに使用できます。 DirectQuery モードで開発されたモデルでは、データはインポートされません。 代わりに、モデル構造を定義するメタデータのみで構成されます。 モデルのクエリを実行すると、基になるデータ ソースからデータを取得するためにネイティブ クエリが使用されます。

図は、DirectQuery モデルが基になるデータ ソースにネイティブ クエリを発行する方法を示しています。

DirectQuery モデルの開発を検討する主な理由は 2 つあります。

  • データ量が大きすぎて、データ削減方法 を適用しても、モデルに読み込むことや、実用的に更新することが困難な場合。
  • レポートとダッシュボードが、スケジュールされた更新制限内で達成できる範囲を超えて、 ほぼリアルタイム のデータを配信する必要がある場合。 スケジュールされた更新制限は、共有容量の場合は 1 日 8 回、Premium 容量の場合は 1 日 48 回です。

DirectQuery モデルにはいくつかの利点があります。

  • インポート モデルのサイズ制限は適用されません。
  • モデルでは、スケジュールされたデータ更新は必要ありません。
  • レポート フィルターとスライサーを操作すると、レポート ユーザーに最新のデータが表示されます。 また、レポート ユーザーはレポート全体を更新して、現在のデータを取得できます。
  • リアルタイム レポートは、 ページの自動更新 機能を使用して開発できます。
  • DirectQuery モデルに基づくダッシュボード タイルは、15 分ごとに自動的に更新できます。

ただし、DirectQuery モデルにはいくつかの制限があります。

  • Power Query/Mashup 式は、データ ソースによって認識されるネイティブ クエリに置き換えることができる関数にのみできます。
  • DAX 数式は、データ ソースによって認識されるネイティブ クエリに置き換えることができる関数のみを使用するように制限されています。 計算テーブルはサポートされていません。
  • Quick Insights の機能はサポートされていません。

Power BI サービス リソースの観点から見ると、DirectQuery モデルには次のものが必要です。

  • クエリが実行されたときにモデルを読み込むための最小限のメモリ (メタデータのみ)。
  • Power BI サービスでは、データ ソースに送信されたクエリを生成して処理するために、重要なプロセッサ リソースを使用する必要がある場合があります。 このような状況が発生した場合、特に同時実行ユーザーがモデルに対してクエリを実行している場合に、スループットに影響を与える可能性があります。

詳細については、「 Power BI Desktop での DirectQuery の使用」を参照してください。

複合モード

複合 モードでは、インポート モードと DirectQuery モードを混在させたり、複数の DirectQuery データ ソースを統合したりできます。 複合モードで開発されたモデルは、各モデル テーブルのストレージ モードの構成をサポートします。 このモードでは、DAX で定義された計算テーブルもサポートされます。

テーブル ストレージ モードは、Import、DirectQuery、または Dual として構成できます。 デュアル ストレージ モードとして構成されたテーブルはインポートと DirectQuery の両方であり、この設定により、Power BI サービスはクエリごとに使用する最も効率的なモードを決定できます。

図は、複合モデルが、テーブル レベルで構成されたインポート ストレージ モードと DirectQuery ストレージ モードの組み合わせであることを示しています。

複合モデルは、インポート モードと DirectQuery モードを最大限に活用するよう努めています。 適切に構成すると、インメモリ モデルの高いクエリ パフォーマンスと、データ ソースからほぼリアルタイムのデータを取得する機能を組み合わせることができます。

詳細については、「 Power BI Desktop で複合モデルを使用する」を参照してください。

純粋インポート テーブルと DirectQuery テーブル

複合モデルを開発するデータ モデリング担当者は、インポートまたはデュアル ストレージ モードでディメンションの種類のテーブルを構成し、DirectQuery モードでファクトタイプ テーブルを構成する可能性があります。 モデル テーブルロールの詳細については、「 スター スキーマと Power BI の重要性について」を参照してください。

たとえば、デュアル モードの Product ディメンション型テーブルと DirectQuery モードの Sales ファクト型テーブルを持つモデルを考えてみましょう。 Product テーブルは、インメモリから効率的かつ迅速にクエリを実行して、レポート スライサーをレンダリングできます。 Sales テーブルは、関連する Product テーブルを使用して DirectQuery モードで照会することもできます。 後者のクエリでは、 Product テーブルと Sales テーブルを結合し、スライサー値でフィルター処理する 1 つの効率的なネイティブ SQL クエリを生成できます。

ハイブリッド テーブル

複合モデルを開発するデータ モデリング担当者は、ファクト テーブルをハイブリッド テーブルとして構成することもできます。 ハイブリッド テーブルは、1 つまたは複数のインポート パーティションと 1 つの DirectQuery パーティションを持つテーブルです。 ハイブリッド テーブルの利点は、次の視覚化に示すように、前回のインポート サイクル後に発生したデータ ソースからの最新のデータ変更を含めると同時に、インメモリから効率的かつ迅速にクエリできることです。

[アーカイブ済み]、[増分更新]、[リアルタイム] の各行がマークされたハイブリッド テーブル パーティションを示すスクリーンショット。

ハイブリッド テーブルを作成する最も簡単な方法は、Power BI Desktop で増分更新ポリシーを構成し、[ DirectQuery を使用して最新のデータをリアルタイムで取得する (Premium のみ)]オプションを有効にすることです。 Power BI では、このオプションが有効になっている増分更新ポリシーを適用すると、前の図に表示されたパーティション分割スキームのようにテーブルがパーティション分割されます。 パフォーマンスを向上させるには、ディメンションの種類のテーブルをデュアル ストレージ モードで構成して、Power BI が DirectQuery パーティションのクエリを実行するときに効率的なネイティブ SQL クエリを生成できるようにします。

注

Power BI では、Premium 容量のワークスペースでセマンティック モデルがホストされている場合にのみ、ハイブリッド テーブルがサポートされます。 したがって、DirectQuery で最新のデータをリアルタイムで取得するオプションを使用して増分更新ポリシーを構成する場合は、セマンティック モデルを Premium ワークスペースにアップロードする必要があります。 詳細については、 セマンティック モデルの増分更新とリアルタイム データに関するページを参照してください。

また、表形式モデル スクリプト言語 (TMSL) または表形式オブジェクト モデル (TOM) を使用して DirectQuery パーティションを追加するか、サードパーティのツールを使用して、インポート テーブルをハイブリッド テーブルに変換することもできます。 たとえば、最新のデータのごく一部のみがインポートされている間に、データの大部分がデータ ウェアハウスに残されるようにファクト テーブルをパーティション分割できます。 この方法は、このデータの大部分がアクセス頻度の低い履歴データである場合にパフォーマンスを最適化するのに役立ちます。 ハイブリッド テーブルには複数のインポート パーティションを含めることができますが、DirectQuery パーティションは 1 つだけです。

関連コンテンツ

  • Last updated on