語意模型的累加式重新整理和實時數據

  • 發行項

累加式重新整理會為經常載入新數據和更新數據的語意模型數據表提供自動化的數據分割建立和管理，藉此擴充排程的重新整理作業。 對於大多數模型，一或多個數據表包含經常變更且可能會以指數方式成長的交易數據，例如關係型或星型資料庫架構中的事實數據表。 累加式重新整理原則來分割數據表、只重新整理最新的匯入數據分割，以及選擇性地針對實時數據使用另一個 DirectQuery 分割區，可以大幅減少必須重新整理的數據量。 同時，此原則可確保數據源的最新變更會包含在查詢結果中。

使用累加式重新整理與即時資料：

  • 需要較少的重新整理週期，以便快速變更的數據。 DirectQuery 模式會在處理查詢時取得最新的數據更新，而不需要高重新整理頻率。
  • 重新整理速度較快。 只需要重新整理已變更的最新數據。
  • 重新整理更可靠。 不需要長時間執行與揮發性數據源的連線。 源數據查詢的執行速度較快，減少網路問題干擾的可能性。
  • 減少資源耗用量。 重新整理的數據較少，可減少PowerBI和數據源系統中記憶體和其他資源的整體耗用量。
  • 已啟用大型語意模型。 具有可能數十億個數據列的語意模型可以成長，而不需要使用每個重新整理作業完全重新整理整個模型。
  • 安裝程序很簡單。 累加式重新 整理原則 只會在Power BI Desktop中定義一些工作。 當 Power BI Desktop 發佈報表時，服務會在每次重新整理時自動套用這些原則。

當您將Power BI Desktop 模型發佈至服務時，新模型中的每個數據表都有單一分割區。 該單一分割區包含該數據表的所有數據列。 如果數據表很大，假設有數千萬個數據列或更多數據列，該數據表的重新整理可能需要很長的時間，並耗用過多的資源。

透過累加式重新整理，服務會動態分割，並將需要經常重新整理的數據與可以較不頻繁重新整理的數據分開。 數據表數據會使用 Power Query 日期/時間參數搭配保留、區分大小寫的名稱 RangeStart 和 RangeEnd來篩選。 當您在Power BI Desktop 中設定累加式重新整理時，這些參數只會篩選載入模型的少量數據。 當 Power BI Desktop 將報表發佈至 Power BI 服務 時，服務會建立累加式重新整理和歷程記錄數據分割，並根據累加式重新整理原則設定選擇性地建立即時 DirectQuery 分割區。 接著，服務會覆寫參數值，根據每個數據列的日期/時間值來篩選和查詢每個數據分割的數據。

每次後續重新整理時，查詢篩選只會傳回參數動態定義的重新整理期間內的數據列。 重新整理期間內具有日期/時間的數據列會重新整理。 具有日期/時間的數據列不再在重新整理期間內，然後成為歷程記錄期間的一部分，不會重新整理。 如果累加式重新整理原則中包含即時 DirectQuery 分割區，也會更新其篩選，以便挑選重新整理期間之後發生的任何變更。 重新整理和歷程記錄期間都會向前復原。 建立新的累加式重新整理分割區時，重新整理期間不再重新整理分割區會變成歷程記錄數據分割。 經過一段時間后，記錄分割區在合併在一起時變得不那麼細微。 當原則所定義的歷程記錄數據分割不再處於歷史期間時，就會完全從模型中移除。 此行為稱為 滾動視窗模式。

Graphic representing a rolling window pattern.

累加式重新整理的美感在於服務會根據您定義的累加式重新整理原則為您處理所有更新。 事實上，從中建立的進程和分割區不會顯示在服務中。 在大部分情況下，定義完善的累加式重新整理原則是大幅改善模型重新整理效能所需的一切。 不過，只有 進階版 容量中的模型才支持即時 DirectQuery 分割區。 Power BI 進階版 也可透過 XML for Analysis （XMLA） 端點啟用更進階的數據分割和重新整理案例。

需求

下一節說明支援的方案和數據源。

支援的方案

Power BI 進階版 支援累加式重新整理，進階版 每個使用者、Power BI Pro 和 Power BI Embedded 模型。

只有 Power BI 進階版、每位使用者 進階版 和 Power BI Embedded 模型才支援使用 DirectQuery 實時取得最新數據。

支援的資料來源

累加式重新整理和實時數據最適合結構化的關係型數據源，例如 SQL 資料庫 和 Azure Synapse，但也適用於其他數據源。 在任何情況下，您的數據源都必須支援下列專案：

日期篩選 - 數據源必須支援一些機制，以依日期篩選數據。 對於關係型來源，這通常是目標數據表上日期/時間或整數數據類型的日期數據行。 RangeStart 和 RangeEnd 參數，必須是日期/時間數據類型，會根據日期數據行篩選數據表數據。 針對格式為整數代理鍵的 yyyymmdd日期數據行，您可以建立函式，以轉換 RangeStart 和 RangeEnd 參數中的日期/時間值，以符合日期數據行的整數代理索引鍵。 若要深入瞭解，請參閱 設定累加式重新整理 - 將 DateTime 轉換為整數。

對於其他數據源，RangeStart 和 RangeEnd 參數必須以某種方式傳遞至數據源，才能進行篩選。 對於依日期組織檔案和資料夾的檔案型數據源，RangeStart 和 RangeEnd 參數可用來篩選檔案和資料夾，以選取要載入的檔案。 針對 Web 型數據源，RangeStart 和 RangeEnd 參數可以整合到 HTTP 要求中。 例如，下列查詢可用於從 AppInsights 實例累加式重新整理追蹤：

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

設定累加式重新整理時，會根據 RangeStart 和 RangeEnd 參數執行包含日期/時間篩選的 Power Query 運算式，以針對數據源執行。 如果在初始來源查詢之後的查詢步驟中指定篩選條件，請務必將初始查詢步驟與步驟參考 RangeStart 和 RangeEnd 參數結合在一起。 例如，在下列查詢表達式中， Table.SelectRows 將會折疊，因為它會緊接著 Sql.Database 步驟，而 SQL Server 支援折疊：

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

不需要 最終查詢 支援折疊。 例如，在下列表達式中，我們使用非折疊的 NativeQuery，但將 RangeStart 和 RangeEnd 參數直接整合到 SQL 中：

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

不過，如果累加式重新整理原則包含使用 DirectQuery 取得實時數據，就無法使用非折疊轉換。 如果是不含實時數據的純匯入模式原則，查詢混搭引擎可能會補償並套用本機篩選，這需要從數據源擷取數據表的所有數據列。 這可能會導致累加式重新整理變慢，而且程式可能會用盡 Power BI 服務 或內部部署數據閘道中的資源，有效地破壞累加式重新整理的目的。

因為對不同數據類型數據源的查詢折疊支援不同，因此應該執行驗證，以確保針對數據源執行的查詢中包含篩選邏輯。 在大部分情況下，Power BI Desktop 會在定義累加式重新整理原則時，嘗試為您執行此驗證。 對於 sql 型數據源，例如 SQL 資料庫、Azure Synapse、Oracle 和 Teradata，此驗證是可靠的。 不過，若未追蹤查詢，其他數據源可能無法驗證。 如果 Power BI Desktop 無法確認查詢，[累加式重新整理原則設定] 對話框中會顯示警告。

Screenshot of the query folding warning

如果您看到這個警告並想要確認發生必要的查詢折疊，請使用Power Query Diagnostics功能，或使用資料源支援的工具來追蹤查詢，例如SQL Profiler。 如果查詢折疊未發生，請確認篩選邏輯包含在要傳遞至數據源的查詢中。 如果沒有，查詢可能會包含防止折疊的轉換。

設定累加式重新整理解決方案之前，請務必徹底閱讀並瞭解 Power BI Desktop 中的查詢折疊指引和 Power Query查詢折疊。 這些文章可協助您判斷數據源和查詢是否支持查詢折疊。

單一數據源

當您使用Power BI Desktop 設定累加式重新整理和實時資料時，或透過XMLA端點使用表格式模型腳本語言 （TMSL） 或表格式物件模型 （TOM） 設定進階解決方案時， 無論是匯入或 DirectQuery，所有分割區都必須從單一來源查詢數據。

其他數據源類型

藉由使用更多自定義查詢函式和查詢邏輯，累加式重新整理可以與其他類型的數據源搭配使用，如果根據篩選RangeStartRangeEnd可以傳入單一查詢，例如儲存在資料夾中的 Excel 活頁簿檔案、SharePoint 中的檔案和 RSS 摘要。 請記住，這些是需要進一步自定義和測試的進階案例，而不需要在此描述的內容。 請務必查看本文稍後的社群一節，以取得有關如何針對唯一案例使用累加式重新整理的詳細信息的建議。

時間限制

不論累加式重新整理，Power BI Pro 模型都有兩個小時的重新整理時間限制，且不支援使用 DirectQuery 取得實時數據。 對於容量 進階版 的模型，時間限製為5小時。 重新整理作業需要大量進程和記憶體。 完整重新整理作業可以單獨使用模型所需的記憶體數量加倍，因為服務會在記憶體中維護模型的快照集，直到重新整理作業完成為止。 重新整理作業也可能需要大量處理，耗用大量可用的CPU資源。 重新整理作業也必須依賴數據源的動態連線，以及這些數據源系統快速傳回查詢輸出的能力。 時間限制是限制可用資源過度耗用量的保障。

注意

透過 進階版 容量，透過 XMLA 端點執行的重新整理作業沒有時間限制。 若要深入瞭解，請參閱 使用 XMLA 端點進行進階累加式重新整理。

因為累加式重新整理會將模型中數據分割層級的重新整理作業優化，因此可以大幅降低資源耗用量。 同時，即使使用累加式重新整理，除非它們經過 XMLA 端點，否則重新整理作業會受到相同的兩小時和五小時限制所系結。 有效的累加式重新整理原則不僅可減少使用重新整理作業處理的數據量，也會減少模型中儲存的不必要的歷程記錄數據量。

查詢也可以受限於數據源的預設時間限制。 大部分的關係型數據源都允許覆寫 Power Query M 運算式中的時間限制。 例如，下列表達式會使用 SQL Server 數據存取函 式，將 CommandTimeout 設定為 2 小時。 原則範圍所定義的每個期間都會提交觀察命令逾時設定的查詢：

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"

對於 進階版 容量中可能包含數十億個數據列的非常大模型，可以啟動初始重新整理作業。 啟動載入可讓服務建立模型的數據表和數據分割物件，但不會將數據載入並處理到任何分割區。 藉由使用 SQL Server Management Studio，您可以將分割區設定為個別、循序或平行處理，以減少單一查詢中傳回的數據量，同時略過五小時的時間限制。 若要深入瞭解，請參閱 進階累加式重新整理 - 防止初始完整重新整理逾時。

目前日期與時間

目前的日期和時間是以重新整理時的系統日期為基礎。 如果服務中的模型已啟用排程的重新整理，則判斷目前日期和時間時，會考慮指定的時區。 如果可用，個別和排程的重新整理都會透過服務觀察時區。 例如，在太平洋時間（美國和加拿大）下午 8：00 發生且指定時區的重新整理會根據太平洋時間而非國際標準時間（UTC）來決定目前日期和時間，這會在下一天傳回。 不會透過 Power BI 服務 叫用的重新整理作業，例如TMSL重新整理命令，請勿考慮排程的重新整理時區。

Screenshot of Scheduled refresh dialog showing the Time zone input field

設定累加式重新整理和實時數據

本節說明設定累加式重新整理和實時數據的重要概念。 當您準備好取得更詳細的逐步指示時，請參閱 設定語意模型的累加式重新整理和實時數據。

設定累加式重新整理是在Power BI Desktop中完成。 對於大多數模型，只需要幾個工作。 但請謹記下列重點：

  • 發佈至 Power BI 服務 之後，您無法從 Power BI Desktop 再次發佈相同的模型。 重新發佈會移除模型中已有的任何現有數據分割和數據。 如果您要發佈至 進階版 容量，可以使用開放原始碼 ALM 工具組，或使用TMSL等工具進行後續元數據架構變更。 若要深入瞭解，請參閱 進階累加式重新整理 - 僅限元數據的部署。
  • 發佈至 Power BI 服務 之後，您無法將模型下載回 Power BI Desktop 作為 .pbix。 因為服務中的模型可能會成長這麼大，所以在一般桌面計算機上下載並開啟模型是不切實際的。
  • 使用 DirectQuery 取得實時資料時，您無法將模型發佈至非 進階版 工作區。 只有 Power BI 進階版 才支援使用即時數據的累加式重新整理。

建立參數

若要在 Power BI Desktop 中設定累加式重新整理，您必須先使用保留、區分大小寫的名稱 RangeStart 和 RangeEnd建立兩個 Power Query 日期/時間參數。 這些參數定義於 Power Query 編輯器 的 [管理參數] 對話框中，一開始是用來篩選載入 Power BI Desktop 模型數據表的數據，只包含那些在該期間內具有日期/時間的數據列。 RangeStart 代表最舊或最早的日期/時間，代表 RangeEnd 最新的或最新的日期/時間。 將模型發佈至服務之後， RangeStart 服務 RangeEnd 會自動覆寫，以查詢累加式重新整理原則設定中指定的重新整理期間所定義的數據。

例如，FactInternetSales 數據源數據表每天平均 10,000 個新數據列。 若要限制最初載入 Power BI Desktop 模型中的數據列數目，請在 和 RangeEnd之間RangeStart指定兩天的期間。

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

篩選資料

RangeStart定義 和 RangeEnd 參數後，您會在資料表的日期數據行上套用自定義日期篩選。 當您選取 [套用] 時，您套用的篩選會選取載入模型的數據子集。

Screenshot of column context menu with Custom Filter selected

透過 FactInternetSales 範例，根據參數建立篩選並套用步驟之後，會將兩天的數據（大約 20,000 個數據列）載入模型。

定義原則

套用篩選並載入模型的數據子集之後，您可以定義數據表的累加式重新整理原則。 將模型發佈至服務之後，服務會使用此原則來建立及管理數據表分割，並執行重新整理作業。 若要定義原則，您可以使用 [ 累加式重新整理和實時數據] 對話方塊來指定必要和選擇性的設定。

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

Table

[選取數據表] 列表框預設為您在 [資料] 檢視中選取的數據表。 使用滑桿啟用數據表的累加式重新整理。 如果數據表的 Power Query 運算式不包含以 RangeStart 和 RangeEnd 參數為基礎的篩選，則無法使用切換。

必要設定

從 重新整理日期 之前開始的封存數據設定會決定在模型中包含日期/時間的數據列，以及目前不完整歷程記錄期間的數據列，以及截至目前日期和時間的重新整理期間中的數據列。

例如，如果您指定五 年，數據表會將過去五年的歷史數據儲存在年份數據分割中。 數據表也會包含目前年份的數據列，以季、月或日分割，最多包含重新整理期間。

針對 進階版 容量中的模型，備份的歷史分割區可以在此設定所決定的數據粒度上選擇性地重新整理。 若要深入瞭解，請參閱 進階累加式重新整理 - 數據分割。

從 重新整理日期 之前開始的累加式重新整理資料設定會決定累加式重新整理期間，其中具有該期間中日期/時間的所有數據列都包含在重新整理分割區中，並透過每個重新整理作業重新整理。

例如，如果您指定三天的重新整理期間，使用每個重新整理作業，服務會 RangeStart 覆寫 和 RangeEnd 參數，以在三天內建立具有日期/時間的數據列查詢，開頭和結束時間取決於目前的日期和時間。 過去三天內具有日期/時間的數據列，最多會重新整理目前的重新整理作業時間。 使用這種類型的原則，您可以預期服務中的 FactInternetSales 模型數據表，其平均每天有 10,000 個新數據列，每次重新整理作業大約 30,000 個數據列。

指定期間，只包含確保正確報告所需的最小數據列數目。 當您為多個數據表定義原則時， RangeStart 即使為每個數據表定義不同的存放區和重新整理期間，也必須使用相同的 和 RangeEnd 參數。

選擇性設定

使用 DirectQuery 即時取得最新資料 （僅限 進階版） 設定可讓您使用 DirectQuery，從數據源的選取數據表擷取最新的變更，超過累加式重新整理週期。 所有日期/時間晚於累加式重新整理期間的數據列都會包含在 DirectQuery 數據分割中，並使用每個模型查詢從數據源擷取。

例如，如果啟用此設定，使用每個重新整理作業，服務仍會覆寫 RangeStart 和 RangeEnd 參數，以在重新整理期間之後建立具有日期/時間之數據列的查詢，且開始相依於目前的日期和時間。 同時包含目前重新整理作業時間之後具有日期/時間的數據列。 使用這種類型的原則，服務中的 FactInternetSales 模型數據表會包含最新的數據更新。

[ 僅重新整理完成天數 ] 設定可確保整日的所有數據列都包含在重新整理作業中。 除非您使用 DirectQuery 實時啟用 [取得最新數據] 設定 進階版，否則此設定是選擇性的。 例如，假設您的重新整理排定於每天早上 4：00 執行。 如果在午夜到上午 4：00 這四個小時的數據源數據表中出現新的數據列，您就不想考慮這些數據列。 石油和天然氣行業每日桶等一些商業計量對部分日子沒有意義。 另一個範例是從財務系統重新整理數據，其中上個月的數據會在當月第十二個日曆日獲得核准。 您可以將重新整理期間設定為一個月，並將重新整理排程在當月第十二天執行。 選取此選項后，例如，在2月12日重新整理1月數據。

請記住，除非針對非UTC時區設定排程的重新整理，否則服務中的重新整理作業會在UTC時間下執行，以決定有效日期和完整期間。

[ 偵測資料變更] 設定可啟用更選擇性的重新整理。 您可以選取用來識別及重新整理資料已變更的日期/時間數據行。 此設定假設這類數據行存在於數據源中，這通常是用於稽核目的。 此數據行不應該是用來使用 和 RangeEnd 參數分割數據的相同數據RangeStart行。 此數據行的最大值會針對累加範圍中的每個期間進行評估。 如果自上次重新整理之後尚未變更，就不需要重新整理期間，這可能會進一步將累加式重新整理的天數從三個減少為一個。

目前的設計要求數據行偵測數據變更會保存並快取到記憶體中。 下列技術可用來減少基數和記憶體耗用量：

  • 重新整理時只保存數據行的最大值，或許是使用 Power Query 函式。
  • 根據您的重新整理頻率需求，將精確度降低到可接受的層級。
  • 定義自訂查詢，以使用 XMLA 端點來偵測數據變更，並避免完全保存數據行值。

在某些情況下，可以進一步增強啟用 [ 偵測數據變更*] 選項。 例如，您可能想要避免在記憶體內部快取中保存上次更新數據行，或啟用擷取/指令數據表是透過擷取-轉換載入 （ETL） 行程準備的案例，以便只標記需要重新整理的數據分割。 在這類情況下，針對 進階版 容量，請使用TMSL和/或 TOM 來覆寫偵測數據變更行為。 若要深入瞭解，請參閱 進階累加式重新整理 - 用於偵測數據變更的自定義查詢。

發佈

設定累加式重新整理原則之後，您會將模型發佈至服務。 發佈完成時，您可以在模型上執行初始重新整理作業。

注意

具有累加式重新整理原則以即時取得 DirectQuery 最新數據的語意模型，只能發佈至 進階版 工作區。

對於發佈至指派給 進階版 容量工作區的模型，如果您認為模型會成長超過 1 GB，您可以改善重新整理作業效能，並藉由啟用大型模型儲存格式，在服務中執行第一次重新整理作業之前，確保模型不會超過大小限制。 若要深入瞭解，請參閱 Power BI 中的大型模型 進階版。

重要

Power BI Desktop 將模型發佈至服務之後，您無法將該 .pbix 下載回來。

Refresh

發佈至服務之後，您會在模型上執行初始重新整理作業。 此重新整理應該是個別的 （手動） 重新整理，以便您可以監視進度。 初始重新整理作業可能需要相當長的時間才能完成。 必須建立數據分割、載入歷程記錄數據、建立或重建關聯性和階層等物件，以及重新計算的計算物件。

後續的重新整理作業，無論是個別或排程，都快得多，因為只會重新整理累加式重新整理數據分割。 其他處理作業仍必須發生，例如合併分割區和重新計算，但通常需要比初始重新整理少得多的時間。

自動報表重新整理

對於使用具有累加式重新整理原則的模型，以使用 DirectQuery 即時取得最新數據的報告，最好是以固定間隔或根據變更偵測來啟用自動頁面重新整理，讓報表包含最新數據而不延遲。 若要深入瞭解，請參閱 Power BI中的自動頁面重新整理。

進階累加式重新整理

如果您的模型位於已啟用 XMLA 端點的 進階版 容量上，則可以針對進階案例進一步擴充累加式重新整理。 例如，您可以使用 SQL Server Management Studio 來檢視和管理分割區、啟動初始重新整理作業，或重新整理已備份的歷程記錄數據分割。 若要深入瞭解，請參閱 使用 XMLA 端點進行進階累加式重新整理。

社群

Power BI 具有充滿活力的社群，其中 MVP、BI 專業人員和同儕共用討論群組、影片、部落格等的專業知識。 瞭解累加式重新整理時，請參閱下列資源：

相關內容