使用者定義的匯總

Power BI 中的匯總可以改善大型 DirectQuery 語意模型的查詢效能。 藉由使用匯總，您可以在記憶體中匯總層級快取數據。 Power BI 中的匯總可以在數據模型中手動設定，如本文所述。 針對 進階版 訂閱，請在模型 設定 中啟用自動匯總功能。

建立匯總數據表

根據數據源類型，匯總數據表可以建立於數據源做為數據表或檢視表的原生查詢。 為了達到最大效能，請將匯總數據表建立為 Power Query 中建立的匯入數據表。 接著，您可以使用 Power BI Desktop 中的 [管理匯總] 對話方塊，使用摘要、詳細數據表和詳細資料行屬性來定義匯總數據行的匯總。

數據倉儲和數據超市等維度數據源可以使用 以關聯性為基礎的匯總。 Hadoop 型巨量數據源通常會 以 GroupBy 數據行為基礎匯總。 本文說明每種數據源類型的典型 Power BI 數據模型化差異。

管理彙總

在任何 Power BI Desktop 檢視的 [ 資料 ] 窗格中，以滑鼠右鍵按兩下匯總數據表，然後選取 [ 管理匯總]。

[ 管理匯總] 對話框會顯示資料表中每個數據行的數據列，您可以在其中指定匯總行為。 在下列範例中，Sales 詳細數據數據表的查詢會在內部重新導向至 Sales Agg 匯總數據表。

在此以關聯性為基礎的匯總範例中，GroupBy 專案是選擇性的。 除了 DISTINCTCOUNT 之外，它們不會影響匯總行為，主要是為了可讀性。 如果沒有 GroupBy 專案，匯總仍會根據關聯性來叫用。 這與 本文稍後的巨量數據範例 不同，其中需要 GroupBy 專案。

驗證

[ 管理匯總] 對話框會強制執行驗證：

• 詳細數據行必須與匯總數據行具有相同的數據類型，但 Count 和 Count 數據表數據列摘要函式除外。 計數和計數數據表數據列僅適用於整數匯總數據行，而且不需要相符的數據類型。
• 不允許包含三個或多個數據表的鏈結匯總。 例如，數據表 A 上的匯總無法參考數據表 B，而數據表 B 具有參考數據表 C 的匯總。
• 不允許重複匯總，其中兩個專案使用相同的摘要函式並參考相同的詳細數據數據表和詳細數據行。
• 詳細數據數據表必須使用 DirectQuery 儲存模式，而非匯入。
• 不支援依非作用中關聯性所使用的外鍵數據行分組，以及依賴USERELATIONSHIP函數進行匯總叫用。
• 根據 GroupBy 數據行的匯總可以使用匯總數據表之間的關聯性，但在 Power BI Desktop 中不支援在匯總數據表之間撰寫關聯性。 如有必要，您可以透過 XML for Analysis （XMLA） 端點，使用第三方工具或腳本解決方案，在匯總數據表之間建立關聯性。

大部分的驗證都是藉由停用下拉式清單值，並在工具提示中顯示說明文字來強制執行。

匯總數據表已隱藏

具有模型唯讀存取權的用戶無法查詢匯總數據表。 只讀存取可避免與數據列層級安全性 （RLS） 搭配使用時的安全性考慮。 取用者和查詢會參考詳細數據數據表，而不是匯總數據表，而且不需要知道匯總數據表。

因此，匯總數據表會隱藏在 報表 檢視中。 如果數據表尚未隱藏，[ 管理匯總] 對話方塊會在您選取 [全部套用] 時將其設定為隱藏。

儲存體模式

匯總功能會與數據表層級儲存模式互動。 Power BI 數據表可以使用 DirectQuery、 匯入或 雙重 儲存模式。 DirectQuery 會直接查詢後端，同時匯入會快取記憶體中的數據，並將查詢傳送至快取的數據。 所有 Power BI 匯入和非多維度 DirectQuery 數據源都可以使用匯總。

若要將匯總數據表的儲存模式設定為 [匯入] 以加速查詢，請在Power BI Desktop 模型 檢視中選取匯總數據表。 在 [屬性] 窗格中，展開 [進階]，下拉 儲存體 模式下的選取專案，然後選取 [匯入]。 變更匯入無法復原。

若要深入了解數據表儲存模式，請參閱 在 Power BI Desktop 中管理儲存模式。

匯總的 RLS

若要正確處理匯總，RLS 運算式應該篩選匯總數據表和詳細數據數據表。

在下列範例中，Geography 數據表上的 RLS 運算式適用於匯總，因為 Geography 位於 Sales 數據表和 Sales Agg 數據表關聯性的篩選端。 叫用匯總數據表的查詢和未成功套用 RLS 的查詢。

Product 數據表上的 RLS 運算式只會篩選詳細 Sales 數據表，而不是匯總的 Sales Agg 數據表。 由於匯總數據表是詳細數據表中另一個數據表示法，因此如果無法套用 RLS 篩選條件，則從匯總數據表回答查詢會不安全。 不建議只篩選詳細數據數據表，因為來自此角色的用戶查詢不會受益於匯總叫用。

RLS 表達式，只 篩選 Sales Agg 匯總數據表，而不允許 Sales 詳細數據數據表。

對於 以 GroupBy 數據行為基礎的匯總，套用至詳細數據的 RLS 表達式可用來篩選匯總數據表，因為匯總數據表中的所有 GroupBy 數據行都會由詳細數據數據表所涵蓋。 另一方面，匯總數據表上的 RLS 篩選無法套用至詳細數據數據表，因此不允許。

以關聯性為基礎的匯總

維度模型通常會根據關聯性使用匯總。 來自數據倉儲和數據超市的Power BI模型類似於星型/雪花式架構，維度數據表與事實數據表之間的關聯性。

在下列範例中，模型會從單一數據源取得數據。 數據表使用 DirectQuery 儲存模式。 Sales 事實數據表包含數十億個數據列。 將 Sales 的儲存模式設定為匯入快取，將會耗用相當大量的記憶體和資源負荷。

請改為建立 Sales Agg 匯總數據表。 在 Sales Agg 數據表中，數據列數目等於依 CustomerKey、DateKey 和 ProductSubcategoryKey 分組的 SalesAmount 總和。 Sales Agg 數據表的數據粒度高於 Sales，因此，它可能包含數百萬個數據列，這更容易管理。

如果下列維度數據表最常用於具有高商業價值的查詢，則可以使用一對多或多對一關聯性來篩選 Sales Agg。

• 地理位置
• 客戶
• Date
• Product Subcategory
• Product Category

下圖顯示此模型。

下表顯示 Sales Agg 數據表的匯總。

注意

Sales Agg 數據表和任何數據表一樣，具有以各種方式載入的彈性。 匯總可以在源資料庫中使用 ETL/ELT 進程或數據表的 M 運算式 來執行。 匯總數據表可以使用匯入儲存模式、語意模型的累加式重新整理或不使用累加式重新整理，也可以使用 DirectQuery，並使用數據行存放區索引針對快速查詢進行優化。 這種彈性可讓平衡的架構分散查詢負載，以避免瓶頸。

將匯總 Sales Agg 數據表的儲存模式變更為 [匯入] 會開啟對話框，指出相關的維度數據表可以設定為 [雙重儲存模式]。

將相關的維度數據表設定為 [雙重] 可讓它們根據子查詢做為 Import 或 DirectQuery。 在下列範例中：

• 您可以從記憶體內部快取傳回從匯入模式 Sales Agg 數據表匯總計量的查詢，以及依屬性分組的查詢。
• 從 DirectQuery Sales 數據表匯總計量的查詢，以及依相關雙重數據表的 attribute（s） 分組的查詢，可以在 DirectQuery 模式中傳回。 查詢邏輯，包括 GroupBy 作業，會向下傳遞至源資料庫。

如需雙重儲存模式的詳細資訊，請參閱 在 Power BI Desktop 中管理儲存模式。

一般與有限的關聯性

以關聯性為基礎的匯總叫用需要一般關聯性。

一般關聯性包括下列儲存模式組合，其中兩個數據表都是來自單一來源：

多邊的表格	1 端的表格
雙重	雙重
Import	匯入或雙重
DirectQuery	DirectQuery 或雙重

唯一將跨來源關聯性視為一般的情況是，如果兩個數據表都設定為 [匯入]。 多對多關聯性一律視為有限。

如需 不相依於關聯性的跨來源 匯總叫用，請參閱 以 GroupBy 數據行為基礎的匯總。

關聯性型匯總查詢範例

下列查詢會叫用匯總，因為 Date 數據表中的數據行位於可叫用匯總的數據粒度。 SalesAmount 數據行會使用 Sum 匯總。

下列查詢不會叫用匯總。 儘管要求 SalesAmount 的總和，查詢會在 Product 數據表中的數據行上執行 GroupBy 作業，但數據粒度無法達到匯總。 如果您觀察模型中的關聯性，產品子類別可以有多個 Product 數據 列。 查詢無法判斷要匯總的產品。 在此情況下，查詢會還原為 DirectQuery，並將 SQL 查詢提交至數據源。

匯總不只是針對執行簡單總和的簡單計算。 複雜的計算也可以受益。 從概念上講，複雜的計算會細分為每個 SUM、MIN、MAX 和 COUNT 的子查詢。 系統會評估每個子查詢，以判斷它是否可以叫用匯總。 由於查詢計劃優化，此邏輯在所有情況下都不會保留 true，但一般應該適用。 下列範例會叫用匯總：

COUNTROWS 函式可以受益於匯總。 下列查詢會叫用匯總，因為 Sales 數據表定義了 Count 數據表數據列匯總。

AVERAGE 函式可以受益於匯總。 下列查詢會叫用匯總，因為 AVERAGE 會在內部折疊至 SUM 除以 COUNT。 由於 UnitPrice 數據行已針對 SUM 和 COUNT 定義匯總，因此會叫用匯總。

在某些情況下，DISTINCTCOUNT 函式可以受益於匯總。 下列查詢會叫用匯總，因為 CustomerKey 有 GroupBy 專案，可維護匯總數據表中 CustomerKey 的相異性。 這項技術可能仍會達到效能閾值，其中超過 2 到 500 萬個相異值可能會影響查詢效能。 不過，在詳細數據表中有數十億個數據列，但在數據行中有 2 到 500 萬個相異值的情況下，它很有用。 在此情況下，DISTINCTCOUNT 的執行速度比使用數十億個數據列掃描數據表更快，即使它快取到記憶體中也一樣。

數據分析表示式 （DAX） 時間智慧函式可感知匯總。 下列查詢會叫用匯總，因為 DATESYTD 函式會產生 CalendarDay 值的數據表，而且匯總數據表的數據粒度為 Date 數據表中的分組數據行所涵蓋。 這是 CALCULATE 函式的數據表值篩選範例，可搭配匯總使用。

以 GroupBy 數據行為基礎的匯總

Hadoop 型巨量數據模型的特性與維度模型不同。 為了避免大型數據表之間的聯結，巨量數據模型通常不會使用關聯性，而是將維度屬性反正規化為事實數據表。 您可以使用以 GroupBy 數據行為基礎的匯總，解除鎖定這類巨量數據模型以進行互動式分析。

下表包含要匯總的 移動 數值數據行。 所有其他數據行都是要分組依據的屬性。 數據表包含IoT資料和大量數據列。 儲存模式為 DirectQuery。 由於整體模型磁碟區較慢而匯總的數據源查詢。

若要啟用此模型的互動式分析，您可以新增匯總數據表，依大部分屬性分組，但排除經度和緯度等高基數屬性。 這可大幅減少數據列數目，而且小到足以舒適地放入記憶體內部快取中。

您可以在 [管理匯總] 對話框中定義 Driver Activity Agg 數據表的匯總對應。

在以 GroupBy 數據行為基礎的匯總中 ，GroupBy 專案不是選擇性專案。 如果沒有它們，匯總就不會被叫用。 這與根據關聯性使用匯總不同，其中 GroupBy 專案是選擇性的。

下表顯示 Driver Activity Agg 數據表的匯總。

您可以將匯總 驅動程式活動 Agg 資料表的儲存模式設定為 [匯入]。

GroupBy 匯總查詢範例

下列查詢會叫用匯總，因為 匯總數據表涵蓋 [活動日期 ] 數據行。 COUNTROWS 函式會使用 Counted 數據表數據列 匯總。

特別是對於包含事實上數據表中篩選屬性的模型而言，最好是使用 計數數據表數據列 匯總。 在使用者未明確要求查詢的情況下，Power BI 可以使用 COUNTROWS 將查詢提交至模型。 例如，篩選對話框會顯示每個值的數據列計數。

合併匯總技術

您可以結合匯總的關聯性和 GroupBy 數據行技術。 根據關聯性的匯總可能需要將反正規化維度數據表分割成多個數據表。 如果某些維度數據表的成本很高或不切實際，您可以在這些維度的匯總數據表中復寫必要的屬性，並針對其他維度使用關聯性。

例如，下列模型會復寫 Sales Agg 數據表中的 Month、Quarter、Semester 和 Year。 Sales Agg 與 Date 數據表之間沒有關聯性，但與 Customer 和 Product Subcategory 之間沒有關聯性。 Sales Agg 的儲存模式為 Import。

下表顯示 Sales Agg 資料表之 [管理匯總] 對話框中設定的專案。 Date 是必要詳細數據數據表的 GroupBy 專案，可按 Date 屬性叫用該群組的查詢匯總。 如前一個範例所示，CustomerKey 和 ProductSubcategoryKey 的 GroupBy 專案不會影響匯總叫用，除了 DISTINCTCOUNT 之外，因為關聯性存在。

合併匯總查詢範例

下列查詢會叫用匯總，因為匯總數據表涵蓋 CalendarMonth，而 CategoryName 可透過一對多關聯性來存取。 SalesAmount 使用 SUM 匯總。

下列查詢不會叫用匯總，因為匯總數據表未涵蓋 CalendarDay。

下列時間智能查詢不會叫用匯總，因為 DATESYTD 函式會產生 CalendarDay 值的數據表，而且匯總數據表不會涵蓋 CalendarDay。

匯總優先順序

匯總優先順序可讓單一子查詢考慮多個匯總數據表。

下列範例是 包含多個來源的複合模型 ：

• Driver Activity DirectQuery 數據表包含來自巨量數據系統的 IoT 資料超過萬億列。 它會提供鑽研查詢，以檢視受控制篩選內容中的個別IoT讀數。
• Driver Activity Agg 數據表是 DirectQuery 模式中的中繼匯總數據表。 它包含 Azure Synapse Analytics 中超過 10 億個數據列（先前稱為 SQL 數據倉儲），並使用數據行存放區索引在來源優化。
• 驅動程式活動 Agg2 匯入數據表的數據粒度很高，因為分組屬性很少，基數較低。 數據列數目可能高達數千個，因此可以輕鬆地放入記憶體內部快取中。 這些屬性會由高調的執行儀錶板使用，因此參考這些屬性的查詢應盡可能快。

注意

只有當匯總數據表來自 SQL Server、Azure SQL 或 Azure Synapse Analytics（先前稱為 SQL 數據倉儲）來源時，才支援使用與詳細數據數據表不同的數據源的 DirectQuery 匯總數據表。

此模型的記憶體使用量相對較小，但它會解除鎖定大型模型。 它代表平衡的架構，因為它會將查詢負載分散到架構的元件，並根據其優勢加以利用。

Driver Activity Agg2 的 [Managed 匯總] 對話框會將 [優先順序] 字段設定為 10，高於 [驅動程式活動 Agg]。 較高的優先順序設定表示先使用匯總的查詢會考慮 驅動程序活動 Agg2 。 不是驅動程序活動 Agg2 可回答之粒度的子查詢可以改為考慮驅動程式活動 Agg。 無法由任一匯總數據表回答的詳細數據查詢，都可以導向驅動程序 活動。

[詳細數據數據表] 數據行中指定的數據表是 Driver Activity，而不是 Driver Activity Agg，因為不允許鏈結匯總。

下表顯示驅動程序活動 Agg2 資料表的匯總。

偵測查詢叫用或遺漏匯總

SQL Profiler 可以偵測查詢是從記憶體內部快取儲存引擎傳回，還是由 DirectQuery 推送至數據源。 您可以使用相同的程式來偵測是否叫用匯總。 如需詳細資訊，請參閱 叫用或遺漏快取的查詢。

SQL Profiler 也提供 Query Processing\Aggregate Table Rewrite Query 擴充事件。

下列 JSON 代碼段顯示使用匯總時事件輸出的範例。

• matchingResult 顯示子查詢使用了匯總。
• dataRequest 會顯示使用的子查詢的 GroupBy 數據行和匯總數據行。
• 對應 會顯示已對應之匯總數據表中的數據行。

讓快取保持同步

結合 DirectQuery、匯入和/或雙重儲存模式的匯總可以傳回不同的數據，除非記憶體內部快取與源數據保持同步。 例如，查詢執行不會嘗試藉由篩選 DirectQuery 結果來比對快取的值來遮罩數據問題。 如有需要，有已建立的技術可在來源處理這類問題。 效能優化應該只以不危害您符合業務需求的能力的方式使用。 您必須負責了解數據流並據以設計。

考量與限制

• 匯總不支持 動態 M 查詢參數。

• 從 2022 年 8 月開始，由於功能變更，Power BI 會忽略已啟用單一登錄 （SSO） 的匯入模式匯總數據表，因為潛在的安全性風險。 為了確保使用匯總的最佳查詢效能，建議您停用這些數據源的 SSO。

社群

Power BI 具有充滿活力的社群，其中 MVP、BI 專業人員和同儕共用討論群組、影片、部落格等的專業知識。 了解匯總時，請務必查看下列其他資源：

• Power BI 社群
• 在 Bing 上搜尋「Power BI 匯總」

相關內容

• 自動匯總
• 複合模型