对于这个含糊的问题，我深表歉意。我正在与一名数据工程师合作开展一个项目，但我对后端的了解有限。
我们正在使用 Azure 事件中心在 Power BI 中流式传输数据。数据大致遵循以下路径:Azure 事件中心 > 流数据流 > 数据集 > Power BI。问题在于，在 Power BI 中(或直接在模型中)运行的任何 DAX 查询的性能都非常差。
这似乎不是 DAX 本身的问题。使用 Azure Analysis Services 连接在相似数量的行上运行的相同 DAX 代码运行良好。但是，当它通过事件中心连接运行时，性能会大幅下降(~3 秒 vs >1 分钟)。不涉及 DAX 的情况下加载的视觉效果实际上具有相当好的性能，这让我认为这个问题与 DAX 交互有关，而不是与整个连接有关。
有人在 Power BI 中的事件中心连接方面遇到过类似的情况吗？有没有办法解决此连接的 DAX 性能问题？
最佳答案
使用以下建议编写优化的 DAX 表达式和设计报告:
DAX 指标
带有变量的 DAX
SELECTEDVALUE () 与 HASONEVALUE ()
一种常见的场景是使用 HASONEVALUE() 检查应用切片器和过滤器后列中是否仅存在一个值，然后使用 VALUES(列名称) DAX 函数获取单个值。
SELECTEDVALUE () 在内部执行上述两个步骤，如果该列中只有一个不同的值，则获取该值；如果有多个可用值，则返回空白。
DISTINCT () 与 VALUES ()
Power BI 会向该列添加一个空白值，以防发现引用完整性违规。对于直接查询，Power BI 默认情况下会向列添加空白值，因为它无法检查违规情况。
DISTINCT ():遇到完整性违规时不返回空白。仅当它是原始数据的一部分时，它才返回空白。
VALUES (): 包含空白，因为 Power BI 由于违反引用完整性而添加了空白。
整个报告中任一函数的用法应该相同。如果可能的话，在整个报告中使用 VALUES ()，这样空白值就不会成为问题。
高效比率计算
将 (a-b)/b 与变量一起使用，而不是 (a/b)-1。通常情况下，这两种情况的性能是相同的，但在边缘情况下，当a和b均为空值时，前者将返回空白并过滤掉日期，而后者将返回-1并增加查询空间。
避免 IFERROR () 和 ISERROR ()
IFERROR () 和 ISERROR () 有时用于测量。这些函数强制引擎逐步执行该行以检查错误。因此，只要有可能，请替换为内置的错误检查函数。
示例:DIVIDE() 和 SELECTEDVALUE() 在内部执行错误检查并返回预期结果。
关于azure - Power BI - 事件中心中的 DAX 速度缓慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/72405643/