自动聚合

自动聚合使用最先进的机器学习（ML）来持续优化 DirectQuery 语义模型，以实现最大的报表查询性能。自动聚合是基于首次为 Power BI 引入的复合模型中的现有用户定义的聚合基础设施构建的。与用户定义的聚合不同，自动聚合不需要™大量的数据建模和查询优化技能来配置和维护。自动聚合既是自我训练，也是自我优化。它们使任何技能级别的模型所有者能够提高查询性能，从而为大型模型提供更快的报表可视化效果。

使用自动聚合：

报告可视化更快 - 查询最佳比例的报告由自动维护的内存聚合缓存返回，而不是后端数据源系统。内存中缓存未返回的离群值查询使用 DirectQuery 直接传递到数据源。
均衡的体系结构 - 与纯 DirectQuery 模式相比，Power BI 查询引擎和内存中聚合缓存会返回大多数查询结果。在高峰报告时间，数据源系统上的查询处理负载可以显著减少，这意味着数据源后端的可伸缩性增加。
轻松设置 - 模型所有者可以启用自动聚合训练并为模型计划一个或多个刷新。第一次训练和刷新后，自动聚合开始创建聚合框架和最佳聚合。系统随时间推移自动调整自身。
微调 - 使用模型设置中的简单直观的用户界面，可以估计内存中聚合缓存返回的查询的不同百分比的性能提升，并进行调整，以获取更大的收益。单个滑块控件可帮助你轻松微调设置。

要求

支持的计划

Power BI Premium 每容量 型号、每用户 Premium 和 Power BI Embedded 型号都支持自动聚合。

支持的数据源

以下数据源支持自动聚合：

Azure SQL 数据库
Azure Synapse 专用 SQL 池
SQL Server 2019 或更高版本
谷歌BigQuery
Snowflake
Databricks
Amazon Redshift

支持的模式

DirectQuery 模式模型支持自动聚合。支持包含导入表和 DirectQuery 连接的复合模型。 DirectQuery 连接仅支持自动聚合。

Permissions

若要启用和配置自动聚合，你必须是 模型所有者。工作区管理员可以作为所有者接管以配置自动聚合设置。

配置自动聚合

在模型设置中配置自动聚合。配置很简单 - 启用自动聚合训练并计划一个或多个刷新。在为模型配置自动聚合之前，请务必全面阅读本文。它很好地了解自动聚合的工作原理，并可以帮助你确定自动聚合是否适合你的环境。准备好有关如何启用自动聚合训练、配置刷新计划和微调环境的分步说明时，请参阅 “配置自动聚合”。

优点

借助 DirectQuery，每次模型用户打开报表或与报表可视化效果交互时，数据分析表达式（DAX）查询将传递给查询引擎，然后作为 SQL 查询传递到后端数据源。数据源必须计算并返回每个查询的结果。与内存中存储的导入模式模型相比，DirectQuery 数据源往返可能既是时间和过程密集型，也可能会导致报表可视化效果中的查询响应时间变慢。

为 DirectQuery 模型启用后，自动聚合可以通过避免数据源查询往返来提升报表查询性能。预聚合查询结果由内存中聚合缓存自动返回，而不是由数据源发送到和返回。内存中聚合缓存中预先聚合的数据量是实际保留的数据量和数据源中详细表的一小部分。结果不仅是更好的报表查询性能，而且减少了后端数据源系统上的负载。使用自动聚合时，只有一小部分报表和即席查询会被传递到后端数据源，这些查询需要的聚合不在内存中缓存中，就像使用纯 DirectQuery 模式一样。

显示自动聚合处理的关系图。

自动查询和聚合管理

虽然自动聚合无需创建用户定义的聚合表并显著简化实现预先聚合的数据解决方案，但更深入地熟悉基础过程和依赖项有助于了解自动聚合的工作原理。 Power BI 依赖于以下内容来创建和管理自动聚合。

查询日志

Power BI 跟踪查询日志中的模型和用户报表查询。对于每个模型，Power BI 维护 7 天的查询日志数据。查询日志数据每天向前归档。查询日志是安全的，不对用户或者通过 XMLA 终结点可见。

训练作业

作为您所选的刷新频率（日或周）第一次计划的模型刷新操作的一部分，Power BI 首先启动一个训练操作，用于评估查询日志，以确保内存聚合缓存中的聚合能够适应变化的查询模式。创建、更新或删除内存中聚合表，并将特殊查询发送到数据源，以确定要包含在缓存中的聚合。但是，在训练期间，计算的聚合数据不会加载到内存缓存中，而是在后续的刷新操作期间加载。

例如，如果选择“日”频率，计划刷新时间为凌晨4:00、上午9:00、下午2:00和晚上7:00，则每天只有凌晨4:00的刷新将同时包括训练操作和刷新操作。随后的 9:00AM、2:00PM 和 7:00PM 的刷新操作是当天安排的仅刷新操作，用于更新缓存中现有的聚合。

训练和刷新操作图。

尽管训练操作评估了查询日志中的过去查询，但结果足够准确，从而确保将来的查询能够覆盖。但是，无法保证将来的查询将由内存中聚合缓存返回，因为这些新查询可能与从查询日志派生的查询不同。内存中聚合缓存未返回的查询将使用 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、Import（无论是否带增量刷新）或双重存储模式为表定义聚合，同时，未命中用户定义聚合表的 DirectQuery 查询连接可以享受到更自动化的聚合处理的好处。这种灵活性使平衡的体系结构能够减少查询负载并避免瓶颈。

自动聚合训练算法在内存中缓存中创建的聚合标识为 System 聚合。训练算法仅在分析报告查询时创建和删除这些 System 聚合，并进行调整以维护模型的最佳聚合。用户自定义聚合和自动聚合都通过刷新来更新。只有那些由自动聚合创建并标记为系统生成的聚合才会被包含在自动聚合处理中。

查询缓存和自动聚合

Power BI Premium 还支持 Power BI Premium/Embedded 中的查询缓存来维护查询结果。查询缓存与自动聚合不同。借助查询缓存，Power BI Premium 使用其本地缓存服务来实现缓存，而自动聚合在模型级别实现。使用查询缓存时，服务仅缓存初始报表页加载的查询，因此当用户与报表交互时，查询性能不会得到改善。相比之下，自动聚合通过预先缓存聚合查询结果来优化大多数报表查询，包括用户与报表交互时生成的查询。可以为模型启用查询缓存和自动聚合，但可能不需要。

使用 Azure Log Analytics 进行监视

Azure Log Analytics （LA）是 Azure Monitor 中的一项服务，Power BI 可用于保存活动日志。使用 Azure Monitor 套件，可以收集、分析和处理来自 Azure 和本地环境的遥测数据。它提供长期存储、即席查询接口和 API 访问，以允许数据导出和其他系统集成。若要了解详细信息，请参阅在 Power BI 中使用 Azure Log Analytics。

如果使用 Azure LA 帐户配置 Power BI，如配置适用于 Power BI 的 Azure Log Analytics 中所述，可以分析自动聚合的成功率。除其他事项外，还可以确定是否从内存缓存中响应报表查询。

若要使用此功能，请下载 PBIT 模板并将其连接到 Log Analytics 帐户，如此 Power BI 博客文章中所述。在报表中，可以在三个不同的级别查看数据：摘要视图、DAX 查询级别视图和 SQL 查询级别视图。

下图显示了所有查询的摘要页。可以看到，标记的图表显示聚合所满足的查询总数与必须使用数据源的查询总数的百分比。

聚合阶段的日志分析查询的屏幕截图。

深入研究的下一步是查看在 DAX 查询级别上聚合的使用。右键单击列表中的 DAX 查询（左下角）透视查询历史记录。

显示 Log Analytics 查询历史记录的屏幕截图。

这将为你提供所有相关查询的列表。深入到下一级别以显示更多聚合详细信息。

显示日志分析查询历史记录钻取的屏幕截图。

应用程序生命周期管理

从开发到测试和从测试到生产，启用了自动聚合的模型对 ALM 解决方案有特殊要求。

部署管道

使用部署管道，Power BI 可以将模型及其模型配置从当前阶段复制到目标阶段。但是，必须在目标阶段重置自动聚合，因为设置不会从当前阶段传输到目标阶段。还可以使用部署管道 REST API 以编程方式部署内容。若要了解有关此过程的详细信息，请参阅使用 API 和 DevOps 自动执行部署管道。

自定义 ALM 解决方案

如果使用基于 XMLA 终结点的自定义 ALM 解决方案，请记住，解决方案可能能够将系统生成的聚合表和用户创建的聚合表复制为模型元数据的一部分。但是，您必须在目标阶段的每个部署步骤后手动启用自动聚合。当覆盖现有模型时，Power BI 将保留配置。

注释

如果将模型作为 Power BI Desktop （.pbix）文件的一部分上传或重新发布，则系统创建的聚合表会丢失，因为 Power BI 会将现有模型替换为目标工作区中的所有元数据和数据。

更改模型

** 更改通过 XMLA 终结点启用自动聚合的模型（例如添加或删除表）后，Power BI 会保留所有可能的现有聚合，并移除那些不再需要或不相关的聚合。在触发下一个训练阶段之前，查询性能可能会受到影响。

元数据元素

启用了自动聚合的模型包含唯一的系统生成的聚合表。报表工具中的用户看不到聚合表。它们在使用 Analysis Services 客户端库版本 19.22.5 及更高 的工具通过 XMLA 终结点可见。使用启用了自动聚合的模型时，请务必将数据建模和管理工具升级到最新版本的客户端库。对于 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 不会创建系统生成的聚合表。
如果修改启用了自动聚合的模型的元数据，查询性能可能会下降，直到触发下一个训练过程。最佳做法是删除自动聚合、进行更改，然后重新训练。
请勿修改或删除系统生成的聚合表，除非禁用了自动聚合并正在清理模型。系统负责管理这些对象。

Community

Power BI 拥有充满活力的社区，其中 MVP、BI 专业人员和同行在讨论组、视频、博客等中分享专业知识。了解自动聚合时，请务必查看以下其他资源：

反馈

此页面是否有帮助？

Last updated on 2026-01-14