powerbi的功能介绍_Power BI性能提升的5大秘密武器

Power BI无疑已经走了很长一段路，它以其作为自助服务工具的强大根基，易于使用的功能以及在企业领域的持续推动和推动而发展。但是，我们仍然可以发现许多开发和维护Power BI解决方案可以通过应用一些更改而受益匪浅，这些更改将导致Power BI解决方案响应速度更快，消耗的资源更少，更符合最佳实践并总体上表现更好。本文将和大家重点分享Power BI性能介绍和最佳实践的五大秘诀。

在Power BI中开发任何新的解决方案时，我们总是希望结合我们探索的所有技巧，以获取性能和最佳实践，因此，个人建议你也在整个Power BI开发过程中实施这些技巧。

秘诀一

减少列数，减少行数

在许多情况下，仅因为Power BI可以处理大数据量，我们才将所需数据加载到Power BI中。但是，随着解决方案开始向外扩展，这可能直接影响性能。通过选择“获取数据”按钮，适当的连接器以及连接类型（如果适用），将数据导入Power BI的过程完成后，我们还应该问自己以下问题：

这些列/行是否可以帮助我们分析数据？
这些列/行是否可以帮助我们进行决策？
我们将在计算中使用这些列/行还是建立关系？

如果有问题的数据要提取到Power BI中，但不满足上述条件，我们应该将其排除在解决方案之外。比如：当仅需要分析今年的当前绩效与上一年的对比时，为什么要提取最近5年的数据呢？当我们只需要产品名称的一列时，为什么要导入产品维度的所有描述性列？同样，在提取数据时很容易加载所有内容而不进行此过程，但是要确保我们的Power BI解决方案消耗更少的资源并以最高的性能执行，我们应该使查询包含更少的列（窄）和更少的行（短）。

为了在上面添加一些细节，在将数据提取到Power BI中时，该过程将通过Power Query进行任何数据整形和数据转换操作，然后将数据加载到Power Pivot中，该数据是一个压缩的列式数据库，用于存储数据通过VertiPaq引擎存储在内存中。现在，我们不打算详细介绍VertiPaq引擎，但是要摆脱这一点非常重要的一件事是，VertiPaq引擎是列式存储引擎，因此可以压缩列。出于这个原因，我们应该更加注意我们要摄取的列数，而不是行数。这在下图中突出显示，我们最好少列多行。

秘诀二

将转换推向源端

Power Query是功能强大的数据转换和数据整形工具，可以轻松地直接在Power BI中直接处理转换。实际上，它是一个很棒的工具，我们可以尝试在Power Query中进行所有操作。但是，很多时候我遇到过使用各种类型的转换来处理数以千万计的行的解决方案，因此可以通过将一些工作负载推回源头来提高性能。

将工作负载推回源端，意味着什么？让我们分解一下以理解它。打开Power BI Desktop时，它是一块空白画布，因为平台中不存在任何数据，因此我们要做的第一件事是选择“获取数据”。从这里开始，我们选择合适的连接器以将数据提取到Power BI中。然后，我们可以选择“转换数据”，这将打开Power Query（相当于单击功能区中的“ Edit Queries”）。在Power Query中时，我们可以应用各种转换来成形数据，但是，重要的是要了解，在此阶段，我们仅将内存中的前1000行存储为预览。

Power Query首先将前1000行存储在内存中，然后在“应用的步骤”窗格中应用转换。

毕竟，这是有道理的，可以想象在使用Power Query并等待应用转换时将所有数据存储到内存中，这肯定会增加等待时间。实际上，这等效于每次应用转换时单击“关闭并应用”。因此，一旦我们完成所有转换的应用并且我们的数据处于预期格式，则单击“关闭并应用”，Power Query会将数据加载到Power Pivot，后者将所有数据存储到内存中，然后在已应用的步骤窗格中应用转换。

单击“关闭并应用”后，Power Query会将所有数据加载到Power Pivot并在已应用步骤窗格中应用转换。

现在我们已经掌握了以上知识，让我们回到将工作量推回源头意味着什么的问题？由于Power BI将数据存储在内存中，因此将所有数据加载到内存中然后应用转换效率要低得多，而不是直接在源中应用任何转换并将结果集简单加载到Power BI中。减少了处理数据导入所需的资源数量，并提高了查询性能。

现在，这可能意味着需要对基础数据源进行一些工作，在某些情况下，由于缺乏基础技术的技能，权限级别或适当的团队来执行所需的更改的等待时间，这些数据可能会受到一些阻碍。这将我们带到了查询折叠机制，该过程是将直接在Power Query中应用的所有转换（用M语言编写）转换为基础数据源的本地语言的过程，因此所有转换都不会在您的计算机上完成，而是在源代码方面。

您可以直接在Power BI Desktop中利用查询折叠功能，但是您应该注意一些因素，例如：

基础数据源必须支持接受查询折叠请求的概念。这包括关系数据库，OData源（例如SharePoint列表），Exchange和Active Directory。
并非所有类型的转换都支持查询折叠，例如，如果您具有“删除最前面的行”，则不会将其发送回源端。
一旦应用了不支持查询折叠的转换步骤，接下来要执行的所有其他步骤将要求首先将数据加载到内存中。

秘诀三

禁用查询负载

在许多性能优化的方案中，我发现许多表已加载到Power BI中，这些表不用于报告，建立关系或创建计算。在继续之前，任何加载到Power Query中的查询都将加载到Power Pivot，因此会消耗宝贵的内存。现在，存在这些表的常见原因是它们在Power Query中充当登台表，因此仅被摄取以转换另一组数据。

例如，你已经将包含所有员工详细信息的数据集“ A”摄取到Power BI中，但是，对于必须执行的分析，需要“ NI”列，该列存储在名为数据集“ B”的另一源中。因此，数据集“ B”也被加载到Power BI中，仅用于与数据集“ A”进行合并，并派生列“ NI”。

完成此操作后，通常可以将数据集“ A”和数据集“ B”都加载到Power Pivot中。请停止这步习惯性的操作吧！我们应该右键单击数据集“ B”，然后取消选择“启用负载”，这将禁用Power Query将该查询加载到Power Pivot中，因此不会不必要地消耗内存。

当我们禁止将查询加载到Power Pivot时，这并不意味着诸如刷新之类的转换将在刷新时中断。两个数据集之间在Power Query中应用的所有转换步骤都将运行，就像从未禁用该查询一样。唯一的区别是，它将不会加载到模型中并且无法用于报告，因此减少了内存消耗。

秘诀四

删除高基数列

在我们继续进行此技巧之前，重要的是要了解高基数列是指Power BI中提取的具有唯一值百分比很高的列。如前所述，数据已加载到Power Pivot（这是一个压缩的列式数据库）中，我们之所以要删除高基数列，是因为压缩高基数列时压缩工作效率低得多。

列包含的唯一值越多，压缩的效率就越低。

我们经常用来解释高基数列的示例是Power BI中通常提取的列，即“ DateTime”。如果我们使用的是三年的数据，则唯一日期的计数将为1095。现在，如果将日期和时间合并为一个列，则必须将1095乘以所有可能的时间组合。因此，如果我们存储的时间属性是一天中的小时，则“ DateTime”列中的单个值的格式为dd-mm-yyyy hh，则唯一值的数量将超过1095，而是乘以所有可能的时间值24，因为我们一天中有24小时。因此，从1095个唯一值开始，我们现在得到1095乘以24，即26,280。如果我们还有分钟和几秒钟，那么唯一值的数量将急剧增加，从而导致压缩效率降低。

要识别高基数列，我们可以使用Power Query中提供的“列分布”之类的功能，甚至可以更好地使用我们建议使用VertiPaq分析器来识别高基数列。重要说明，如果您在Power BI中使用列分配功能，则除非更改，否则这仅适用于前1000行。

秘诀五

与星型图对齐

这是迄今为止官方一直推荐的Power BI中最重要的性能提示。实际上，至关重要的是，我们也将继续努力推动将你的数据建模为接近星型模式，解决你当前不知道的问题，并阻止在以后出现的问题。如果在创建Power BI解决方案时需要执行任何操作，则将使模型与Kimball Star Schema接近。

星型模式可以以较少的表和较少的关系来对Power BI中的数据进行建模，从而使所有内容尽可能地接近。

它由一个包含有用于测量的数字属性的事实表组成。考虑一下诸如收入或可用库存之类的数字列，这些数字列经过汇总和计数，以帮助我们进行数据分析。此外，星型模式在Fact表周围包含Dimension表，这些表具有用于向数字属性提供上下文的描述性属性。例如，我们通过“库存情况表”知道我们有300个可用库存项目，但是通过“产品尺寸表”，我们知道哪个特定项目。

使用星型模式的主要原因是为了更快地检索数据和创建可伸缩的BI解决方案。为了进一步分解，将数据建模为星型模式所带来的一些好处是：