ホットテーブルパーティションとコールドテーブルパーティションを使用して、非常に大きな Power BI データモデルを最適化する

この記事では、ホットテーブルパーティションとコールドテーブルパーティションを使用して、非常に大きなデータモデルを最適化する方法について説明します。パーティションは、テーブルのデータを個別のサブセットに分割する方法を提供します。パーティションは標準の Power BI データモデリングツールでは直接公開 されません が、Power BI Desktop で増分更新ポリシーを構成することで、高度なパーティション分割方法を利用できます。増分更新は、データセットの増分更新とリアルタイムデータで説明されているように、パーティションに依存します。ただし、ホットテーブルパーティションとコールドテーブルパーティションの構成は、増分更新ポリシーで実現できる機能を超え、一般的なテーブルパーティション分割スキームと XMLA ベースのツールに精通していることを前提としています。

[前提条件]

このパーティション分割手法の相対的な複雑さのため、次の領域の経験を持つ上級ユーザーに最適です。

テーブルパーティション分割の概念、インポートモードパーティション、 DirectQuery モード 、デュアルモード のしくみについて説明します。
XMLA ベースのツールを使用してハイブリッドテーブルを作成する方法に関する知識。ハイブリッドテーブルでは、1 つ以上のインポートモードパーティションと 1 つの DirectQuery パーティションが使用されます。
DataCoverageDefinitionを指定するために使用できる DAX 関数の要件に関する知識。これは、Power BI エンジンが必要に応じてクエリ処理からこのパーティションを除外できるように、ハイブリッドテーブルの DirectQuery パーティションに含まれるデータを記述するための DirectQuery パーティションの新しいプロパティです。 DirectQuery パーティションを除外すると、不要なデータソースクエリを回避し、DAX クエリ処理のパフォーマンスを向上させることができます。
通常のテーブルリレーションシップと制限されたテーブルリレーションシップの違いを理解する。たとえば、RELATED 関数は、関連する日付ディメンションテーブルの値に基づいてファクトテーブルパーティションのデータカバレッジを定義する場合に便利です。ファクトテーブルパーティションは DirectQuery パーティションであり、RELATED 関数が値をフェッチできない日付テーブルとのリレーションシップが制限される可能性があることに注意してください。このシナリオでは、RELATED は日付ディメンションテーブルがデュアルテーブルの場合にのみ機能します。日付テーブルは 、DirectQuery または デュアル モードである必要があります。純粋なインポートにすることはできません。

Power BI によって DataCoverageDefinition パーティションがクエリ処理から誤って除外される可能性があるため、正しく定義されていないが間違った結果を招く可能性があることに注意してください。そのため、DataCoverageDefinition の有無で結果を比較し、それぞれの結果が一致することを確認してください。

ホットテーブルパーティションとコールドテーブルパーティションを使用するタイミング

ホットパーティションとコールドパーティションが、履歴分析用のハイブリッドテーブルの微調整に役立つ例を次に示します。長年にわたって蓄積された非常に大規模なデータソースがあるとします。主な用途は、過去 2 年間の最新のデータを分析することです。場合によっては、古いデータを分析することもできます。おそらく、最近の売上が前年比で急激に増加していることに気付いたと思います。それは今まで起こったことがありますか? 売上追跡を開始して以来、最大の売上急増ですか?

ホットパーティションとコールドパーティションをサポートしていない場合、この種の履歴分析では、すべての履歴データと最新のデータをファクトテーブルにインポートする必要があります。プライマリ分析では古い履歴データも使用されないため、これはリソースの非効率的な使用です。最悪の場合、データボリュームは非常に大きいため、完全にインポートすることもできません。データモデルを DirectQuery モードに切り替え、インポートモードと比較してパフォーマンスの低下を受け入れるか、別のモデルを構築してユーザーにレポートを切り替える必要があります。ホットパーティションとコールドパーティションを含むハイブリッドテーブルを使用すると、より優れたオプションが提供されます。

ホットテーブルパーティションとコールドテーブルパーティションの使用方法

まず、AdventureWorks サンプルデータモデルの FactInternetSales テーブルを次の図に示すように、最新のデータの ホット インポートモードパーティションを使用して売上テーブルを構成し、古いデータを コールドDirectQuery パーティションに保持します。 20200101以上の OrderDateKey を持つ行は、ホットインポートモードパーティションを介してデータモデルにインポートされます。 OrderDateKey が20200101未満の行は、コールド DirectQuery パーティションでカバーされます。これで、Power BI はインポートモードで主要なユースケースを迅速に提供できます。 DirectQuery パーティションでこれをカバーしているため、たまにしか分析しない膨大な量の履歴データをインポートする必要はありません。

Adventure Works サンプルデータモデルの Fact Internet Sales テーブルのスクリーンショット。ファクトインターネット販売テーブルが開き、フィルター処理された行が表示されます。

AdventureWorks サンプルデータウェアハウスがあり、それに従いたい場合は、一般的な手順を次に示します。

データセットを作成します。 Power BI Desktop を使用して、AdventureWorks データセットとレポートを作成します。すべてのテーブルを純粋 DirectQuery モードで含めます。次に、 FactInternetSales テーブルを除くすべてのテーブルを デュアル モードに変換します。 FactInternetSales テーブルは DirectQuery モードのままにします。
データセットをアップロードします。書き込み操作用に XMLA エンドポイントを有効にして、Power BI Premium でホストされているワークスペースを使用します。
互換性レベルを更新します。 SQL Server Management Studio (SSMS) で AdventureWorks データセットを含むワークスペースを開きます。 AdventureWorks データセット>Script>Script Database asCreate または Replace to を右クリックし、[新しいクエリエディター] ウィンドウを選択します。 compatibilityLevel プロパティを 1603 (以上) に設定します。 [ 実行] を選択するか、F5 キーを押します。操作が正常に完了したことを確認します。

FactInternetSales テーブルパーティションを構成します。 AdventureWorks データセット>スクリプト>スクリプトデータベースとして作成または置換先を右クリックし、[新しいクエリエディターウィンドウ]を選択します。パーティションセクション全体を次のセクションに置き換えます。環境内の AdventureWorksDW データベースを指すように Sql.Database 行を更新してください。 [ 実行] を選択するか、F5 キーを押します。操作が正常に完了したことを確認します。

   "partitions": [ 
    { 
      "name": "FactInternetSales-DQ-Partition", 
      "mode": "directQuery", 
      "dataView": "full", 
      "source": { 
        "type": "m", 
        "expression": [ 
          "let", 
          "    Source = Sql.Database(\"demo.database.windows.net\", \"AdventureWorksDW\"),", 
          "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] < 20200101)", 
          "in", 
          "    #\"Filtered Rows\"" 
        ] 
      } 
    }, 
    { 
      "name": "FactInternetSales-Import-Partition", 
      "mode": "import", 
      "source": { 
        "type": "m", 
        "expression": [ 
          "let", 
          "    Source = Sql.Database(\"demo.database.windows.net\", \"AdventureWorksDW\"),", 
          "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
          "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= 20200101)", 
          "in", 
          "    #\"Filtered Rows\"" 
        ] 
      } 
    } 
  ],

データモデルを処理します。 Power BI ポータルで、 AdventureWorks データセットを含むワークスペースを開き、データセットのオンデマンド更新を実行して、データを含むインポートパーティションを読み込みます。
レポートに最近のデータと履歴データが表示されていることを確認します。 AdventureWorks を開き、次のスクリーンショットのように、2020 年 1 月 1 日以降の販売トランザクションの結果をレポートに表示できることを確認します。

2 つの異なるレポートのスクリーンショット。1 つは 2020 年のデータを示し、1 つは 2019 年のデータを示しています。

DirectQuery パーティションのデータカバレッジを定義する

このソリューションは、最近のデータと履歴データに対してシームレスに機能します。ただし、既定では、Power BI では、各パーティションに含まれるデータがわからないため、すべてのテーブルパーティションに対してクエリが実行されます。そのため、Power BI は、DirectQuery パーティションがカバーしていない年数であっても DirectQuery パーティションに対してクエリを実行します。売上データはインポートパーティションですぐに使用でき、DirectQuery パーティションは行を提供しませんが、この余分なソースクエリを実行しても、データソースに顕著な負荷が発生し、DAX クエリ処理に遅延が発生する可能性があります。この余分なソースクエリを回避するには、 DataCoverageDefinitionを使用します。

次のスクリーンショットに示すように、Power BI レポートでは、各ビジュアルの DAX クエリによって Power BI が DirectQuery パーティションにクエリを実行するため、2020 の不要な SQL クエリがいくつかデータソースに送信されます。

DAX クエリのスクリーンショット。

次の TMSL スニペットのように dataCoverageDefinition パーティションにプロパティを設定することで、これらの SQL クエリは回避されます。ただし、データカバレッジ定義を適用または変更した後にデータセットを更新する必要があることに注意してください。データカバレッジ定義を評価するには、プロセスの再計算で十分です。この手順を忘れると、パーティションにアクセスしようとするクエリがエラーになります。エラーメッセージは、「テーブル『[テーブル名]』のDQパーティションのDataCoverageDefinitionが最近の変更後にまだ計算されていません」と表示されます。再処理する必要があります。

        { 
          "name": "FactInternetSales-DQ-Partition", 
          "mode": "directQuery", 
          "dataView": "full", 
          "source": { 
            "type": "m", 
            "expression": [ 
              "let", 
              "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW2020\"),", 
              "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
              "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] < 20200101)", 
              "in", 
              "    #\"Filtered Rows\"" 
            ] 
          },  
"dataCoverageDefinition": {  
                  "description": "DQ partition with all sales from 2017, 2018, and 2019.",  
                  "expression": "RELATED('DimDate'[CalendarYear]) IN {2017,2018,2019}"  
                }  
        }

前述のように、 dataCoverageDefinition プロパティは不要なデータソースの読み込みを排除するのに役立ちます。また、Power BI では必要に応じて DAX クエリ処理から DirectQuery パーティションを除外できるため、最近のデータの分析パフォーマンスも向上します。単純な AND 演算子、OR 演算子、NOT 演算子を使用して、単一の値と範囲に対して単純なデータカバレッジ式を定義できます。 RELATED 関数を使用して、ファクトテーブルと通常のリレーションシップを持つディメンションテーブルの列に基づいてデータカバレッジを定義することもできます。データカバレッジ式でディメンションテーブルの列が使用されている場合は、ディメンションテーブルが デュアル モードであることを確認します。ファクトテーブル自体の列に基づいてデータカバレッジを定義することもできます。サポートされている操作については、次の表を参照してください。3 つのグループに分類されています。 

タイプ	Comments	例示
単一の述語（値を基準にした）	等値、不等値、および IN 演算子ディメンションテーブルとファクトテーブルの両方をサポートする	RELATED('Date'[Year]) = 2020 NOT RELATED('Date'[Year]) = 2020 RELATED('Date'[Year]) IN {2020, 2021, 2022} InternetSales'[SalesAmt] = CURRENCY(100.0) 「NOT InternetSales'[SalesAmt] = CURRENCY(100.0)」 InternetSales'[SalesAmt] IN {CURRENCY(100.0), CURRENCY(200.0)}
単一述語 (範囲ベース)	>、<、>=、<= などの比較演算子を指定できます。ディメンションテーブルをデュアルモードにする必要がある	RELATED('Date'[Year]) > 2020 RELATED('Date'[Year]) <= 2020
複数の述語	等値、不等値、および比較 IN 演算子をサポートしていませんデュアルモードの 1 つのディメンションテーブルに制限	RELATED('Date'[Year]) > 2010 > RELATED('Date'[Year]) > 2020 関連('Date'[Year]) = 2020 かつ関連('Date'[Calendar Quarter]) = 1 RELATED('Date'[Year]) > 2020 > NOT RELATED('Date'[Calendar Quarter]) = 1 RELATED('Date'[Year]) > 2020 > RELATED('Date'[Calendar Quarter]) < 3 RELATED('Date'[Year]) > 2020 > (RELATED('Date'[Calendar Quarter]) = 1 \|\|RELATED('Date'[Calendar Quarter]) = 2)

DataCoverageDefinition パーティションのプロパティを使用すると、データソースの不要なクエリを回避することで、インポートモードのホットパーティションと DirectQuery モードのコールドパーティションに基づいて、最大の Power BI データモデルを最適化できます。このソースクエリの削減は、ホットデータを分析するときにレポートのパフォーマンスを向上するのに役立ちます。また、データソースの負荷を減らすのに役立ちます。この方法では、データソースのスケールを最大化するのに役立ちます。ただし、 dataCoverageDefinition プロパティを使用してデータモデルを最適化することは、依然として高度なシナリオであることに注意してください。結果は慎重に確認してください。

考慮事項と制限事項

現在、DataCoverageDefinition パーティションのプロパティには、RELATED('Date'[Year]) = 2020 や RELATED('Date'[Year]) IN {2020, 2021, 2022} などの静的な値が必要です。 RELATED('Date'[DateKey]) = TODAY() など、動的割り当てはサポートされていません。
リアルタイムデータを使用した増分更新では、 DataCoverageDefinition プロパティは利用されません。 DirectQuery (リアルタイム) パーティションにデータカバレッジ定義を適用すると、パーティションを再作成するときに、増分更新によってデータカバレッジ定義が削除されます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-02-03

次の方法で共有

ホット テーブル パーティションとコールド テーブル パーティションを使用して、非常に大きな Power BI データ モデルを最適化する

[前提条件]

ホット テーブル パーティションとコールド テーブル パーティションを使用するタイミング

ホット テーブル パーティションとコールド テーブル パーティションの使用方法

DirectQuery パーティションのデータ カバレッジを定義する