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

[アーティクル]
04/13/2024

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

前提条件

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

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

Power BI がクエリ処理から DirectQuery パーティションを誤って除外する可能性があるため、正しく定義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デュアル モードに変換します。テーブルは FactInternetSalesDirectQuery モードのままにします。
データセットをアップロードします。書き込み操作で XMLA エンドポイントが有効になっているPower BI Premiumでホストされているワークスペースを使用します。
互換性レベルを更新します。 SQL Server Management Studio (SSMS) で AdventureWorks データセットを使用してワークスペースを開きます。 AdventureWorks データセット>のスクリプト>スクリプトデータベースを [作成] または [置換] として右クリックし、[新しいクエリエディター] ウィンドウを選択します。 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 クエリのスクリーンショット。

次の dataCoverageDefinition TMSL スニペットのように DirectQuery パーティションにプロパティを設定すると、これらの 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 つのグループに分類された、サポートされている操作については、次の表を参照してください。 

Type	説明	例
単一述語 (値ベース)	等値、不等値、および 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 RELATED('Date'[Year]) = 2020 && RELATED('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)

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

考慮事項と制限事項

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

次の方法で共有

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

前提条件

ホットテーブルパーティションとコールドテーブルパーティションを使用する場合

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

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

考慮事項と制限事項

フィードバック

フィードバック

その他のリソース

次の方法で共有

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

前提条件

ホット テーブル パーティションとコールド テーブル パーティションを使用する場合

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

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

考慮事項と制限事項

フィードバック

フィードバック

その他のリソース

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

ホットテーブルパーティションとコールドテーブルパーティションを使用する場合

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

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