在 Power BI Desktop 中使用 DirectQuery
- 版本 :2023.1(当前版本)
在 Power BI Desktop 中使用 DirectQuery
使用 Power BI Desktop 连接到任何数据源时,可以导入数据的副本。 对于某些数据源,还可以使用 DirectQuery 直接连接到数据源,而无需导入数据。 有关支持 DirectQuery 的数据源的完整列表,请参阅 DirectQuery 支持的数据源。
下面是使用导入模式和 DirectQuery 连接模式之间的差异:
导入:所选表和列中的数据副本导入 Power BI Desktop。 在你创建可视化效果或与之进行交互时,Power BI Desktop 需要使用导入的数据。 若要查看自初始导入或最近一次刷新以后基础数据所发生的更改,必须再次导入完整的数据集以刷新数据。
DirectQuery:不会将任何数据导入 Power BI Desktop 中。 对于关系源,你可以选择要显示在 Power BI Desktop“字段”列表中的表和列。 对于 SAP Business Warehouse (SAP BW) 等多维源,所选多维数据集的维度和度量值会显示在“字段”列中。 在你创建可视化效果或与之进行交互时,Power BI Desktop 会查询基础数据源,就是说,你查看的始终都是最新数据。
使用 DirectQuery 创建可视化效果或与之交互时,必须查询基础源。 需要刷新可视化效果花费的时间取决于基础数据源的性能。 如果最近已请求为处理请求而必需的数据时,Power BI Desktop 将使用最近的数据来减少显示可视化效果时所需的时间。 从“主页”功能区中选择“刷新”将使用当前数据刷新所有可视化效果。
使用 DirectQuery 时,可以使用许多数据建模和数据转换,但存在一些基于性能的限制。 有关 DirectQuery 优点、限制和建议的详细信息,请参阅 Power BI 中的 DirectQuery。
DirectQuery 优点
使用 DirectQuery 的一些优点包括:
DirectQuery 可使你在超大型数据集上生成可视化效果,除此之外将无法使用预聚合导入所有数据。
DirectQuery 报表始终会使用当前数据。 查看基础数据更改需要刷新数据,而重新导入大型数据集来刷新数据可能不可行。
1 GB 的数据集限制不适用于 DirectQuery。
使用 DirectQuery 进行连接
使用 DirectQuery 连接到数据源:
在“Power BI Desktop”功能区的“主页”组中,选择“获取数据”,然后选择 DirectQuery 支持的数据源,例如 SQL Server。
在连接的对话框中,在“数据连接模式”下,选择“DirectQuery”。
发布到 Power BI 服务
可以将 DirectQuery 报表发布到 Power BI 服务,但需要为 Power BI 服务执行额外的步骤才能打开报表。
如果需要将 Power BI 服务连接到除 Azure SQL 数据库、Azure Synapse Analytics(原 SQL 数据仓库)、Amazon Redshift 和 Snowflake 数据仓库之外的 DirectQuery 数据源,则必须安装本地数据网关并注册数据源。
如果将 DirectQuery 用于 Azure SQL 数据库、Azure Synapse、Amazon Redshift 或 Snowflake 数据仓库等云源,则不需要本地数据网关。 仍必须为 Power BI 服务提供凭据才能打开已发布的报表。 如果没有凭据,在尝试打开已发布的报表或浏览使用 DirectQuery 连接创建的数据集时,将发生错误。
提供凭据用于打开报表和刷新数据:
在 Power BI 服务中,选择右上角的齿轮图标,然后选择“设置”。
在“设置”页上,选择“数据集”选项卡,选择将使用 DirectQuery 的数据集。
在“数据源连接”下,提供用于连接到数据源的凭据。
备注
如果将 DirectQuery 用于具有专用 IP 地址的 Azure SQL 数据库,则需要使用本地网关。
注意事项和限制
DirectQuery 模式不支持某些 Power BI Desktop 功能,或这些功能有限制。 Power BI 服务中的某些功能(如“快速见解”)也不适用于使用 DirectQuery 的数据集。 决定是否使用 DirectQuery 时,应考虑到这些功能限制。 同时还应考虑下列因素:
性能和负载注意事项
DirectQuery 将所有请求发送到源数据库,因此视觉对象所需的刷新时间取决于基础源返回结果所需的时间。 接收视觉对象请求数据的推荐响应时间是五秒或更短。 超过 30 秒的刷新时间会为使用报表的用户带来不可接受的糟糕体验。 Power BI 服务中超过 4 分钟的查询会超时,用户会收到一个错误。
源数据库上的负载还取决于使用已发布报表的 Power BI 用户的数量,尤其是在报表使用行级别安全性 (RLS) 的情况下。 刷新多个用户共享的非 RLS 仪表板磁贴会将单个查询发送到数据库,但刷新使用 RLS 的仪表板磁贴需要每个用户执行一个查询。 增加的查询会显著增加负载,并可能影响性能。
100 万行限制
DirectQuery 为从云数据源返回的数据定义了 100 万行限制,这些数据源不是本地的任何数据源。 根据专有压缩算法,本地源限制为每行大约 4 MB 的已定义有效负载,或者整个视觉对象为 16 MB。 高级容量可以设置不同的最大行限制,如博客文章 Power BI Premium 新容量设置中所述。
Power BI 会创建尽可能高效的查询,但某些生成的查询可能会从基础数据源检索过多的行。 例如,生成包含非常高的基数列的简单图表,聚合选项设置为“不汇总”。 视觉对象必须只具有基数低于 100 万的列,或必须应用适当的筛选器。
行限制不适用于用于选择 DirectQuery 返回的数据集的聚合或计算,仅适用于返回的行。 例如,在数据源上运行的查询可以聚合 1000 万行。 只要返回到 Power BI 的数据少于 100 万行,查询就可以准确返回结果。 如果数据超过 100 万行,Power BI 会显示错误,但具有不同管理员设置限制的高级容量除外。 错误说明:外部数据源的查询结果集超过了允许的最大行数‘1000000’行。
安全注意事项
默认情况下,在 Power BI 服务中使用发布报表的所有用户都使用发布后输入的凭据连接到基础数据源。 这种情况与导入的数据相同。 所有用户都会看到相同的数据,而不考虑基础源定义的任何安全规则。
如果需要使用 DirectQuery 源实现按用户安全性,可以使用 RLS 或针对源配置 Kerberos 约束身份验证。 Kerberos 并不适用于部分源。 有关详细信息,请参阅 Power BI 行级别安全性 (RLS)和配置从 Power BI 服务到本地数据源的基于 Kerberos 的 SSO。
其他 DirectQuery 限制
使用 DirectQuery 的其他一些限制包括:
如果“Power Query 编辑器”查询过于复杂,将会出错。 若要修复此错误,必须在 Power Query 编辑器中删除有问题的步骤,或切换到导入模式。 SAP BW 等多维源无法使用 Power Query 编辑器。
自动日期/时间层次结构在 DirectQuery 中不可用。 DirectQuery 模式不支持按年、季度、月或日向下钻取日期列。
对于表或矩阵可视化效果,从 DirectQuery 源返回超过 500 行的结果有 125 列的限制。 这些结果在表或矩阵中显示滚动条,以便提取更多数据。 在这种情况下,表或矩阵中的最大列数为 125。 如果必须在单个表或矩阵中包含超过 125 的列数,请考虑使用
MIN
、MAX
、FIRST
或LAST
创建度量值,因为它们不计入此最大值。无法将导入模式更改为 DirectQuery 模式。 如果导入所有必要的数据,则可以从 DirectQuery 模式切换到导入模式。 无法切换回去,主要是因为 DirectQuery 不支持的功能集。 由于外部度量值的处理方式不同,多维源(如 SAP BW)的 DirectQuery 模型不能从 DirectQuery 切换到导入模式。
Power BI 服务不支持使用单一登录 (SSO) 身份验证从数据源引用 DirectQuery 表的计算表和计算列。