Power BI での増分更新Incremental refresh in Power BI

Power BI の非常に大きいデータセットの増分更新には、次の利点があります。Incremental refresh enables very large datasets in Power BI with the following benefits:

  • 更新が高速化される - 更新する必要があるのは変更されたデータのみです。Refreshes are faster - Only data that has changed needs to be refreshed. たとえば、10 年間のデータセットのうち過去 5 日間だけを更新します。For example, refresh only the last five days of a ten-year dataset.
  • 更新の信頼性が高くなる - 揮発性のソース システムに対して長時間の接続を維持する必要がなくなります。Refreshes are more reliable - It's no longer necessary to maintain long-running connections to volatile source systems.
  • リソースの消費量が減る - 更新するデータが少ないと、メモリや他のリソースの全体的な消費量が減少します。Resource consumption is reduced - Less data to refresh reduces overall consumption of memory and other resources.

注意

増分更新は、Power BI Pro、Premium および共有サブスクリプションとデータセットで行えます。Incremental refresh is now available for Power BI Pro, Premium, and shared subscriptions and datasets.

増分更新を構成するConfigure incremental refresh

増分更新ポリシーは、Power BI Desktop で定義し、発行されると Power BI サービスに適用されます。Incremental refresh policies are defined in Power BI Desktop and applied when published to the Power BI service.

Power BI Desktop で大きいデータセットをフィルター処理するFilter large datasets in Power BI Desktop

PBIX ファイルはデスクトップ コンピューターで利用可能なメモリ リソースによって制限されるため、数十億行になる可能性のある大きいデータセットは Power BI Desktop モデルに収まらない場合があります。Large datasets with potentially billions of rows may not fit into a Power BI Desktop model because the PBIX file is limited by the memory resources available on the desktop computer. したがって、そのようなデータセットは、一般に、インポート時にフィルター処理されます。Such datasets are therefore commonly filtered upon import. この種のフィルター処理には、増分更新を使用するかどうかどうかが適用されます。This type of filtering applies whether using incremental refresh or not. 増分更新の場合は、Power Query の日付/時刻パラメーターを使用してフィルター処理します。For incremental refresh, you filter by using Power Query date/time parameters.

RangeStart パラメーターと RangeEnd パラメーターRangeStart and RangeEnd parameters

増分更新の場合、大文字と小文字が区別される予約済みの名前 RangeStartRangeEnd で、Power Query の日付/時刻パラメーターを使用して、データセットがフィルター処理されます。For incremental refresh, datasets are filtered by using Power Query date/time parameters with the reserved, case-sensitive names RangeStart and RangeEnd. これらのパラメーターは、Power BI Desktop にインポートされるデータをフィルター処理するためだけでなく、Power BI サービスに発行された複数の範囲に動的にデータをパーティション分割するためにも使用されます。These parameters are used to filter the data imported into Power BI Desktop, and also to dynamically partition the data into ranges once published to the Power BI service. パラメーターの値は、サービスによってパーティションごとにフィルター処理のために置き換えられます。The parameter values are substituted by the service to filter for each partition. サービスのデータセットの設定で設定する必要はありません。There's no need to set them in dataset settings in the service. 発行すると、パラメーター値は Power BI サービスによって自動的にオーバーライドされます。Once published, the parameter values are overridden automatically by the Power BI service.

既定値でパラメーターを定義するには、Power Query エディターで [パラメーターの管理] を選択します。To define the parameters with default values, in the Power Query Editor, select Manage Parameters.

パラメーターの管理

パラメーターを定義した後は、列の [カスタム フィルター] メニュー オプションを選択してフィルターを適用することができます。With the parameters defined, you can then apply the filter by selecting the Custom Filter menu option for a column.

カスタム フィルター

列の値が RangeStart 以降で RangeEnd "より前" になるように、行がフィルター処理されることを確認します。Ensure rows are filtered where the column value is after or equal to RangeStart and before RangeEnd. 他のフィルターの組み合わせによっては、行が二重にカウントされる場合があります。Other filter combinations may result in double counting of rows.

行のフィルター

重要

RangeStart または RangeEnd のいずれか (両方ではなく) で、クエリに等しい (=) があることを確認します。Verify queries have an equal to (=) on either RangeStart or RangeEnd, but not both. 等しい (=) が両方のパラメーターに存在する場合、行が 2 つのパーティションの条件を満たし、その結果、モデル内にデータが重複する可能性があります。If the equal to (=) exists on both parameters, a row could satisfy the conditions for two partitions, which could lead to duplicate data in the model. たとえば、For example,
#"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] <= RangeEnd) は、データが重複する結果になる可能性があります。#"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] <= RangeEnd) could result in duplicate data.

ヒント

パラメーターのデータ型は日付/時刻でなければなりませんが、データ ソースの要件に合うように変換できます。While the data type of the parameters must be date/time, it's possible to convert them to match the requirements of the datasource. たとえば、次の Power Query 関数は、yyyymmdd という形式の整数代理キーと同じように日付/時刻値を変換します。これは、データ ウェアハウスの一般的な形式です。For example, the following Power Query function converts a date/time value to resemble an integer surrogate key of the form yyyymmdd, which is common for data warehouses. この関数は、フィルター手順から呼び出すことができます。The function can be called by the filter step.

(x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)

Power Query エディターで [適用して閉じる] を選びます。Select Close and Apply from the Power Query Editor. Power BI Desktop にデータセットのサブセットが存在する必要があります。You should have a subset of the dataset in Power BI Desktop.

日付列の更新をフィルター処理するFilter date column updates

Power BI サービスで日付列のフィルターを使用して、複数の範囲にデータを動的にパーティション分割します。The filter on the date column is used to dynamically partition the data into ranges in the Power BI service. 増分更新は、フィルター処理された日付列をソース システムでも更新するようには設計されていません。Incremental refresh isn't designed to support cases where the filtered date column is updated in the source system. 更新は、実際の更新ではなく、挿入と削除として解釈されます。An update is interpreted as an insertion and a deletion, not an actual update. 削除が増分の範囲でなく、履歴の範囲で発生する場合は、ピックアップされません。If the deletion occurs in the historical range and not the incremental range, it won't get picked up. この場合、パーティション キーの競合によって、データ更新エラーが発生する可能性があります。This can cause data refresh failures due to partition-key conflicts.

クエリの折りたたみQuery folding

更新操作のためにクエリが送信されるときに、パーティション フィルターがソース システムにプッシュされることが重要です。It's important the partition filters are pushed to the source system when queries are submitted for refresh operations. フィルターをプッシュ ダウンするには、データ ソースでクエリの折りたたみがサポートされている必要があります。To push filtering down means the datasource should support query folding. SQL クエリをサポートするほとんどのデータ ソースは、クエリの折りたたみをサポートしています。Most data sources that support SQL queries support query folding. しかし、フラット ファイル、BLOB、Web フィードなどのデータ ソースでは、通常サポートされません。However, data sources like flat files, blobs, and web feeds typically do not. フィルターがデータ ソース バックエンドでサポートされていない場合、プッシュ ダウンすることはできません。In cases where the filter is not supported by the datasource back-end, it cannot be pushed down. そのような場合、フィルターはマッシュアップ エンジンによってローカルで補われて適用されます。そのためには、データ ソースから完全なデータセットを取得する必要が生じる場合があります。In such cases, the mashup engine compensates and applies the filter locally, which may require retrieving the full dataset from the data source. これにより、増分更新が非常に低速になり、Power BI サービスまたはオンプレミスのデータ ゲートウェイ (使用されている場合) でプロセスがリソース不足になる可能性があります。This can cause incremental refresh to be very slow, and the process can run out of resources either in the Power BI service or in the on-premises data gateway if used.

各データ ソースでさまざまなレベルのクエリの折りたたみがサポートされている場合は、ソースのクエリにフィルター ロジックが含まれていることを確認するための検証を実行することをお勧めします。Given the various levels of query folding support for each datasource, it's recommended that verification is performed to ensure the filter logic is included in the source queries. これを簡単にするため、Power BI Desktop ではこの検証の自動実行が試みられます。To make this easier, Power BI Desktop attempts to perform this verification for you. 検証できない場合は、増分更新ポリシーを定義するときに、増分更新ダイアログで警告が表示されます。If unable to verify, a warning is displayed in the incremental refresh dialog when defining the incremental refresh policy. SQL、Oracle、Teradata などの SQL ベースのデータ ソースでは、この警告を利用できます。SQL based data sources such as SQL, Oracle, and Teradata can rely on this warning. 他のデータ ソースでは、クエリをトレースしないと検証できない場合があります。Other data sources may be unable to verify without tracing queries. Power BI Desktop で確認できない場合は、次の警告が表示されます。If Power BI Desktop is unable to confirm, the following warning is displayed. この警告が表示され、必要なクエリの折りたたみが行われていることを確認するには、クエリ診断機能を使用するか、ソース データベースが受け取ったクエリをトレースします。If you see this warning and want to check that the necessary query folding is occurring, you can use the Query Diagnostics feature, or trace queries received by the source database.

クエリの折りたたみ

更新ポリシーを定義するDefine the refresh policy

増分更新は、ライブ接続モデルを除く、テーブルのコンテキスト メニューで使用できます。Incremental refresh is available on the context menu for tables, except for Live Connection models.

更新ポリシー

[増分更新] ダイアログIncremental refresh dialog

[増分更新] ダイアログが表示されます。The incremental refresh dialog is displayed. トグルを使用してダイアログを有効にします。Use the toggle to enable the dialog.

更新の詳細

注意

テーブルに対する Power Query の式が予約された名前のパラメーターを参照していない場合は、トグルが無効になっています。If the Power Query expression for the table doesn't refer to the parameters with reserved names, the toggle is disabled.

ヘッダー テキストでは次のことが説明されています。The header text explains the following:

  • 更新ポリシーは Power BI Desktop で定義され、サービスでの更新操作によって適用されます。Refresh policies are defined in Power BI Desktop, and they are applied by refresh operations in the service.

  • Power BI サービスから増分更新ポリシーが含まれる PBIX ファイルをダウンロードできたとしても、それを Power BI Desktop で開くことはできません。If you're able to download the PBIX file containing an incremental-refresh policy from the Power BI service, it cannot be opened in Power BI Desktop. これは将来的にはサポートされる可能性がありますが、これらのデータセットは非常に大きくなる可能性があり、標準的なデスクトップ コンピューター上でダウンロードして開くことは実際的ではないということに注意してください。While this may be supported in the future, keep in mind these datasets can grow to be so large that they are impractical to download and open on a typical desktop computer.

更新範囲Refresh ranges

次の例では、丸 5 年間のデータと、現在の日付までの今年のデータを格納し、丸 10 日間のデータを増分更新するように、更新ポリシーを定義します。The following example defines a refresh policy to store data for five full calendar years plus data for the current year up to the current date, and incrementally refresh ten full days of data. 最初の更新操作では、履歴データを読み込みます。The first refresh operation loads historical data. その後の更新は増分的であり、(毎日実行するようにスケジュールされている場合は) 次の操作が実行されます。Subsequent refreshes are incremental, and (if scheduled to run daily) perform the following operations:

  • 新しい日のデータが追加されます。Add a new day of data.

  • 現在の日付までの丸 10 日分が更新されます。Refresh ten full days up to the current date.

  • 現在の日付より 5 年以上前のデータが削除されます。Remove calendar years that are older than five years prior to the current date. たとえば、今日の日付が 2019 年 1 月 1 日の場合は、2013 年が削除されます。For example, if the current date is January 1 2019, the year 2013 is removed.

Power BI サービスの最初の更新では、丸 5 年間のすべてをインポートするのに長くかかる可能性があります。The first refresh in the Power BI service may take longer to import all five full calendar years. その後の更新は、わずかな時間で完了する可能性があります。Subsequent refreshes may be finished in a fraction of the time.

更新範囲

現在の日付Current date

"現在の日付" とは、更新時のシステム日付です。The current date is based on the system date at the time of refresh. Power BI サービスのデータセットでスケジュールされている更新が有効になっている場合は、指定したタイム ゾーンが考慮され、現在の日付が決定されます。If scheduled refresh is enabled for the dataset in the Power BI service, the specified time zone will be taken into account when determining the current date. Power BI サービスにより手動で呼び出された更新でも、スケジュールされた更新でも、指定されている場合はタイム ゾーンが順守されます。Both manually invoked and scheduled refreshes through the Power BI service observe the time zone if available. たとえば、タイム ゾーンが指定された、太平洋標準時の午後 8 時 (米国およびカナダ) に発生する更新では、(それ以外の場合では翌日になる) GMT ではなく、太平洋標準時に基づいて現在の日付が決定されます。For example, a refresh that occurs at 8 PM Pacific Time (US and Canada) with time zone specified will determine the current date based on Pacific Time, not GMT (which would otherwise be the next day). Power BI サービスによって呼び出されていない更新操作 (TMSL 更新コマンドなど) では、スケジュールされた更新タイム ゾーンは考慮されませんRefresh operations not invoked through the Power BI service, such as the TMSL refresh command, will not consider the scheduled refresh time zone

タイム ゾーン

注意

これらの範囲の定義がすべて必要な場合は、後の発行操作にすぐに進むことができます。Definition of these ranges might be all you need, in which case you can go straight to the publishing step below. 追加のドロップダウンは高度な機能用です。The additional dropdowns are for advanced features.

高度なポリシーのオプションAdvanced policy options

データ変更の検出Detect data changes

10 日間の増分更新は、5 年間の完全更新より効率的です。Incremental refresh of ten days is more efficient than full refresh of five years. ただし、さらによくすることができます。However, it's possible to do even better. [データ変更の検出] チェック ボックスをオンにすると、識別に使用する日付/時刻列を選択して、データが変更された日だけを更新することができます。If you select the Detect data changes checkbox, you can select a date/time column used to identify and refresh only the days where the data has changed. この場合、そのような列がソース システムに存在するものとします。一般的にこれは監査目的です。This assumes such a column exists in the source system, which is typically for auditing purposes. RangeStart パラメーターや RangeEnd パラメーターでデータをパーティション分割するために使用される列と同じ列にはしないでください。This should not be the same column used to partition the data with the RangeStart/RangeEnd parameters. この列の最大値が、増分範囲の各期間に対して評価されます。The maximum value of this column is evaluated for each of the periods in the incremental range. 前回の更新以降変更されていない場合、その期間を更新する必要はありません。If it has not changed since the last refresh, there is no need to refresh the period. 例では、増分更新される日数がさらに 10 日から約 2 日に減るはずです。In the example, this could further reduce the days incrementally refreshed from ten to around two.

変更の検出

ヒント

現在の設計では、データの変更を検出する列は永続化されてメモリにキャッシュされる必要があります。The current design requires that the column to detect data changes is persisted and cached into memory. 次のいずれかの手法を使ってカーディナリティとメモリ消費量を減らすことを検討することが必要な場合があります。You may want to consider one of the following techniques to reduce cardinality and memory consumption.

おそらく Power Query 関数を使って、更新時にこの列の最大値のみを保持します。Persist only the maximum value of this column at time of refresh, perhaps using a Power Query function.

更新頻度の要件で許容されるレベルに有効桁数を減らします。Reduce the precision to a level that is acceptable given your refresh-frequency requirements.

XMLA エンドポイントを使用してデータの変更を検出するためのカスタム クエリを定義し、列の値の全体的な永続化を回避します。Define a custom query for detecting data changes using the XMLA endpoint and avoid persisting the column value altogether. 詳細については、後述する「データ変更の検出のためのカスタム クエリ」を参照してください。See custom queries for detect data changes below for more information.

完了期間のみを更新Only refresh complete periods

たとえば、毎朝午前 4 時に更新を実行するようスケジュールされているものとします。Let's say your refresh is scheduled to run at 4:00 AM every morning. この 4 時間の間にソース システムに追加されたデータは考慮しないようにする必要があります。If data appears in the source system during those 4 hours, you may not want to account for it. 石油ガス業界における 1 日あたりバレル数のような一部のビジネス メトリックでは、部分的な日には意味がありません。Some business metrics such as barrels per day in the oil and gas industry make no sense with partial days.

別の例としては、前月のデータが 12 日に承認されるような財務システムからのデータ更新があります。Another example is refreshing data from a financial system where data for the previous month is approved on the 12th calendar day of the month. 増分の範囲を 1 か月に設定し、12 日に実行するように更新をスケジュールします。You could set the incremental range to 1 month and schedule the refresh to run on the 12th day of the month. このオプションをオンにすると、たとえば 1 月のデータは 2 月 12 日に更新されます。With this option checked, it would for example refresh January data on February 12th.

完全な期間

注意

サービスの更新操作は、UTC 時刻で実行されます。Refresh operations in the service run under UTC time. これにより、有効な日付を決定して、完全な期間に影響を与えることができます。This can determine the effective date and affect complete periods. 更新操作の有効日をオーバーライドする機能を追加する予定です。We plan to add the ability to override the effective date for a refresh operation.

サービスへの公開Publish to the service

これで、モデルを更新できるようになりました。You can now refresh the model. 最初の更新は、履歴データをインポートするため長くかかる可能性があります。The first refresh may take longer to import the historical data. その後の更新は、増分更新を使用するため大幅に短縮できます。Subsequent refreshes can be much quicker because they use incremental refresh.

クエリのタイムアウトQuery timeouts

更新のトラブルシューティングに関する記事では、Power BI サービスでの更新操作がタイムアウトの対象になることが説明されています。The troubleshooting refresh article explains that refresh operations in the Power BI service are subject to timeouts. クエリは、データ ソースの既定のタイムアウトによっても制限できます。Queries can also be limited by the default timeout for the data source. ほとんどのリレーショナル ソースでは、M 式でタイムアウトをオーバーライドできます。Most relational sources allow overriding timeouts in the M expression. たとえば、次の例では、SQL Server のデータ アクセス関数を使って 2 時間に設定しています。For example, the expression below uses the SQL Server data-access function to set it to 2 hours. ポリシーの範囲によって定義されている各期間が、コマンド タイムアウトの設定に従ってクエリを送信します。Each period defined by the policy ranges submits a query observing the command timeout setting.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

増分更新に関する XMLA エンドポイントの利点XMLA endpoint benefits for incremental refresh

Premium 容量でのデータセットに対する XMLA エンドポイントを、読み取り、書き込み操作に対して有効にすることができます。これは、増分更新において大きな利点となります。The XMLA endpoint for datasets in a Premium capacity can be enabled for read-write operations, which can provide considerable benefits for incremental refresh. XMLA エンドポイントを介した更新操作は、1 日 48 回の更新に制限されるものではなく、さらにスケジュールされた更新のタイムアウトも適用されません。このことは、増分更新のシナリオで役に立ちます。Refresh operations through the XMLA endpoint are not limited to 48 refreshes per day, and the scheduled refresh timeout is not imposed, which can be useful in incremental refresh scenarios.

SQL Server Management Studio (SSMS) を使用した更新管理Refresh management with SQL Server Management Studio (SSMS)

XMLA エンドポイントの読み取り、書き込みが有効になっていると、増分更新ポリシーの適用によって生成されたパーティションを、SSMS を使用して表示および管理することができます。With XMLA endpoint read-write enabled, SSMS can be used to view and manage partitions generated by the application of incremental refresh policies. これにより、たとえば、増分範囲内にない特定の履歴パーティションを更新することで、日付を遡って更新を実行することができます。すべての履歴データを最新の情報に更新する必要はありません。This allows, for example, to refresh a specific historical partition not in the incremental range to perform a back-dated update without having to refresh all historical data. また、SSMS を使用すると、履歴パーティションを一括で増分追加または更新することで、非常に大規模なデータセットの履歴データを読み込むこともできます。You can also use SSMS to load historical data for very large datasets by incrementally adding/refreshing historical partitions in batches.

SSMS でのパーティション

増分更新の動作をオーバーライドするOverride incremental refresh behavior

SSMS では、テーブル モデルのスクリプト言語 (TMSL)表形式オブジェクト モデル (TOM) を使用して、増分更新を呼び出す方法をより細かく制御することもできます。With SSMS, you also have more control over how to invoke incremental refreshes from using the Tabular Model Scripting Language (TMSL) and the Tabular Object Model (TOM). たとえば、SSMS では、オブジェクト エクスプローラーでテーブルを右クリックしてから、 [テーブルの処理] メニュー オプションを選択します。For example, in SSMS, in Object Explorer, right-click a table and then select the Process Table menu option. 次に、 [スクリプト] ボタンをクリックして、TMSL 更新コマンドを生成します。Then click the Script button to generate a TMSL refresh command.

[テーブルの処理] ダイアログの [スクリプト] ボタン

次のパラメーターを TMSL 更新コマンドに挿入すれば、既定の増分更新動作をオーバーライドできます。The following parameters can be inserted into the TMSL refresh command to override the default incremental refresh behavior.

  • applyRefreshPolicy – テーブルで増分更新ポリシーが定義されている場合、そのポリシーを適用するかどうかは applyRefreshPolicy で決定されます。applyRefreshPolicy – If a table has an incremental refresh policy defined, applyRefreshPolicy will determine if the policy is applied or not. ポリシーが適用されていない場合、完全処理操作では、パーティション定義は変わらないままで、テーブル内のすべてのパーティションは完全に更新されます。If the policy is not applied, a process full operation will leave partition definitions unchanged and all partitions in the table will be fully refreshed. 既定値は true です。Default value is true.

  • effectiveDate – 増分更新ポリシーが適用されている場合は、履歴範囲と増分範囲に対するローリング ウィンドウ範囲を決定するために現在の日付を把握しておく必要があります。effectiveDate – If an incremental refresh policy is being applied, it needs to know the current date to determine rolling window ranges for the historical range and the incremental range. effectiveDate パラメーターを使用すると、現在の日付をオーバーライドすることができます。The effectiveDate parameter allows you to override the current date. これは、データを過去または将来の日付まで増分更新するテスト、デモ、およびビジネスのシナリオにおいて役立ちます (たとえば、将来の予算)。This is useful for testing, demos, and business scenarios where data is incrementally refreshed up to a date in the past or the future (for example, budgets in the future). 既定値は現在の日付です。The default value is the current date.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

TMSL での既定の増分更新動作の上書きの詳細については、「Refresh コマンド」を参照してください。To learn more about overriding default incremental refresh behavior with TMSL, see Refresh command.

データ変更の検出のためのカスタム クエリCustom queries for detect data changes

TMSL または TOM を使用して、検出されたデータ変更動作をオーバーライドできます。You can use TMSL and/or TOM to override the detected data changes behavior. これを使用すれば、メモリ内キャッシュでの最終更新列の永続化を回避できるだけでなく、更新が必要なパーティションのみにフラグを付ける目的で ETL プロセスによって構成または命令テーブルが準備されるというシナリオを有効にすることができます。Not only can this be used to avoid persisting the last-update column in the in-memory cache, it can enable scenarios where a configuration/instruction table is prepared by ETL processes for the purpose of flagging only the partitions that need to be refreshed. これにより、データ更新がどれほど前に行われたかに関係なく、必要な期間についてのみ更新されるという、より効率的な増分更新プロセスを作成できます。This can create a more efficient incremental refresh process where only the required periods are refreshed, no matter how long ago data updates took place.

pollingExpression は、他の M クエリの簡易な M 式または名前とすることを目的としています。The pollingExpression is intended to be a lightweight M expression or name of another M query. スカラー値が返される必要があり、パーティションごとに実行されます。It must return a scalar value and will be executed for each partition. 返された値が、増分更新を最後に実行したときとは異なる場合、パーティションには完全処理のフラグが設定されます。If the value returned is different to what it was the last time an incremental refresh occurred, the partition is flagged for full processing.

次の例では、日付を遡った変更について履歴の範囲内の 120 か月すべてが対象とされています。The following example covers all 120 months in the historical range for backdated changes. 10 年ではなく 120 か月を指定した場合、データ圧縮はそれほど効率的ではないかもしれませんが、履歴年の 1 年全体を最新の情報に更新する必要はなくなります (それを行うとしたら、日付を遡った変更には 1 か月で十分である場合によりコストがかかります)。Specifying 120 months instead of 10 years means data compression may not be quite as efficient, but avoids having to refresh a whole historical year, which would be more expensive when a month would suffice for a backdated change.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

メタデータのみの配置Metadata-only deployment

新しいバージョンの PBIX ファイルを Power BI Desktop から Power BI Premium 内のワークスペースに発行すると、同じ名前を持つデータセットが既に存在している場合、既存のデータセットを置き換えるように求められます。When publishing a new version of a PBIX file from Power BI Desktop to a workspace in Power BI Premium, if a dataset with the same name already exists, you are prompted to replace the existing dataset.

データセットの置換を求めるプロンプト

場合によっては、データセットを置換したくないこともあります (特に増分更新で)。In some cases you may not want to replace the dataset, especially with incremental refresh. Power BI Desktop 内のデータセットは、サービス内のものより大幅に小さくなる可能性があります。The dataset in Power BI Desktop could be much smaller than the one in the service. サービス内のデータセットに増分更新ポリシーが適用されている場合、データセットが置換されると、数年分の履歴データが失われる可能性があります。If the dataset in the service has an incremental refresh policy applied, it may have several years of historical data that will be lost if the dataset is replaced. すべての履歴データを最新の情報に更新すると、時間がかかり、ユーザーに対してシステムのダウンタイムが発生する可能性があります。Refreshing all the historical data could take hours and result in system downtime for users.

代わりに、メタデータのみの展開を実行することをお勧めします。Instead, it's better to perform a metadata-only deployment. そうすれば、履歴データを失うことなく新しいオブジェクトを展開することができます。This allows deployment of new objects without losing the historical data. たとえば、いくつかのメジャーを追加した場合、データを最新の情報に更新する必要なく新しいメジャーのみを展開できるので、時間を大幅に節約できます。For example, if you have added a few measures, you can deploy only the new measures without needing to refresh the data, saving a lot of time.

読み取り、書き込みに対して構成した場合、XMLA エンドポイントは、それを行うツールとの互換性を提供します。When configured for read-write, the XMLA endpoint provides compatibility with tools that make this happen. たとえば、ALM Toolkit は Power BI データセット用のスキーマ差分ツールであり、これを使用すればメタデータの展開のみを実行することができます。For example, the ALM Toolkit is a schema diff tool for Power BI datasets and can be used to perform deployment of metadata only.

Analysis Services の Git リポジトリから最新バージョンの ALM Toolkit をダウンロードしてインストールします。Download and install the latest version of the ALM Toolkit from the Analysis Services Git repo. ドキュメントのリンクと、サポートの可否に関する情報には、[ヘルプ] リボンからアクセスできます。Documentation links and information on supportability are available via the Help ribbon. メタデータのみの展開を実行するには、比較を実行し、実行中の Power BI Desktop インスタンスをソースとして、サービス内の既存のデータセットをターゲットとして選択します。To perform a metadata only deployment, perform a comparison and select the running Power BI Desktop instance as the source, and the existing dataset in the service as the target. 表示される相違点を検討し、テーブルと増分更新パーティションの更新をスキップするか、[オプション] ダイアログを使用してテーブルの更新のためにパーティションを維持します。Consider the differences displayed and skip the update of the table with incremental refresh partitions, or use the Options dialog to retain partitions for table updates. 選択内容を検証してターゲット モデルの整合性を確保してから、更新を行います。Validate the selection to ensure the integrity of the target model and then update.

ALM Toolkit

関連項目See also

XMLA エンドポイントを使用したデータセット接続 Dataset connectivity with the XMLA endpoint
更新に関するトラブルシューティング シナリオTroubleshooting refresh scenarios