Power BI 傻瓜入门 20. 使用Power BI优化DAX的十种方法

Martin-Mei

于 2023-11-02 13:54:06 发布

阅读量657

点赞数 5

分类专栏： Power BI入门文章标签： powerbi Power Platform

本文链接：https://blog.csdn.net/mwjcxl/article/details/134177665

版权

Power BI入门专栏收录该内容

21 篇文章 9 订阅

订阅专栏

数据分析表达式（DAX）语言是一种在许多Microsoft产品中使用的公式表达式语言。如果您曾经使用过Analysis Services、Excel中的Power Pivot或Power BI等产品，那么您已经对DAX略知一二了。在许多情况下，Power BI中用于对关系表中的数据执行高级计算和查询的函数、运算符和值与其他Microsoft产品中使用的函数、操作符和值相同。然而，通过Power BI，微软创建了仅适用于其企业商业智能产品的特定利基DAX功能。

在本章中，将展示如何考虑仅在Power BI中发现的那些特殊功能。此外，您还看到了在使用Power BI时完善DAX代码的一些关键方法。

关注逻辑

性能优化是建模数据、数据库交付和数据提取的关键。这就是为什么，当您设计高质量的数据库层时，实际上是在为支持DAX数据效率的优化数据模型设置路径。

在创建数据模型和数据库层时，应重点确保字段正确映射、具有预期用途且缺乏冗余。这不仅有助于您最大限度地减少使用DAX计算列、计算表和度量的需求，而且还可以使用Power BI提供总体上更快的输出体验。不要因为在更复杂的活动中进行计算而过度应付性能挑战，从而导致DAX环境变慢。

例如，带有DAX的DirectQuery模式有一些显著的限制。确保模型绝对没有逻辑引用。如果您使用的是DirectQuery，由于它的自动化，这已经意味着性能会受到影响，因此添加DAX表达式会产生显著的滞后。

另一方面，导入模型模式也带来了自身的挑战。由于此模式支持内存模型，因此需要避免任意提供数据模型的业务逻辑。提要的随机使用只会减慢模型的处理速度。您当然可以在视图中使用过滤器，但如果这样做，请确保在部署过滤器时尽量减少所需的逻辑。（在这种情况下，最小化过滤器逻辑意味着不在同一环境中多次实现同一过滤器。）

无论您是遵循DirectQuery模式还是导入模型模式，实现逻辑的一个可靠方法是将逻辑放入创建表的存储过程中，使您的模型能够重用逻辑。通过这样做，您可以创建相同的一组表，并创建一个真理的单一来源。此外，在应用大表时，应该实现索引——理想情况下是集群列存储。

设置代码格式

对于您来说，拥有自己奇特的代码命名方式并不罕见。每个人都有自己的系统。如果你的代码只针对你自己，那么在这里和那里打破一些规则可能是可以的。注意单词“少数”，而不是“全部”。为什么？仅仅因为代码现在是为您准备的，并不意味着您以后不会与其他人共享示例。

你可能会注意到，例子中引用的所有内容都清楚地映射到一个表、列或行。
每个变量都是有意义的，并且与代码示例相关。常见的礼貌是确保别人在尝试阅读你的DAX代码时不会感到困惑。事实上，你不想有一天打开自己的代码样本，在想知道自己写了什么的时候挠头。

您的第一个目标是对所有代码进行一致的格式化，并仔细地编写文档。下面是一个文档充分、格式化的代码示例：

Total Orders =
    IF (ISFILTERED ('Date Ranges'[Date Range]),
        CALCULATE (COUNTROWS ('Order Data'),
        FILTER ('Order Table',
        'Order Table'[Submit Date] >= [Commit Date]
        && 'Order Table'[Submit Date] <= [Ship
        Date]) ),
            COUNTROWS ('Order Data') )

遵循以下最佳实践可以帮助您保持代码的整洁：

如果引用新函数或度量值，则总是缩进新行。
在开括号和闭括号前后放置空格，以确保实现数据的上下文。
为了便于阅读，请始终在+、–和=等运算符周围放置空格。
不要用不必要的变量、函数和公式使代码过于复杂。
永远不要随意创建项，也不要给表起与度量相同的名称。它只会让您或其他开发人员感到困惑。
除非引用列名的来源表，否则永远不要包含列名。

保持结构简单（KISS）

你可能还记得年轻时的某个化身中的“保持简单”这句话。这句话也适用于Power BI和DAX：您制作的表和列越复杂，就越有可能遇到两个问题。首先，当谈到取得成果时，您会立即看到绩效的提升。其次，很难决定什么是必要的，什么是任意的数据。

简单地说，重要的是只包括模型中探索业务问题所绝对需要的表和列。当您添加的代码超过必要数量时，会导致内存使用过度，用户复杂性增加，并且可能会无意中增加数据量。所有这些项目都会导致性能下降。您正试图减少模型中的列数和行数。

少即是多——你的目标是找到精确性和准确性。
当您对数据进行重新设计以实现简单性时，您可能需要对删除了列的事实表进行返工——这些表需要重新聚合。在几乎所有条件下，模型越小，性能越好。

可能禁止数据缩减的一个条件涉及唯一ID。一个例子是一个主键，如TransactionID或ProductID，用于简单地计数项目。这些类型的柱为创建轻量级模型创造了令人望而却步的环境。这里的教训很简单：在使用唯一数据和DAX之前要三思而后行。

避开某些功能

你有没有听过一句老话，“我不会用十英尺长的杆子碰它？”它适用于某些功能，因为对Power BI性能和潜在数据输出的影响可能对你的数据集有害。避免使用SEARCH、IFERROR、CONTAINS和INTERSECT等基本功能。
让我们深入了解一下：

确保您具有成本效益和商业头脑的一个好做法是在选择DAX函数的过程中使用最佳实践分析器（BPA）。当你使用BPA时，请检查使用相同功能的真正价值，因为它通常缺乏效率，而且成本高昂。

就内存和处理负载而言，SEARCH是使用成本最高的函数之一，因为它要求系统扫描每一行以查找给定的值。换句话说，没有搜索快捷方式。使用DAX更有效地处理搜索的一种方法是在数据库中创建一列。然后，将该列作为数据列引入模型中。SEARCH必须执行动态操作；
因此，对于函数，在潜在地使用度量时需要利用SEARCH。如果无法在数据库中创建新列，请考虑创建计算列。您需要让测量值参考列。

IFERROR是Microsoft Excel中的一个良性函数。但是，当它在Power BI中使用时，您可能会遇到性能问题。使用更简单的函数，如DIVIDE，它使用内置进程更容易地解决零错误，减少了许多错误，并支持更快的性能。

使用需要过度解析的函数，尤其是在虚拟映射关系时，效率可能非常低。同样，这个问题与性能问题有关。分析数据越多，用户的性能下降程度就越高。对虚拟关系使用CONTAINS或INTERSECT并不罕见。两者都需要在表关系之间进行大量交互。这就是为什么您应该考虑使用更灵活的函数，如TREATAS。而使用CONTAINS和INTERSECT，您可以解析整个数据集，TREATAS几乎将列数据过滤为特定列集中的有限数据集。

让你的措施有意义

使用特定DAX功能有时间和地点。措施的使用也不例外。当然，您可以使用计算列来计算列，但寻找数据效率不是更有意义吗？在组合中引入度量不会对数据模型产生负面的性能影响。
考虑到在某些情况下无法通过单独使用计算列来操作数据，度量是一种可靠的替代方法。许多数学、统计学和三角计算都需要度量，因为它们不能单独使用计算表来完成。

无论您是尝试使用基本DAX函数，还是编写复杂的DAX函数代码，都必须了解Power BI确实允许用户隐式聚合列。在Power BI中，当您想快速测试可视化的执行情况时，隐式度量可能会有所帮助。
另一种选择是使用DAX创建显式度量。在这种情况下，您的意图是创建集中的计算。以下是为DAX创建可重复的度量可能有意义的原因，即使它稍微复杂一些。通过应用以下任一学派来考虑数据集：

Power BI应该表现得像Excel。这意味着将隐式度量值与工作簿数据结合使用。这意味着大量使用两个函数：SUM用于数字数据，COUNT用于文本数据。使用Power BI Desktop时，任何数字列都可以使用“汇总方式”属性。
Power BI应明确定义所有度量。通过显式定义度量，模型支持数据控制，因为开发人员正在对行为进行编码。尽管这种方法可以为开发人员提供更多的灵活性，但它可能并不总是能在一开始就产生您想要的确切结果。可能需要进行修订，但如果经过一段时间的完善，可能会产生重大结果。

有目的的筛选

FILTER函数使用过度。尽管它的主要目的是根据度量值筛选列，但要仔细思考为什么要使用该筛选器。如果过滤只针对列值，则不需要使用FILTER函数。事实上，当使用FILTER功能时，当目的没有明确定义时，您的Power BI性能会下降。让我们看几个例子，从你不应该做的事情开始：

BID = CALCULATE ([PROFIT], FILTER ('State', 'State'[Country] = "United States"))

避免使用本例中使用的逻辑——不必要地过滤每一行。现在，这里有两个更合适的潜在选项：

选项#1

BID = CALCULATE ([PROFIT], 'State'[Country], "United States")

选项#2
```
BID = CALCULATE ([PROFIT], KEEPFILTERS ('State'[Country] = "United
States"))
```
这两种选择都是可靠的选择；然而，结果却不同。与原始查询相比，第二个选项的执行方式相同。不同之处在于，代码的效率要高得多，因为过滤器直接应用于列，而不是整个表。在第一种选择中，代码样本很尴尬，因为它显示了美国在所有领域的盈利能力。您可以考虑在特定情况下使用此选项，例如当您需要一个值来显示时，而不考虑必须应用特定的筛选器。

有目的地转换数据

DAX不是指数据转换表达式，它是用于分析的。保持Power BI功能处于正确的泳道中，这意味着如果您想转换数据，请在Power Query中花费尽可能多的时间。在将数据导入Power BI模型之前，您在Power Query中提取、转换和加载数据的时间越多，以后所需的操作就越少。
在导入之前进行大量变革活动的模型可以实现快速的资源处理和优化。

一旦您的数据在加载前的准备工作中转换为尽可能好的状态，您就可以在将数据摄入Power BI后对其进行分析。在Power BI中摄入数据之前，请遵循这些指南，将DAX作为主要工具来转换数据集。您的数据应该

采用合适的分析格式
使用最佳数据模型格式完全加载到模型中。
尽可能多地进行清理、合并和拆分，因为在DAX中执行这项工作只会增加不必要的步骤

花更多的时间准备数据而不是分析数据是可以的，因为在转换过程中获得尽可能好的格式可以最大限度地减少以后的分析。

用你的列玩捉迷藏游戏

到目前为止，您可能已经意识到，过滤整个表可能会对性能产生深远影响，不仅在使用Power BI时，而且在实现DAX时也是如此。原因与解析每个表行有关：这非常耗时，而且通常会产生边际输出。相反，您可以选择一种更好的方式来管理表中的数据，不仅适用于DAX，而且适用于Power BI。遵循以下最佳实践：

无论你做什么，都要避免过滤整个表。您面临性能停滞的风险。假设您正在使用Azure、AWS、GCP或IBM Cloud为数据库带宽付费。在这种情况下，如果你的交易量很大，你会受到一点标签冲击。
删除您知道不会使用的所有列。表中有列“仅仅因为”为查询性能添加了不必要的费用。
重点关注使用基于列的方法进行筛选。一个更好的策略是只过滤那些你知道有相关数据的少数列。如果你能从数据集中删除剩下的列，那就去做吧。你可能会得到高性能的结果。

使用所有这些奇妙的函数

如果不是Power BI和DAX的绝佳资源，我就不会花几乎整整一章的时间来概述250多个功能。它们确实是代码缩减的救命稻草，因为它们被命名为表达式中的公式。函数通常有一个必需的、可选的参数作为输入。
每次执行函数时，都会返回一个值。与其他开发工作不同，这些功能几乎不需要代码。

DAX函数涵盖了从计算日期和时间到计算与字符串相关的数据、查找以及在表上迭代以执行递归表活动的各个方面。借助Power BI中的DAX，您对数据进行编码的能力远远超出了Excel在支持数学计算方面所提供的能力——以下列表为您提供了一些线索：

只有Power BI中的DAX允许您引用完整的列或表——也许您只想使用这些列或表中的特定值。您可以将筛选函数应用于公式。
假设您希望逐行自定义基于计算的数据。在这种情况下，某些DAX函数使您能够使用当前行值。也可以使用行数据作为参数值。
只有可以与DAX一起使用的变量才允许执行因上下文而异的计算。
DAX允许您跨表及其数据集返回函数，而不仅仅是一个值。尽管该表可能不显示在报告客户端中，但该表为其他功能提供了输入。
DAX为业务用户提供了一种特定的功能类型，称为时间智能功能。这些功能是独特的，因为它们可以让您了解选定的日期范围，并根据一系列日期（包括日期范围）执行复杂的计算。