我试图评估在成本和性能方面使用 Power BI 和 Azure Analysis Services 或 Power BI 和 Direct Query 访问数据和在数据集上运行查询的最佳方法。
我试图用下图说明这两种方法。
图中的第 4 步和第 5 步描述了使用 Power BI 和 Direct Query 访问 Azure Data Lake 中的数据。然而，第 4 步和第 6 步描述了使用 Power BI 和 Azure Analysis Services 访问数据。
根据我自己的研究，Direct Query 因性能问题而臭名昭著，例如
All DirectQuery requests are sent to the source database, so the time required to refresh a visual is dependent on how long that back-end source takes to respond with the results from the query (or queries).
上面的陈述有据可查，但是，在我的设计中，DirectQuery 请求应该不是问题，因为大部分逻辑和转换将在 Databricks 中进行(尽管我不希望这个问题集中在 Databricks 上) .
另一方面，使用 Azure Analysis Services (AAS)，所有请求都发生在内存中，而不是 DirectQuery，因此速度更快。
所以，如果您能分享您使用 DirectQuery 和 AAS 的经验，我会很高兴。如果我错过了使用技术相对于其他技术的任何优点/缺点，请告诉我/
最佳答案
Power BI (PBI) 数据模型是 Analysis Service 的轻量级版本。如果您打开了 PBI Desktop，您可以打开任务管理器并看到后台有一个 Analysis Services 实例。 在 Power BI 中，数据集大小限制为 1GB，在 Premium 中为 10GB，可以刷新到 12GB。
Analysis Services 将能够容纳更多数据，并且不受限于有限的数据集大小，并且您还拥有基于企业组织的其他功能。 Analysis Services 还可以在直接查询模式下访问数据源或导入数据，例如 Power BI。
在您的问题中，您提到直接查询模式“因性能问题而臭名昭著”，但这将取决于数据源的结构和大小。对于我已经部署的一些项目，我使用直接查询来访问至少 50-100GB 的数据源，但是这些大多是标准的星型模式数据仓库，或者定义的报告表，两者都将具有相关索引、覆盖索引或列存储索引，以便更有效地检索数据。由于基于度量、关系和连接开销对数据源执行的查询数量，直接查询模式将变慢。另一个可能是页面上的视觉对象数量，因为每个视觉对象都是一个查询，并且每个视觉对象都必须在数据源上运行。
另一种提高直接查询速度的方法是使用 Aggregations在 Power BI 中，将导入的数据子集存储在 Power BI 中。如果查询可以由聚合层回答，那么它会更快得到回答。微软用'Trillion Row Demo演示了这一点'
就 Power BI 直接查询问题而言，从我与之交互的客户范围来看，那些确实存在直接查询问题的客户在低效架构中混搭表，对数据运行次优查询源，在 DAX 中有许多数据转换，以及编写不当的 DAX 度量，例如大量 DISTINCT COUNTS 和 SWITCH。
因此，如果您希望导入数据，并且它超过了数据集大小限制，那么 Analysis Services 是您的最佳选择。如果您能以良好的方式设置数据结构，Power BI 和 Direct Query 应该没有问题。
希望对你有帮助
关于powerbi - Azure 分析服务与直接查询，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58235730/