织梦如何生成网站地图,网站开发如何赚钱,网站如何做微信支付,wordpress 手机 主题Power BI无疑已经走了很长一段路#xff0c;它以其作为自助服务工具的强大根基#xff0c;易于使用的功能以及在企业领域的持续推动和推动而发展。但是#xff0c;我们仍然可以发现许多开发和维护Power BI解决方案可以通过应用一些更改而受益匪浅#xff0c;这些更改将导…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解决方案。为了进一步分解将数据建模为星型模式所带来的一些好处是简洁性易于阅读使用和理解。事实包含要测量和计数的数字属性而维度包含要过滤的描述性属性性能较少的表以及表之间的关系较少因此增加了数据检索时间功能充分利用Power BI的向下钻取追溯和其他各种功能来分析数据模型大小由于限制表和关系的数量减少了消耗的内存量可扩展性易于扩展以适应新的尺寸列和度量从上面我们分享的所有技巧中可以轻松地将数据模型与星型架构对齐这是我们应该一直努力实现的最重要的技巧。更多Power BI 技巧请关注小悦后续会有更多关于Power BI 性能技巧文章哦推荐阅读Power BI模型中星型架构的重要性一mp.weixin.qq.comPower BI模型中星型架构的重要性二mp.weixin.qq.com【2020】Power BI 3月产品功能更新mp.weixin.qq.com
