共用方式為

自動彙總

  • 發行項

自動彙總使用最先進的機器學習 (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
  • Snowflake
  • Databricks
  • Amazon Redshift

支援的模式

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

權限

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

設定自動彙總

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

福利

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

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

此圖顯示自動彙總處理。

自動查詢和彙總管理

雖然自動彙總不需要建立使用者定義的彙總資料表，並大幅簡化實作預先彙總的資料解決方案，但更深入熟悉基礎流程和相依性有助於了解自動彙總的運作方式。 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 排程的重新整理均為「僅重新整理作業」，其會更新快取中現有的彙總。

此圖顯示訓練和重新整理作業。

雖然訓練作業會從查詢記錄評估過去的查詢，但結果夠準確，可確保會涵蓋未來的查詢。 但是，不保證記憶體內部彙總快取將會傳回未來的查詢，因為那些新查詢可能與從查詢記錄衍生的查詢不同。 記憶體內部彙總快取未傳回的查詢會使用 DirectQuery 傳遞至資料來源。 視那些新查詢的頻率與排名而定，那些查詢的彙總可能會隨著下一個訓練作業包含於記憶體內部彙總快取中。

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

重新整理作業

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

此圖顯示僅重新整理作業及與資料來源相關的重新整理查詢。

當天 (或當週) 定期排程的重新整理，確保快取中的彙總資料會與後端資料來源的資料保持同步。 透過模型設定，您每天最多可排程 48 次重新整理，以確保彙總快取傳回的報表查詢會根據後端資料來源的最新重新整理資料取得結果。

警告

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

隨需訓練

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

重新整理記錄

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

[重新整理記錄] 視窗的螢幕擷取畫面，其中顯示排程的記錄詳細資料。

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

訓練和重新整理失敗

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

重新整理記錄畫面的螢幕擷取畫面，其中顯示部分完成的項目。

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

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

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

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

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 是使用 Azure LA 帳戶所設定 (如設定適用於 Power BI 的 Azure Log Analytics 中所述)，您就能分析自動彙總的成功率。 除此之外，您還能判斷報表查詢是否可從記憶體內部快取中得到答案。

若要使用此功能，下載 PBIT 範本，並將其連線到您的記錄分析帳戶，如這篇 Power BI 部落格文章 (英文) 所述。 在報表中，您可以檢視三個不同層級的資料：摘要檢視、DAX 查詢層級檢視，以及 SQL 查詢層級檢視。

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

依彙總階段顯示記錄分析查詢的螢幕擷取畫面。

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

顯示記錄分析查詢歷史記錄的螢幕擷取畫面。

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

顯示記錄分析查詢歷史記錄鑽研的螢幕擷取畫面。

應用程式生命週期管理

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

部署管線

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

自訂 ALM 解決方案

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

注意

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

改變模型

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

中繼資料元素

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

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

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 專業人員和同行在討論群組、影片、部落格等中分享專長。 了解自動彙總時，請務必查看下列其他資源：

相關內容