自動彙總

2025-03-25

自動彙總使用最先進的機器學習 (ML)，持續將 DirectQuery 語意模型最佳化，以獲得最高的報表查詢效能。自動彙總建置於現有的使用者定義彙總基礎結構之上，此基礎結構最早是隨著適用於 Power BI 的複合模型引進。與使用者定義的彙總不同，自動彙總不需要大量的資料模型化和查詢最佳化技能來設定和維護。自動彙總既可自我訓練，也可自我最佳化。其讓任何技能層級的模型擁有者都能提升查詢效能，為大型模型提供更快速的報表視覺效果。

透過自動彙總：

報表視覺效果速度更快：報表查詢的最佳百分比會由自動維護的記憶體內部彙總快取 (而不是後端資料來源系統) 傳回。記憶體內部快取未傳回的異常查詢會透過 DirectQuery 方法直接傳遞至資料來源。
平衡的架構：相較於單純的 DirectQuery 模式，大多數的查詢結果都會由 Power BI 查詢引擎和記憶體內部彙總快取傳回。尖峰報告期間資料來源系統上的查詢處理負載可大幅降低，這表示資料來源後端的可擴縮性會提高。
輕鬆設定：模型擁有者可以啟用自動匯整訓練，並針對模型排程一次或多次重新整理。透過第一次訓練和重新整理，自動彙總功能會開始構建一個彙總架構和最佳彙總。系統會隨著時間自動進行自我調整。
微調：透過模型設定中簡單的直覺式使用者介面，您可以針對從記憶體內部彙總快取傳回的不同百分比查詢來推估效能提升，並進行調整以獲得更大收益。單一滑動桿控制項可協助您輕鬆地微調環境。

需求

支援的方案

Power BI Premium Per Capacity、Premium Per User 及 Power BI Embedded 模型支援自動彙總。

支援的資料來源

下列資料來源支援自動彙總：

Azure SQL Database
Azure Synapse 專用 SQL 集區
SQL Server 2019 或更新版本
Google BigQuery
雪花
Databricks
Amazon Redshift

支援的模式

DirectQuery 模式模型支援自動彙總。支援具有匯入資料表和 DirectQuery 連線的複合模型。只有 DirectQuery 連線支援自動彙總。

權限

若要啟用並設定自動彙總，您必須是模型擁有者。工作區管理員可以作為擁有者接手，以設定自動彙總。

設定自動彙總

自動彙總會在模型設定中設定。設定很簡單：啟用自動彙總訓練，並排程一或多次重新整理。為模型設定自動彙總之前，務必完整閱讀此文章。這可讓您充分了解自動彙總的運作方式，並協助您判斷自動彙總是否適合您的環境。當您準備好如何啟用自動彙總設定、設定重新整理排程，以及微調以適應您的環境的逐步指示時，請參閱設定自動彙總。

福利

透過 DirectQuery，每次模型使用者開啟報表或與報表視覺效果互動時，Data Analysis Expressions (DAX) 查詢都會傳遞至查詢引擎，然後以 SQL 查詢的形式傳遞至後端資料來源。資料來源必須針對每個查詢計算並傳回結果。相較於儲存在記憶體內部的匯入模式模型，DirectQuery 資料來源來回行程可能是時間和流程密集型的，這通常會導致報表視覺效果中的查詢回應時間變慢。

針對 DirectQuery 模型啟用時，自動彙總可藉由避免資料來源查詢來回行程來提升報表查詢效能。預先彙總的查詢結果會由記憶體內部彙總快取自動傳回，而不是傳送至資料來源並由其傳回。記憶體內部彙總快取中預先彙總的資料量，只是資料來源上事實資料表和詳細資料表中所保留資料量的一小部分。結果不僅能提升報表查詢效能，也可降低後端資料來源系統上的負載。透過自動彙總，只有一小部分報表和臨機查詢需要的彙總不在記憶體快取中，才會被傳遞到後端資料來源，這就像單純使用 DirectQuery 模式一樣。

Diagram that shows automatic aggregation processing. 此圖顯示自動彙總處理。

自動查詢和彙總管理

雖然自動彙總不需要建立使用者定義的彙總資料表，並大幅簡化實作預先彙總的資料解決方案，但更深入熟悉基礎流程和相依性有助於了解自動彙總的運作方式。 Power BI 依賴下列項目來建立並管理自動彙總。

查詢記錄

Power BI 會在查詢記錄中追蹤模型和使用者報表查詢。針對每個模型，Power BI 會維護七天的查詢記錄資料。每天向前復原查詢記錄資料。查詢記錄是安全的，且無法透過 XMLA 端點來向使用者顯示。

訓練作業

根據您選擇的頻率（天或週），在首次排定的模型刷新作業中，Power BI 會首先啟動訓練操作來評估查詢日誌，以確保記憶體中彙總快取的彙總能夠適應不斷變化的查詢模式。記憶體內聚合資料表會進行建立、更新或刪除，並將特殊查詢傳送至資料來源，以確定納入快取的聚合。計算的聚合資料不會在訓練期間載入到內存快取中，而是在隨後的更新操作中載入。

例如，如果您選擇天頻率，且排程在上午 4:00、上午 9:00、下午 2:00 及下午 7:00 進行重新整理，則只有每天上午 4:00 的重新整理將同時包含訓練作業及重新整理作業。當天上午 9:00、下午 2:00 及下午 7:00 的後續排程重新整理作業均為「僅更新作業」，其會更新快取中現有的彙總資料。

Diagram of the training and refresh operation. 此圖顯示訓練和重新整理作業。

雖然訓練作業會從查詢記錄評估過去的查詢，但結果夠準確，可確保會涵蓋未來的查詢。但是，不保證記憶體內部彙總快取將會傳回未來的查詢，因為那些新查詢可能與從查詢記錄衍生的查詢不同。記憶體內部彙總快取未傳回的查詢會使用 DirectQuery 傳遞至資料來源。根據那些新查詢的頻率和排名，這些查詢的彙總可能在下一次的訓練作業中被納入內存中的彙總快取中。

訓練作業有 60 分鐘的時間限制。如果訓練無法在時間限制內處理整個查詢記錄，就會在模型重新整理記錄中記錄通知，並在下次啟動時繼續訓練。訓練週期會在處理整個查詢記錄時完成並取代現有的自動彙總。

重新整理作業

如前所述，當訓練作業在您所選頻率的第一次排程重新整理中完成後，Power BI 會執行重新整理作業，以查詢並載入新的和更新的彙總資料到記憶體內的彙總快取，並移除任何不再足夠高排名的彙總 (由訓練演算法決定)。針對您所選「天」或「週」頻率的所有後續重新整理均為僅重新整理作業，其會查詢資料來源，以更新快取中現有的彙總資料。透過使用先前的範例，當天上午 9:00、下午 2:00 及下午 7:00 排程的重新整理均為僅重新整理作業。

Diagram showing refresh only operations and refresh queries related to the data source. 此圖顯示僅重新整理作業及與資料來源相關的重新整理查詢。

定期安排在一天（或一週）中多次進行的重新整理，確保快取中的彙總資料更加符合後端資料來源的最新資料。透過模型設定，您每天最多可排程 48 次重新整理，以確保彙總快取傳回的報表查詢會根據後端資料來源的最新重新整理資料取得結果。

警告

對於 Power BI 服務及資料來源系統而言，訓練與重新整理作業都是流程和資源密集型作業。提高使用彙總的查詢百分比，意味著必須在訓練和重新整理作業期間，從資料來源查詢並計算出更多彙總，增加過度使用系統資源的可能性，而且可能導致逾時。若要了解更多內容，請參閱精細調整。

隨需訓練

如先前所述，訓練週期可能不會在單一資料重新整理週期的時間限制內完成。如果您不想等到下一個包含訓練的排程重新整理週期，您也可以在模型設定中選擇 [立即訓練並重新整理]，以需求觸發自動化的彙總訓練。使用「立即訓練並重新整理」會同時觸發訓練作業和重新整理作業。檢查模型重新整理記錄，以查看目前的作業是否已完成，然後再執行另一個隨需訓練和重新整理作業 (如有必要)。

重新整理記錄

每個重新整理作業都記錄在模型重新整理記錄中。關於每次重新整理的重要資訊會顯示，包括針對設定的查詢百分比取用快取中的記憶體彙總量。若要檢視刷新記錄，請在模型設定頁面中，選取 刷新記錄。如果您想進一步了解，請選擇顯示詳細資料。

Screenshot of the refresh history window showing the scheduled history details. [重新整理記錄] 視窗的螢幕擷取畫面，顯示排定歷史記錄的詳細資訊。

藉由定期檢查重新整理記錄，您可確保排程的重新整理作業會在可接受的期間內完成。確定重新整理作業會在下一次排程的重新整理開始之前成功完成。

訓練和更新失敗

雖然 Power BI 會根據您所選擇的每日或每週頻率，在當日或當週的第一個排程刷新過程中進行訓練和刷新作業，但這些作業會以個別交易的形式來實作。如果訓練作業在其時間限制內無法完整處理查詢記錄，Power BI 將使用先前的訓練狀態，繼續重新整理現有的彙總 (以及複合模型中的一般資料表)。在此情況下，重新整理記錄將指出重新整理成功，而訓練會在下次啟動訓練時繼續處理查詢記錄。如果用戶端報表查詢模式已變更且彙總尚未調整，則查詢效能的最佳化程度可能較低，但達到的效能等級仍應比沒有任何彙總的單純 DirectQuery 模型好得多。

Screenshot of the refresh history screen showing an item that was partially completed. 顯示部分完成項目的重新整理歷史記錄螢幕擷取畫面。

如果訓練作業需要太多週期才能完成查詢記錄的處理，請考慮降低在模型設定中使用記憶體內部彙總快取的查詢百分比。這將減少在快取中建立的彙總數目，但能夠有更多時間來完成訓練和重新整理作業。若要深入了解，請參閱微調。

如果訓練成功但重新整理失敗，即會將整個重新整理標示為失敗，因為結果是一個無法使用的記憶體內部彙總快取。

排程重新整理時，您可以指定重新整理失敗時的電子郵件通知。

使用者定義的彙總和自動彙總

Power BI 中的可自訂彙總可以根據模型中的隱藏彙總資料表手動設定。設定使用者定義的彙總通常很複雜，需要更高層級的資料模型化和查詢最佳化技能。另一方面，作為 AI 驅動系統的一部分，自動彙總可消除這種複雜度。與保持靜態的使用者定義彙總不同，Power BI 會持續維護查詢記錄，並根據機器學習 (ML) 預測模型化演算法，從那些記錄中判斷查詢模式。預先彙總的資料會根據查詢模式分析來計算並儲存於記憶體內部。透過自動彙總，模型既可自我訓練，也可自我最佳化。當客戶報表的查詢模式改變時，自動聚合會進行調整，優先處理並快取那些最常用的聚合。

由於自動彙總建置於現有的使用者定義彙總基礎結構之上，因此，可在相同模型中同時使用使用者定義的彙總和自動彙總。熟練的資料模型師可以使用 DirectQuery、匯入（有或沒有增量式重新整理）或雙重儲存模式來定義資料表的聚合。與此同時，對於透過 DirectQuery 連線進行且未使用使用者定義聚合資料表的查詢，系統能提供更多自動聚合的優勢。此彈性讓平衡的架構可降低查詢負載，並避免出現瓶頸。

自動彙總訓練演算法在記憶體內部快取中建立的彙總會識別為 System 彙總。訓練演算法在分析報告查詢並進行調整以維持模型的最佳彙總時，只會建立和刪除那些System彙總。使用者定義的彙總和自動彙總都會透過更新來重新整理。只有自動彙總所建立並標示為系統產生之彙總的彙總才會包含在自動彙總處理中。

查詢快取和自動彙總

Power BI Premium 也支援在 Power BI Premium/Embedded 中查詢快取，以維護查詢結果。查詢快取是一種與自動彙總功能截然不同的特性。透過查詢快取機制，Power BI Premium 使用其本地快取服務來進行快取操作，而自動彙總功能則在模型層級執行。透過查詢快取，服務僅針對報表頁面的首次載入進行查詢快取，因此，當使用者與報表互動時，查詢效能不會提升。相反地，自動彙總會透過預先快取的彙總查詢結果，將大多數的報表查詢最佳化，包括使用者與報表互動時產生的查詢。查詢快取和自動彙總都可針對模型啟用，但可能並非必要。

使用 Azure Log Analytics 監視

Azure Log Analytics (LA) 是 Azure 監視器內的服務，讓 Power BI 可用來儲存活動記錄。透過 Azure 監視器套件，您可以收集、分析及處理來自 Azure 和內部部署環境的遙測資料。其提供長期儲存體、臨機操作查詢介面和 API 存取，以允許資料匯出並與其他系統整合。若要深入了解，請參閱在 Power BI 中使用 Azure Log Analytics。

如果 Power BI 已依照設定適用於 Power BI 的 Azure Log Analytics 所述使用 Azure LA 帳戶進行設定，則您可以分析自動彙總結果的成功率。除此之外，您還能判斷報表查詢是否可從記憶體內部快取中得到答案。

若要使用此功能，下載 PBIT 範本，然後依據此 Power BI 部落格文章 (英文) 的說明，將它連接到您的記錄分析帳戶。在報表中，您可以檢視三個不同層級的資料：摘要檢視、DAX 查詢層級檢視，以及 SQL 查詢層級檢視。

下圖顯示所有查詢的摘要頁面。如您所見，標示的圖表會顯示彙總所滿足的查詢總數百分比，以及必須利用資料來源的查詢總數百分比。

Screenshot with log analytics queries by aggregations stage. 依彙總階段顯示記錄分析查詢的螢幕擷取畫面。

下一個深入探討的步驟是查看 DAX 查詢層級的彙總用法。以滑鼠右鍵按一下清單中的 DAX 查詢 (左下) >[鑽取][查詢歷史記錄]>。

Screenshot that shows log analytics query history. 顯示記錄分析查詢歷史記錄的螢幕擷取畫面。

這將為您提供所有相關查詢的清單。鉆穿至下一個層級，以顯示更多詳細的彙總資料。

Screenshot that shows log analytics query history drill through. 顯示出日誌分析查詢歷史深入功能的螢幕擷取畫面。

應用程式生命週期管理

從開發到測試及從測試到實際執行環境，已啟用自動彙總的模型對 ALM 解決方案有特殊需求。

部署管線

透過部署管線，Power BI 可將模型及其模型設定從目前階段複製到目標階段。不過，自動彙總必須在目標階段重設，因為設定不會從目前階段傳輸到目標階段。您也可以使用部署管線 REST API，以程式設計方式部署內容。若要深入了解此流程，請參閱「使用 API 和 DevOps 將部署管線自動化」。

自訂 ALM 解決方案

如果您使用以 XMLA 端點為基礎的自訂 ALM 解決方案，請記住，您的解決方案可能會複製系統產生的彙總資料表和使用者建立的彙總資料表，作為模型中繼資料的一部分。不過，您必須在目標階段的每個部署步驟之後手動啟用自動彙總。如果您覆寫現有模型，Power BI 將會保留設定。

注意

如果您上傳或重新發佈模型作為 Power BI Desktop (.pbix) 檔案的一部分，系統建立的彙總資料表就會遺失，因為 Power BI 會以目標工作區中的所有中繼資料和資料取代現有模型。

改變模型

在透過 XMLA 端點更改已啟用自動彙總的模型之後 (例如，新增或移除資料表)，Power BI 會保留所有可以保留的現有彙總，並移除不再需要或相關的彙總。查詢效能可能會受到影響，直到觸發下一個訓練階段為止。

中繼資料元素

已啟用自動彙總的模型包含系統產生的唯一彙總資料表。使用者不會在報表工具中看見彙總資料表。可以透過 XMLA 端點，使用搭載版本 19.22.5 或更新版本的 Analysis Services 用戶端程式庫的工具來查看。使用已啟用自動彙總的模型時，務必將您的資料模型化和管理工具升級至最新版的用戶端程式庫。針對 SQL Server Management Studio (SSMS)，升級至 SSMS 版本 18.9.2 或更高版本。舊版 SSMS 無法列舉資料表或編寫出這些模型的指令碼。

自動彙總資料表是透過 SystemManaged 資料表屬性來識別，這是 Analysis Services 用戶端程式庫版本 19.22.5 和更新版本中表格式物件模型 (TOM) 的新功能。下列程式碼片段顯示屬性SystemManaged，針對自動彙總資料表設定為true，針對一般資料表設定為false。

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.AnalysisServices.Tabular;

namespace AutoAggs
{
    class Program
    {
        static void Main(string[] args)
        {
            string workspaceUri = "<Specify the URL of the workspace where your model resides>";
            string datasetName = "<Specify the name of your dataset>";

            Server sourceWorkspace = new Server();
            sourceWorkspace.Connect(workspaceUri);
            Database dataset = sourceWorkspace.Databases.GetByName(datasetName);

            // Enumerate system-managed tables.
            IEnumerable<Table> aggregationsTables = dataset.Model.Tables.Where(tbl => tbl.SystemManaged == true);


            if (aggregationsTables.Any())
            {
                Console.WriteLine("The following auto aggs tables exist in this dataset:");
                foreach (Table table in aggregationsTables)
                {
                    Console.WriteLine($"\t{table.Name}");
                }
            }
            else
            {
                Console.WriteLine($"This dataset has no auto aggs tables.");
            }

            Console.WriteLine("\n\rPress [Enter] to exit the sample app...");
            Console.ReadLine();
        }
    }
}

執行此程式碼片段，會在控制台上輸出模型中目前包含的自動彙總資料表。

輸出程式碼片段的螢幕擷取畫面，顯示在模型中存在的自動聚合資料表。

請記住，隨著訓練作業會判斷要包含在記憶體內部彙總快取中的最佳彙總，彙總資料表會不斷變化。

重要

Power BI 可完全管理自動彙總系統產生的資料表物件。請勿自行刪除或修改這些資料表。這樣做可能導致效能下降。

Power BI 會在模型外部維護模型設定。模型中存在系統管理的彙總資料表，不一定表示實際上會啟用模型來進行自動彙總訓練。換句話說，如果您針對已啟用自動彙總的模型編寫出完整的模型定義指令碼，並建立模型的新複本 (具有不同的名稱/工作區/容量)，則不會啟用新的結果模型來進行自動彙總訓練。您仍然需要在模型設定中，針對新模型啟用自動彙總訓練。

考量與限制

使用自動彙總時，請記住下列事項：

彙總不支援動態 M 查詢參數。
初始訓練階段期間產生的 SQL 查詢可能會為資料倉儲產生大量負載。如果訓練始終未完成，而您可在資料倉儲端確認查詢遇到逾時，請考慮暫時擴大資料倉儲以符合訓練需求。
儲存在記憶體內部彙總快取中的彙總，可能不會針對資料來源的最新資料進行計算。不同於單純的 DirectQuery，而是更像一般匯入資料表，資料來源上的更新與儲存於記憶體內部彙總快取中的彙總資料之間會有延遲。儘管一律將會有某種程度的延遲，但可透過有效的重新整理排程來降低風險。
若要進一步最佳化效能，請將所有維度資料表設為雙重模式，並將事實資料表保留在 DirectQuery 模式。
Power BI Pro、Azure Analysis Services 或 SQL Server Analysis Services 無法使用自動彙總。
Power BI 不支援下載已啟用自動彙總的模型。如果您將 Power BI Desktop (.pbix) 檔案上傳或發佈至 Power BI，然後啟用自動彙總，就無法再下載 PBIX 檔案。請務必在本機保留 PBIX 檔案的複本。
在 Azure Synapse Analytics 中，不支援使用外部資料表的自動彙總。您可以使用下列 SQL 查詢來列舉 Synapse 中的外部資料表：SELECT SCHEMA_NAME(schema_id) AS schema_name, name AS table_name FROM sys.external_tables。
自動彙總僅適用於使用增強型中繼資料的模型。如果您想要為較舊的模型啟用自動彙總，先將模型升級到增強型中繼資料。若要深入了解，請參閱使用增強型模型中繼資料。
如果將 DirectQuery 資料來源設定為單一登入，並使用動態資料檢視或安全性控制項來限制允許使用者存取的資料，則不要啟用自動彙總。自動彙總並不知道這些資料來源層級的控制項，因此無法確保會為每位使用者提供正確的資料。訓練將在重新整理記錄中記錄警告，指出其偵測到針對單一登入設定的資料來源，並略過使用此資料來源的資料表。如果可能，針對這些資料來源停用 SSO，以充分利用自動彙總可提供且已最佳化的查詢效能。
如果模型只包含混合式資料表，則不要啟用自動彙總，以避免不必要的處理額外負荷。混合式資料表會同時使用匯入分割區和 DirectQuery 分割區。常見案例是使用即時資料進行累加式重新整理，其中 DirectQuery 分割區會從資料來源中擷取自上次資料重新整理之後發生的交易。不過，Power BI 會在重新整理期間匯入彙總。自動彙總不能包含自上次資料重新整理之後發生的交易。訓練過程將在重新整理記錄中記錄警告，指出它已偵測到且略過混合式資料表。
計算結果欄不會被視為自動彙總。如果您在 DirectQuery 模式中使用計算欄，例如使用 COMBINEVALUES DAX 函數，根據來自兩個 DirectQuery 資料表的多個資料行建立關係，對應的報表查詢將不會命中記憶體中的彙總快取。
自動彙總僅適用於 Power BI 服務。 Power BI Desktop 不會建立系統產生的彙總資料表。
如果您修改已啟用自動彙總之模型的中繼資料，查詢效能可能就會下降，直到觸發下一個訓練流程為止。最佳做法是，您應該卸除自動彙總、進行變更，然後重新訓練。
除非您已停用自動彙總並清除模型，否則不要修改或刪除系統產生的彙總資料表。系統會負責管理這些物件。

社群

Power BI 擁有充滿活力的社群，MVP、BI 專業人員和同行在討論群組、影片、部落格等中分享專長。了解自動彙總時，請務必查看下列其他資源：