自動匯總

  • 發行項

自動匯總會使用最先進的機器學習服務 （ML） 持續優化 DirectQuery 語意模型，以達到報表查詢效能上限。 自動匯總建置在Power BI複合模型首次引進的現有 使用者定義匯總 基礎結構之上。 與使用者定義的匯總不同，自動匯總不需要大量的數據模型化和查詢優化技能來設定和維護。 自動匯總既是自我定型又自我優化。 它們可讓任何技能層級的模型擁有者改善查詢效能，為大型模型提供更快的報表視覺效果。

使用自動匯總：

  • 報表視覺效果更快 - 自動維護的記憶體內部匯總快取會傳回報表查詢的最佳百分比，而不是後端數據源系統。 記憶體內部快取未傳回的極端值查詢會使用 DirectQuery 直接傳遞至數據源。
  • 平衡架構 - 相較於純 DirectQuery 模式，大部分的查詢結果都會由 Power BI 查詢引擎和記憶體內部匯總快取傳回。 在尖峰報告時間對數據源系統的查詢處理負載可以大幅減少，這表示數據源後端的延展性增加。
  • 輕鬆設定 - 模型擁有者可以啟用自動匯總定型，並排程模型的一或多個重新整理。 在第一次定型和重新整理之後，自動匯總會開始建立匯總架構和最佳匯總。 系統會隨著時間自動調整本身。
  • 微調 – 在模型設定中使用簡單且直覺的使用者介面，您可以估計從記憶體內部匯總快取傳回之不同百分比查詢的效能提升，並調整以取得更大的收益。 單一投影片列控件可協助您輕鬆地微調環境。

需求

支援的方案

Power BI 支援每個容量的自動匯總 進階版、每位使用者 進階版，以及 Power BI Embedded 模型。

支援的資料來源

下列資料源支援自動匯總：

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

支援的模式

DirectQuery 模式模型支援自動匯總。 支援具有匯入數據表和 DirectQuery 連線的複合模型。 只有 DirectQuery 連線才支援自動匯總。

權限

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

設定自動匯總

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

福利

使用 DirectQuery 時，每次模型使用者開啟報表或與報表視覺效果互動時，數據分析表示式 （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：00AM 重新整理會同時包含訓練作業和重新整理作業。 後續的上午 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 進階版 也支援 Power BI 進階版/Embedded 中的查詢快取，以維護查詢結果。 查詢快取與自動匯總不同。 使用查詢快取，Power BI 進階版 會使用其本機快取服務來實作快取，而自動匯總則會在模型層級實作。 使用查詢快取時，服務只會快取初始報表頁面載入的查詢，因此當使用者與報表互動時，查詢效能不會改善。 相反地，自動匯總會預先快取匯總查詢結果，將大部分報表查詢優化，包括使用者與報表互動時所產生的查詢。 查詢快取和自動匯總都可以針對模型啟用，但可能不需要。

使用 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 查詢層級檢視。

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

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 端點使用具有 Analysis Services 用戶端連結庫 19.22.5 版和更新版本的工具來看見。 使用已啟用自動匯總的模型時，請務必將您的數據模型化和管理工具升級至最新版的用戶端連結庫。 針對 SQL Server Management Studio （SSMS），升級至 SSMS 18.9.2 版或更高版本。 舊版 SSMS 無法列舉數據表或編寫這些模型的腳本。

自動匯總數據表是由 SystemManaged 數據表屬性所識別，這是 Analysis Services 用戶端連結庫 19.22.5 版和更新版本中表格式物件模型 （TOM） 的新功能。 下列代碼段顯示針對SystemManaged自動匯總數據表和false一般數據表，設定為 true 的屬性。

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();
        }
    }
}

執行此代碼段會輸出控制台中模型目前包含在模型中的自動匯總數據表。

Screenshot of the output the snippet showing auto aggs tables that exist in the model.

請記住，當定型作業決定要包含在記憶體中匯總快取的最佳匯總時，匯總數據表會不斷變更。

重要

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 專業人員和同儕共用討論群組、影片、部落格等的專業知識。 了解自動匯總時，請務必查看下列其他資源：

相關內容