DirectQuery 模式下的 AAS 表格模型性能优势答案

【问题标题】：AAS tabular model in DirectQuery mode performance benefitsDirectQuery 模式下的 AAS 表格模型性能优势
【发布时间】：2020-02-05 23:29:01
【问题描述】：

假设您有 10 个相当大的事实表（每个 50-100 GB），应该使用 Power BI 进行查询。它们不适合 Azure Analysis Services RAM（价格合理）。因此，为了使用表格模型和 AAS，您必须使用以下模式：

(1) Power BI Desktop -> Azure Analysis Services -> [DirectQuery] -> SQL Database

但据我从this article 得知，AAS 表格模型不会缓存任何聚合结果（意味着不会暗示任何额外的性能优化）。此外，AFAIK、Power BI (PowerPivot) 已经嵌入了 AAS。

作为替代方案，我可以直接从 Power BI 查询 SQL 数据源：

(2) Power BI Desktop -> [DirectQuery] -> SQL Database

第一个模式（使用 AAS）是否比第二个模式（不使用 AAS）提供任何性能优势？

附：我的问题不是关于语义层的优缺点，请参阅this article。这个问题与this question 不同，因为它只询问 ASS DirectQuery 的性能方面。

【问题讨论】：

我不是来回答这个问题的，因为我不了解 AAS，但几个月前 PowerBI 发布了（聚合）[docs.microsoft.com/en-us/power-bi/desktop-aggregations]，它们是隐藏在模型中的聚合表。这些可能会有所帮助，因为您有巨大的桌子。
好点@GiovanniLuisotto！ @VB 你真的需要所有 50 GB 的原始信息吗？你不能在后端执行一些有意义的聚合吗？然后，AAS 压缩将进一步减小您的表大小。
@Seymour 不幸的是，有些报告是建立在交易粒度数据之上的。但是我们找到了一个解决方案（根本不使用 AAS） - 使用维度模型可以在以下两者上构建报告：聚合表和事务表。意味着只有极少数百分比的请求会发送到事务级表。
你用的是什么工具？
@Seymour Power BI，如果你是这个意思的话。

标签： powerbi dax powerpivot ssas-tabular azure-analysis-services

【解决方案1】：

性能优势需要根据您的工作负载和其他因素进行测试。

警告（此答案基于我自己和我的同事的经验和测试）

服务标准： 从服务的角度来看，Azure 分析服务 (AAS) 和 Power BI 服务 (PBIS) 之间的主要区别在于 AAS 是一组已知的硬件/性能，而 PBIS 是共享容量，并且可以遭受“吵闹的邻居”问题，如果另一个客户在同一个集群上并大量使用它，则会对您的报告性能产生影响。

性能： 本质上，PBI 和 AAS 做同样的事情，将 DAX 转换为 SQL 查询，然后返回数据。根据我在性能方面构建 PBI 和 AAS 的经验，两者之间没有太大区别。往往成为瓶颈的主要问题是使用本地 SQL 的网关以及本地或云中 SQL Server 的容量。例如，为了获得更好的性能，您可以使用聚集列索引将事实表带入内存，并且在工作时间更容易增加/减少 Azure SQL 数据库 DTU 的/容量。

目前 AAS 没有 PBI 的聚合模式，这可以减少发回的查询数量并且速度更快，但也有一个缺点，即它们必须在某些时候刷新。

我建议使用例如 DAX Studio 进行测试，以了解您可能会在性能方面获得哪些变化。我自己的测试表明，有利于 AAS 在毫秒到 1 秒范围内的差异。

然而语义层的好处是一个重要的考虑因素

连接： AAS 比 Power BI 更支持 Excel、SSMS、SSRS 等其他连接。 Excel 可以通过附加插件连接到 Power BI 模型。

可维护性： 在 Visual Studio/SSDT 中使用 Azure DevOps、Git 等维护数据模型的整个生命周期要比在 Power BI Desktop 中容易得多。使用 AAS，您还可以使用计算组进行时间智能计算，而不是 YTD、并行周期、MTD 等的多个度量或解决方法

如果纯 Power BI 方法的性能稍好一些，我仍然会使用 AAS，因为没有性能因素的好处，它必须在切换之前显示出显着提高的性能。

希望有帮助

【讨论】：