通过 Direct Query 连接到 Azure 专用 SQL 池的 Power BI 报表性能缓慢

Posted 2023-03-25

【中文标题】通过 Direct Query 连接到 Azure 专用 SQL 池的 Power BI 报表性能缓慢

【英文标题】：Slow performance of Power BI report connected to Azure Dedicated SQL pool via Direct Query

【发布时间】：2021-05-08 19:55:41

【问题描述】：

总结

我有一个简单的 Power BI 报告，其中包含 3 个 KPI，刷新需要 0.3 秒。将数据移动到 Azure 专用 SQL 池后，相同的报告需要 6 秒才能刷新。目标是在 5 秒内加载一份报告，其中应用了 10-15 个 KPI 和多达 10 个过滤器，并连接到更大（数百万行）的数据集。

如何提高通过 Direct Query 连接到 Azure 专用 SQL 池的 Power BI 的性能？

更多详情

设置：专用 SQL 池 > Power BI（直接查询）

数据：3 个表（行 x 列：4x136 用户表、4x3000 日期表、8x270.000 主表）

数据模型：主表到日期表连接 - 基于“日期”类型字段的多对一。主用户连接 - 基于 user_id (varchar(10)) 的多对一。使用的其他数据类型：日期、整数、varchars（50 和更少）。

专用 SQL 池性能级别为 Gen2：DW200c。但是，使用的 DWU 数量从未超过 50 个，通常保持在 15 个以下。

报告： 该报告包括基于相同公式计算的 3 个 KPI（只是“5 个符号文本”不同）：

KPI 1:=
CALCULATE(
    COUNTA('Table Main'[id]),
    CONTAINSSTRING('Table Main'[varchar 50 field 0], "5 symbols text"),
    ISBLANK('Table Main' [varchar 50 field 1]),
    ISBLANK('Table Main' [varchar 50 field 2])
    )

报告包括 6 个过滤器：5 个“基本过滤”，选择了 1 个或多个值，1 个“字符串包含”过滤器。

问题： 显示 3 个 KPI（仅 3 个数字）的视觉效果需要 6…8 秒才能加载，这非常多，尤其是在需要添加更多 KPI 和过滤器的情况下。 （相比之下，如果所有数据都加载到 .pbix 文件中，则为 0.3 秒）。这是一个问题，因为在页面 (10-15) 上添加更多 KPI 会按比例增加加载时间，对于计算更复杂且报告变得无法使用的 KPI，加载时间甚至更长。

问题： 是否可以显着提高报表/AAS/SQL 池的性能（快 2…10 倍）？如何？ 如果没有，是否可以以某种方式将计算出的 KPI / 可视化内容缓存在报告或 AAS 中，而无需每次都查询数据，也无需将数据保存在 pbix 或 AAS 模型中？

尝试过的解决方案无效： 聚集列存储、聚集行存储、非聚集行存储索引的单独使用和不同组合。自动统计开/关。自动化索引和统计数据确实提高了 10…20%，但这绝对不够。

简单的值列表（任何表中的 1 列）需要 1.5 到 4 秒才能加载）

我的尝试

将 SQL 池从西欧移动到法国并返回。没有改进

应用索引：行和列存储、集群和非集群、手动和自动定义（包括统计信息） - 性能提高了 10...20%，但这并不能解决问题。

更改资源类：smallrc、largerc、xlargerc。使用的 DWU 百分比仍然从未超过 50（200 个）。没有改进

缩小数据格式并删除多余的数据：最小的 nvarchar(n) 可能，最大的是 nvarchar(50)，所有多余的列都已删除。没有改进

隔离模型：我有一个更大的数据模型，为了测试目的，我将 3 个表隔离到一个单独的模型中，以确保其他部分不会影响性能。没有改进。

减少 KPI 和过滤器的数量 仅剩下 2 个报告过滤器（仅限主表字段），加载视觉对象需要 2 秒。在连接的日期表上使用 +2 过滤器 2.5 秒，在用户表上使用 +2 过滤器 6 秒。这意味着我只能使用 1-2 个过滤报告，这是不可接受的。

【参考方案1】：

不幸的是，这是一个反复试验的过程。以下是您的列表中尚未列出的一些内容：

基于 user_id (varchar(10)) 的多对一 -> 添加一个 numeric 列，它是 hash 的 user_id 列，并使用它来加入而不是 varchar列。 确保您的 statistics 是最新的。 试试Dual mode。在内存中加载较小的维度表并将事实表保存在数据库中。 使用aggregates，这样除非用户尝试向下钻取，否则报表实际上会在不查询数据库的情况下填充。 Partition your fact table 通过相应的列。 确保您在事实表中使用right distribution 并选择了正确的列。

小心分区和分布。 Synapse 的设计与传统的 RDB（如 mysql）略有不同，它在某种程度上更接近 NoSQL DB，但并不完全如此。因此，在使用这些概念之前，请先了解这些概念在 Syanpse 中的工作原理（否则您的性能可能会更差）！

【讨论】：

谢谢。这些建议很有帮助。我还添加了以下操作：1) 启用 RESULTS_SET_CATCHING 2) 添加物化视图（尽管我仍在努力使其正常用于我的查询）。在性能改进方面，最好的是：1）双模式 2）聚合 3）结果缓存 4）物化视图 5）表的正确分布

好消息！好奇，numeric 而不是 varchar 列根本没有提高连接性能吗？还是不够？