实现聚合
当语义模型为大型事实数据表（包含数亿或数十亿行的表）提供报表时，甚至优化 DAX 和减少基数可能不够。 聚合提供了一种提前汇总数据的方法，以便常见查询从小型、快速的内存中缓存返回结果，而不是扫描整个详细信息表。
了解在何种情况下聚合有帮助
当存在三个条件时，聚合最有价值：
- 大型事实数据表。 无法将包含数亿行的表完整地加载到内存中。
- 常见查询模式。 用户经常按摘要级别（按月、按区域、按产品类别）而不是单个事务级别进行查询。
- DirectQuery 或复合模型。 详细信息数据位于外部源中，往返查询速度较慢。
聚合功能的工作原理是：先将预先计算好的摘要数据存储在一个导入模式表中，随后查询引擎会首先该表。 如果可以从聚合中应答查询，则结果会立即从内存中返回。 否则，查询将流向详细信息表。
你可以将聚合功能理解为一篇长篇报告最前面的那份执行摘要。 大多数读者从摘要中获取所需的内容。 只有需要完整详细信息的用户才能阅读整个文档。
处理用户定义的聚合
用户定义的聚合可让你完全控制汇总和存储的内容。 若要实现它们，需要：
- 创建聚合表。 在 Power Query 中创建一个表，该表按照所需粒度汇总事实表。 例如，按产品类别和区域而不是单个交易汇总每日销售额。
- 配置聚合映射。 在Power BI桌面的模型视图中，选择聚合表并打开 管理聚合。 将每列映射到其相应的详细信息表列，并指定聚合函数（Sum、Count、Min、Max、GroupBy）。
- 隐藏聚合表。 聚合表应对报表作者隐藏。 查询引擎会自动使用它们：用户不需要知道它们存在。
- 设置存储模式。 聚合表使用导入模式进行内存中快速访问。 详细信息表通常使用 DirectQuery，因此无需将数十亿行加载到内存中。
当视觉对象查询与聚合的粒度和函数匹配的数据时，引擎将从 Import 表返回结果。 当查询需要更精细的粒度时，它会透明地传递到 DirectQuery 详细信息表。
注释
用户定义的聚合需要复合模型（具有混合存储模式的表）。 聚合表为 Import，详细信息表为 DirectQuery。 这两个表都需要将关系与同一维度表匹配。
使用自动聚合
自动聚合通过使用机器学习来确定要汇总的内容来简化此过程。 Power BI分析查询日志并自动创建、更新和删除基于实际使用模式的聚合，而不是手动创建和映射聚合表。
若要启用自动聚合，请执行以下操作：
- 在Power BI 服务中打开语义模型的 Settings。
- 启用自动聚合训练。
- 安排一个或多个数据刷新。
在第一个训练和刷新周期中，Power BI评估查询日志（存储 7 天的查询数据），并创建内存中聚合表。 系统持续适应：随着查询模式的变化，聚合方式会调整以优先考虑最常被请求的摘要。
自动聚合有几个要求：
- Premium、Premium Per User 或 Fabric 容量
- 需要聚合的表的 DirectQuery 存储模式
- 支持的数据源（Azure SQL 数据库、Synapse、Databricks、Snowflake 等）
可以在同一模型中同时使用用户定义的和自动聚合。 用户定义的聚合处理已知静态模式，而自动聚合则适应更改查询行为。
监控聚合的有效性
实现聚合后，请验证它们是否正在使用：
- 查看刷新历史记录。 在模型的设置中，刷新历史记录显示聚合缓存使用的内存量及其服务的查询数。
- 使用Azure Log Analytics。 如果你的容量连接到 Azure Log Analytics，你可以分析由聚合提供的查询与直接命中数据源的查询的百分比。 这提供了 DAX 和 SQL 查询级别的聚合命中率的详细视图。
如果查询缺少聚合（转为使用 DirectQuery），请检查查询模式。 聚合可能不会涵盖用户所请求的细节或功能。
聚合和 Direct Lake
在Microsoft Fabric中，使用 Direct Lake 存储模式的语义模型直接从 OneLake 中的 Delta 表读取，而无需将数据导入内存或发送 DirectQuery 查询。 对于许多场景，Direct Lake 已经很快，因为它避免了数据导入和外部查询来回的开销。
聚合功能在以下情况下可以作为 Direct Lake 的补充：
- 基础 Delta 表非常大，常见查询只需要摘要级结果。
- 对于那些频繁被查询的模式，你需要减少最终加载到列段中的实际数据量。
对于大多数 Direct Lake 模型，首先测试性能而不进行聚合。 仅当度量显示明确需求时，才添加它们。