速度是 Direct Query 的绊脚石
不幸的是，直接查询常常被证明太慢了。对此的一种解释是，Power BI 会针对屏幕上的每个视觉效果向底层数据库发送查询。对于某些仪表板来说，这个数字可能会有几十个。即使对于像 Snowflake 这样的快速数据库，处理如此大量的查询也需要几秒钟。
直接查询显示速度是多少
通过一些努力和创造力，我们成功将测试页面的性能从三个测试用例的平均测试分数 7,879 毫秒提高到三个测试用例的平均测试分数 873 毫秒，速度提高了近 10 倍！报告在视觉方面仅做出了非常有限的让步。
使用 Power BI 中的直接查询实现卓越性能的分步指南
Snowflake - 仓库设置
Snowflake 中有几个设置会影响性能。首先，我们来看一下虚拟仓库。虚拟仓库提供检索数据的计算能力。
虚拟仓库大小
您可以为仓库选择不同的大小。不要简单地将仓库从XS增加到S或M，经验表明，更大的仓库往往会导致 性能下降。对于大型数据集和/或复杂查询，更大的仓库更有可能产生积极影响，因为在这种情况下工作分布在多台机器上。在我们的案例中它之所以没有效果，可能是因为划分工作所花费的时间比它节省的时间还多。
查询加速速度。在这项研究中，这对性能有积极的影响，但时间（阅读：在不同项目中使用直接查询的更多经验）将证明是否总是如此。在仓库上启用查询加速并测量对性能的影响，以确定此选项是否适合您的情况。
雪花 - 模型
除了仓库之外，所使用的数据模型也对性能有很大影响。多年来，星型模式一直是设计 BI 数据模型的方法。我们将这条路径留给我们的仪表板。
创建一个大表
根据事实和周围的维度创建一个表。为此，选择仪表板（或多个仪表板）所需的所有属性（测量值和维度属性）。将其保存在 1 个表中，即“一个大表”。这是包含信息区域所有信息的一张表，因此没有单独的维度表。
在 Snowflake 中我们可以通过定义动态表来实现这一点。这是一种由 Snowflake 物理写入数据库的数据库视图。但当然也可以为此创建一个 ETL 流程。
然而，有时除了“一个大表”之外，可能还需要创建其他表。这些表 墨西哥电报数据 是维度的小子集，例如在以下情况下需要它们：
优化性能较差的选择器或使用不区分大小写的搜索功能。
链接一个报告页面上使用的多个事实表，这些事实表不能合并为一个大表。
自定义生成器。 除了创建一个大表之外，在 Snowflake 中 定义一个物化视图也很有趣 ，其中来自一个大表的数据在聚合级别上进行计算。如果您的仪表板包含详细信息页面，但也显示每月的信息，那么这可能是一个有用的选项。 如果对于相关的报告页面来说足够的话， Snowflake 将自动使用来自物化视图的聚合信息 。这可以进一步提高性能。
聚类键。 这决定了数据存储的排序。通过将聚类键放在仪表板上的选择器上，Snowflake 将能够更快地提供所请求的数据选择。对聚类键中字段的顺序进行试验。
Snowflake 中的所有逻辑。 理想情况下，您只需要对 Power BI 中的列执行类似 SUM 的计算。这可确保 Power BI 中仅请求报告所需的数据。为了给用户提供最佳性能，有时需要仔细考虑这一点，例如：
尽量避免平均值等等。