通过直接查询连接到 Azure 专用 SQL 池的 Power BI 报告性能缓慢

编程问答 2022-05-27

问题描述

总结

我有一个简单的 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，这些 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 倍）？如何？ 如果不是，是否有可能以某种方式在报表或 AAS 中缓存计算出的 KPI/可视化内容，而无需每次都查询数据，并且无需将数据保留在 pbix 或 AAS 模型中？

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

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

我的尝试

  1. 将 sql 池从西欧移到法国再移回。没有改进

  2. 应用索引：行存储和列存储、集群和非集群、手动和自动定义（inl. 统计）- 性能提高了 10...20%，但并没有解决问题。>

  3. 更改资源类：smallrc、largerc、xlargerc。使用的 DWU 的百分比始终不会超过 50（200 个中）。没有改进

  4. 缩小数据格式并去除多余的数据：最小的nvarchar(n)，最大的nvarchar(50)，所有多余的列都被去除了。没有改进

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

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

解决方法

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

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

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

azureazureazureazure-sql-databaseazure-synapsepowerbisql-server