Azure 分析服务与直接查询

Question

我正在尝试评估使用 Power BI with Azure Analysis Services 或 Power BI with Direct Query 访问数据和对数据集运行查询的成本和性能方面的最佳方法。

我试图用下图说明这两种方法。

图中步骤 4 和 5 描述了使用 Power BI 和 Direct Query 访问 Azure Data Lake 中的数据。而步骤 4 和 6 描述了使用 Power BI 和 Azure Analysis Services 访问数据。

根据我自己的研究，Direct Query 因性能问题而臭名昭著，例如

所有 DirectQuery 请求都发送到源数据库，因此刷新视觉对象所需的时间取决于后端源响应查询（或多个查询）结果所需的时间。

上面的陈述有据可查，但是，在我的设计中 DirectQuery 请求不应该成为问题，因为大部分逻辑和转换将在 Databricks 中进行（尽管我不希望这个问题专注于 Databricks）。

另一方面，使用 Azure 分析服务 (AAS)，所有请求都发生在内存中，而不是 DirectQuery，因此速度要快得多。

因此，如果您能分享您使用 DirectQuery 和 AAS 的经验，我会很高兴。如果你能告诉我我是否错过了使用技术的任何优势/劣势/

Answer 1

Power BI (PBI) 数据模型是分析服务的轻量级版本。如果您打开了 PBI 桌面，您可以打开任务管理器并看到后台有一个 Analysis Services 实例。在 Power BI 中，数据集大小限制为 1GB，在 Premium 中为 10GB，可以刷新到 12GB。

Analysis Services 将能够保存更多数据，并且不仅限于有限的数据集大小，您还具有基于企业组织的其他功能。Analysis Services 还可以在直接查询模式下驻留在数据源上或导入数据，如 Power BI。

在您的问题中，您提到直接查询模式“因性能问题而臭名昭著”，但这将取决于数据源的结构和大小。对于我部署的许多项目，我使用 Direct Query 来处理至少 50-100GB 的数据源，但是这些大多是标准的 Star Schema 数据仓库或定义的报告表，两者都将具有相关索引、覆盖索引或列存储索引以允许更有效地检索数据。由于基于度量、关系和连接开销对数据源执行的查询数量较多，直接查询模式会变慢。另一个可能是页面上的视觉对象数量，因为每个视觉对象都是一个查询，每个都必须在数据源上运行。

提高 Direct Query 速度的另一种方法是使用Power BI 中的聚合，将导入的数据子集存储在 Power BI 中。如果查询可以由聚合层回答，那么它将更快得到回答。微软通过“ Trillion Row Demo ”展示了这一点

就 Power BI Direct Query 问题而言，从我与之交互的客户端范围来看，那些确实存在 Direct Query 问题的客户端在低效架构中混搭了表，在数据源上运行次优查询， DAX 中的许多数据转换，以及编写不当的 DAX 度量，例如大量 DISTINCT COUNTS & SWITCH。

因此，如果您希望导入数据，并且超过了数据集大小限制，那么 Analysis Services 是您的最佳选择。如果你能很好地设置数据结构，Power BI 和 Direct Query 应该没有问题。

希望有帮助