Power BI 中的数据刷新

借助 Power BI,你可以快速完成从数据到洞察再到操作的过程,但必须确保 Power BI 报表和仪表板中的数据是最新的。 了解如何刷新数据通常对于提供准确的结果至关重要。

本文从概念层面介绍了 Power BI 的数据刷新功能及其依赖项。 它还提供了避免常见刷新问题的最佳做法和技巧。 该内容为帮助你了解数据刷新的工作原理奠定了基础。 有关配置数据刷新的有针对性的分步说明,请参阅本文末尾的“后续步骤”部分中列出的教程和操作指南。

了解数据刷新

使用服务主体和应用程序机密嵌入 Power BI 内容

每当你刷新数据时,Power BI 都必须查询基础数据源,可能要将源数据加载到数据集中,然后更新报表或仪表板中依赖于该更新数据集的所有可视化效果。 整个过程由多个阶段组成,具体取决于数据集的存储模式,如以下各节所述。

若要了解 Power BI 如何刷新数据集、报表和仪表板,必须了解以下概念:

  • 存储模式和数据集类型:Power BI 支持的存储模式和数据集类型具有不同的刷新要求。 你可以选择将数据重新导入 Power BI 来查看发生的所有更改,也可以选择直接在源中查询数据。
  • Power BI 刷新类型:无论数据集的具体情况如何,了解各种刷新类型都可以帮助你了解 Power BI 在刷新操作期间将时间花在哪些地方。 将这些详细信息与存储模式细节相结合有助于了解为数据集选择“立即刷新”时 Power BI 的确切执行情况。

存储模式和数据集类型

Power BI 数据集可以在下列模式之一中运行,以访问各种数据源中的数据。 有关详细信息,请参阅 Power BI Desktop 中的存储模式

  • 导入模式
  • DirectQuery 模式
  • LiveConnect 模式
  • 推送模式

下图阐释了基于存储模式的不同数据流。 最重要的一点是,只有导入模式数据集才需要刷新源数据。 之所以需要刷新,是因为只有这种数据集才会从其数据源导入数据,并且导入的数据可能会定期或临时更新。 DirectQuery 数据集以及在 LiveConnect 模式下连接到 Analysis Services 的数据集不导入数据;它们通过每次用户交互查询基础数据源。 推送模式下的数据集不直接访问任何数据源,但需要你将数据推送到 Power BI 中。 数据集刷新要求因存储模式/数据集类型而异。

Storage modes and dataset types

导入模式下的数据集

Power BI 将数据从原始数据源导入到数据集中。 提交到数据集的 Power BI 报表和仪表板查询从导入的表和列中返回结果。 可以将此类数据集视为时间点副本。 由于 Power BI 复制数据,因此必须刷新数据集以从基础数据源提取更改。

由于 Power BI 缓存数据,因此导入模式数据集可能会很大。 有关每种容量的最大数据集大小,请参阅下表。 通过将数据集大小保持在远低于最大大小的水平,可避免在刷新操作期间数据集需要的资源超过可用资源上限时出现刷新问题。

容量类型 最大数据集大小
共享、A1、A2 或 A3 1GB
A4 或 P1 3 GB
A5 或 P2 6 GB
A6 或 P3 10GB

有关高级容量中大型数据集的详细信息,请参阅大型数据集。 在 A6 或 P3 容量上,数据集可以最多刷新到 12 GB。

DirectQuery/LiveConnect 模式下的数据集

Power BI 不会通过在 DirectQuery/LiveConnect 模式下运行的连接导入数据。 相反,只要报表或仪表板查询数据集,数据集就会从基础数据源返回结果。 Power BI 转换查询并将其转发到数据源。

尽管在 DirectQuery 模式和 LiveConnect 模式下,Power BI 都会将查询转发到源,但值得注意的是,Power BI 在 LiveConnect 模式下不必转换查询。 查询直接转到托管数据库的 Analysis Services 实例,而不会消耗共享容量或高级容量上的资源。

由于 Power BI 不导入数据,因此无需运行数据刷新。 但是,Power BI 仍执行磁贴刷新,还有可能执行报表刷新,如介绍刷新类型的下一节所述。 磁贴是固定到仪表板的报表视觉对象,仪表板磁贴大约每隔一小时刷新一次,以便磁贴显示最新的结果。 可以在数据集设置中更改计划,如下面的屏幕截图所示,或使用“立即刷新”选项手动强制更新仪表板。

Refresh schedule

注意

导入模式下的数据集以及结合导入模式和 DirectQuery 模式的复合数据集不需要单独刷新磁贴,因为 Power BI 会在每次计划或按需数据刷新期间自动刷新磁贴。 对于导入模型,可以在“数据集”选项卡的“刷新计划”部分找到刷新计划。对于复合数据集,“刷新计划”部分位于“优化性能”部分。

注意

Power BI 不支持跨边界实时连接到主权云中的 Azure Analysis Services (AAS)。

推送数据集

推送数据集不包含数据源的正式定义,因此它们不要求你在 Power BI 中执行数据刷新。 可以通过使用外部服务或进程(例如 Azure 流分析)将数据推送到数据集来刷新它们。 这是使用 Power BI 进行实时分析的常用方法。 Power BI 仍会对基于推送数据集使用的所有磁贴执行缓存刷新。 有关详细演练,请参阅教程:流分析和 Power BI:针对流式处理数据的实时分析仪表板

Power BI 刷新类型

Power BI 刷新操作可以包含多种刷新类型,包括数据刷新、OneDrive 刷新、查询缓存刷新、磁贴刷新和报表视觉对象刷新。 虽然 Power BI 会自动确定给定数据集所需的刷新步骤,但你应该知道它们如何影响刷新操作的复杂性和持续时间。 有关快速参考,请参阅下表。

存储模式 数据刷新 OneDrive 刷新 查询缓存 磁贴刷新 报表视觉对象
导入 计划和按需 是,针对已连接的数据集 如果已在高级容量上启用 自动和按需
DirectQuery 不适用 是,针对已连接的数据集 如果已在高级容量上启用 自动和按需
LiveConnect 不适用 是,针对已连接的数据集 如果已在高级容量上启用 自动和按需
推送 不适用 不适用 不可行 自动和按需

探究不同刷新类型的另一种方式是了解它们的影响以及应用它们的位置。 数据源表结构或架构(如新列、重命名列或删除的列)中的更改只能在 Power BI Desktop 中应用,在 Power BI 服务中,它们可能会导致刷新失败。 有关其影响的快速参考,请参阅下表。


报表视觉对象刷新 数据刷新 架构刷新
不同的刷新类型有何用途? 刷新用于填充视觉对象的查询。

对于使用 DirectQuery 表的视觉对象,视觉对象将执行查询,以从数据源获取最新数据。

对于使用导入表的视觉对象,视觉对象只会在上次刷新数据时查询已导入到数据集的数据。
从数据源刷新数据。

不适用于 DirectQuery 表,因为它们位于视觉对象级别,并且依赖于报表视觉对象刷新。

对于导入的表,将从源刷新数据。
显示自上次刷新以来数据源表结构的任何更改。

例如:显示添加到 Power BI 数据流或 SQL 数据库视图的新列。

适用于导入的表和 DirectQuery 表。

在 Power BI Desktop 中,报表视觉对象刷新、数据刷新和架构刷新同时发生,方法是使用

  • “主页”功能区 >“刷新”按钮
  • “主页”功能区>“转换数据”>“关闭并应用”按钮
  • 任何表上的上下文菜单(右键单击或单击任何省略号),然后选择“刷新数据”

不能总是独立应用这些刷新类型,应用它们的位置因 Power BI Desktop 和 Power BI 服务而异。 有关快速参考,请参阅下表。

报表视觉对象刷新 数据刷新 架构刷新
在 Power BI Desktop 中
  • “查看”功能区>“性能分析器”按钮>“刷新视觉对象”
  • 创建和更改导致 DAX 查询运行的视觉对象
  • 页面刷新启用时(仅限 DirectQuery)
  • 打开 PBIX 文件
不可独立于其他刷新类型使用 不可独立于其他刷新类型使用
在 Power BI 服务中
  • 浏览器加载或重新加载报表时
  • 单击“刷新视觉对象”右上角菜单栏按钮
  • 在编辑模式下单击“刷新”按钮
  • 页面刷新启用时(仅限 DirectQuery)
  • 计划的刷新
  • 立即刷新
  • 从 Power Automate 刷新 Power BI 数据集
  • 处理来自 SQL Server Management Studio(高级版)的表
不可用
请记住 例如,如果在浏览器中打开报表,计划的刷新将对导入的表执行数据刷新,打开的浏览器中的报表视觉对象直到启动刷新才会更新。 重命名或删除源列或表时,对 Power BI 服务的数据刷新将会失败。 失败是因为 Power BI 服务也不包含架构刷新。 若要更正此错误,架构刷新需要在 Power BI Desktop 中发生,并且需要将数据集重新发布到服务。 数据源中经过重命名或删除的列或表将在 Power BI Desktop 中使用架构刷新进行更新,但它可能会破坏视觉对象和 DAX 表达式(度量值、计算列、行级别安全性等)并删除依赖于这些列或表的关系。

数据刷新

对 Power BI 用户而言,刷新数据通常意味着根据刷新计划或按需将数据从原始数据源导入到数据集。 可以每天执行多次数据集刷新,如果基础源数据经常更改,则可能必须执行多次刷新。 Power BI 将共享容量上的数据集限制为每天最多刷新数据集 8 次。 8 次刷新的值存储在后端数据库中,并按照“数据库设置”页上所选的“本地时间”时区计算。 计划程序将检查应在何时刷新哪个模型。 8 次刷新的配额会在本地时间每日凌晨 12:01 重置。

Data refresh schedule in Database settings.

如果数据集驻留在 Premium 容量上,则每天最多可在数据集设置中计划 48 次刷新。 有关详细信息,请参阅本文后面的配置计划刷新。 在以编程方式使用 TMSL 或 PowerShell 进行配置时,XMLA 终结点已启用读写操作的 Premium 容量中的数据集支持无限刷新操作。

还有一点非常重要,就是每日刷新的共享容量限制适用于计划刷新和组合 API 刷新。 还可以通过在数据集菜单中选择“立即刷新”来触发按需刷新,如下面的屏幕截图所示。 刷新限制不包括按需刷新。 另请注意,Premium 容量中的数据集不会对 API 刷新施加限制。 如果你有兴趣使用 Power BI REST API 生成自己的刷新解决方案,请参阅数据集 - 刷新数据集

Refresh now

注意

在共享容量中,数据刷新必须在 2 小时内完成。 如果数据集需要进行更长时间的刷新操作,请考虑将数据集移到高级容量上。 在高级容量上,最长刷新持续时间为 5 小时。

OneDrive 刷新

如果数据集和报表是基于 OneDrive 或 SharePoint Online 上的 Power BI Desktop 文件、Excel 工作簿或逗号分隔值 (.csv) 文件创建的,则 Power BI 会执行另一种类型的刷新,称为 OneDrive 刷新。 有关详细信息,请参阅从 Power BI 文件获取数据

OneDrive 刷新与 Power BI 将数据从数据源导入到数据集的数据集刷新不同,它会将数据集和报表与其源文件同步。 默认情况下,Power BI 以大约每小时一次的频率检查连接到 OneDrive 或 SharePoint Online 上的文件的数据集是否需要同步。

Power BI 会根据 OneDrive 中的项 ID 执行刷新,因此在考虑进行更新与替换时请慎重。 如果将 OneDrive 文件设置为数据源,Power BI 在执行刷新时会引用该文件的项 ID。 请考虑以下情况:你有主文件 A 和该文件的生产副本 B,同时你为文件 B 配置了 OneDrive 刷新。如果随后复制文件 A 而不是文件 B,则复制操作会删除旧的文件 B,并新建具有不同项 ID 的文件 B,而这会中断 OneDrive 刷新 。 若要避免这种情况,可以改为上传并替换文件 B,这样可原样保留其项 ID。

可以将文件移动(例如,使用拖放操作)到其他位置,由于 Power BI 仍可识别文件 ID,刷新将继续进行。 但如果将该文件复制到其他位置,则会新建该文件的实例和文件 ID。 因而 Power BI 文件引用将失效,且刷新将失败。

注意

即使已在本地计算机上完成了同步,并且已在 Power BI 服务中使用“立即刷新”,Power BI 也可能需要长达 60 分钟的时间才能刷新数据集。

若要查看过去的同步周期,请检查刷新历史记录中的 OneDrive 选项卡。 以下屏幕截图显示了示例数据集的完整同步周期。

Refresh history

如上面的屏幕截图所示,Power BI 将此 OneDrive 刷新标识为计划刷新,但无法配置刷新间隔。 只能在数据集设置中停用 OneDrive 刷新。 如果不希望 Power BI 中的数据集和报表自动从源文件中获取任何更改,则停用刷新非常有用。

请注意,仅当数据集连接到 OneDrive 或 SharePoint Online 中的文件时,数据集设置页面才会显示“OneDrive 凭据”和“OneDrive 刷新”部分,如以下屏幕截图所示 。 未连接到 OneDrive 或 SharePoint Online 中的源文件的数据集不显示这些部分。

OneDrive Credentials and OneDrive refresh

为数据集禁用 OneDrive 刷新后,仍可以通过在数据集菜单中选择“立即刷新”来按需同步数据集。 在按需刷新过程中,Power BI 会检查 OneDrive 或 SharePoint Online 上的源文件是否比 Power BI 中的数据集更新,如果是,则同步数据集。 “刷新历史记录”会在“OneDrive”选项卡上将这些活动列为按需刷新 。

请记住,OneDrive 刷新不会从原始数据源中请求数据, 而只是使用 .pbix、.xlsx 或 .csv 文件中的元数据和数据更新 Power BI 中的资源,如下图所示。 为确保数据集具有数据源中的最新数据,Power BI 还会在按需刷新过程中触发数据刷新。 你可以在“刷新历史记录”中切换到“计划”选项卡来对此进行验证 。

OneDrive refresh diagram

如果为连接 OneDrive 或 SharePoint Online 的数据集一直启用 OneDrive 刷新,并且希望按计划执行数据刷新,请确保配置计划,以便 Power BI 在 OneDrive 刷新后执行数据刷新。 例如,如果你创建自己的服务或进程,以在每天凌晨 1 点更新 OneDrive 或 SharePoint Online 中的源文件,则可以将计划刷新配置为凌晨 2:30,以便为 Power BI 提供足够的时间来完成 OneDrive 刷新,然后再启动数据刷新。

查询缓存刷新

如果数据集驻留在高级容量上,则可以通过启用查询缓存来提高所有关联报表和仪表板的性能,如以下屏幕截图所示。 查询缓存会指示高级容量使用其本地缓存服务来维护查询结果,避免基本数据源计算这些结果。 有关详细信息,请参阅 Power BI Premium 中的查询缓存

Query caching

但是,在进行数据刷新之后,先前缓存的查询结果便不再有效。 Power BI 会丢弃这些缓存结果,并且必须重新生成它们。 因此,对于与经常刷新(例如每天 48 次)的数据集关联的报表和仪表板,使用查询缓存的意义不大。

报表视觉对象刷新

此刷新过程不太重要,因为它仅与 Analysis Services 的实时连接有关。 对于这些连接,Power BI 会缓存报表视觉对象的最后一个状态,这样一来,当你再次查看报表时,Power BI 就不必查询 Analysis Services 表格模型。 当你与报表交互时(例如通过更改报表筛选器),Power BI 会查询表格模型并自动更新报表视觉对象。 如果你怀疑报表显示过时数据,还可以选择报表的“刷新”按钮来触发所有报表视觉对象的刷新操作,如以下屏幕截图所示。

Refresh report visuals

仅刷新固定的视觉对象,而不是固定的实时页面。 若要刷新固定的实时页面,可使用浏览器的“刷新”按钮。

查看数据基础结构依赖项

无论采用哪种存储模式,都必须能够访问基础数据源,否则将无法成功刷新数据。 有三种主要的数据访问方案:

  • 数据集使用驻留在本地的数据源
  • 数据集使用云中的数据源
  • 数据集使用来自本地源和云源的数据

连接到本地数据源

如果数据集使用 Power BI 无法通过直接网络连接访问的数据源,则必须先为此数据集配置网关连接,然后才能启用刷新计划或执行按需数据刷新。 有关数据网关及其工作原理的详细信息,请参阅什么是本地数据网关?

你有以下选择:

  • 选择具有所需数据源定义的企业数据网关
  • 部署个人数据网关

注意

可以在管理数据源 - 导入/计划刷新一文中找到需要数据网关的数据源类型列表。

使用企业数据网关

Microsoft 建议使用企业数据网关(而不是个人网关)将数据集连接到本地数据源。 请确保正确配置网关,这意味着网关必须具有最新的更新和所有必需的数据源定义。 数据源定义可为 Power BI 提供给定源的连接信息,包括连接终结点、身份验证模式和凭据。 有关在网关上管理数据源的详细信息,请参阅管理数据源 - 导入/计划刷新

如果你是网关管理员,则将数据集连接到企业网关相对来说比较简单。 必要时,可以使用管理员权限立即更新网关并添加缺少的数据源。 事实上,可以直接从数据集设置页面向网关添加缺少的数据源。 展开切换按钮以查看数据源,然后选择“添加到网关”链接,如以下屏幕截图所示。 但如果你不是网关管理员,则必须联系网关管理员添加所需的数据源定义。

注意

仅网关管理员可将数据源添加到网关。 此外,确保网关管理员将你的用户帐户添加到有权使用数据源的用户的列表。 数据集设置页仅允许选择你有权使用其匹配数据源的企业网关。

Add to gateway

请确保将正确的数据源定义映射到数据源。 如上面的屏幕截图所示,网关管理员可在连接到同一数据源的单个网关上创建多个定义,其中每个定义使用不同的凭据。 如示例中所示,销售部门中的数据集所有者会选择 AdventureWorksProducts-Sales 数据源定义,而支持部门中的数据集所有者会将数据集映射到 AdventureWorksProducts-Support 数据源定义。 如果数据源定义的名称不直观,请联系网关管理员来明确要选择哪个定义。

注意

一个数据集只能使用一个网关连接。 换句话说,不能跨多个网关连接访问本地数据源。 因此,必须将所有必需的数据源定义添加到同一网关。

部署个人数据网关

如果你无权访问企业数据网关,并且你是唯一管理数据集的人员,因此无需与其他人共享数据源,则可以在个人模式下部署数据网关。 在“网关连接”部分的“未安装个人网关”下,选择“立即安装” 。 如本地数据网关(个人模式)中所述,个人数据网关存在若干限制。

与企业数据网关不同,你无需向个人网关添加数据源定义, 而是使用数据集设置中的“数据源凭据”部分来管理数据源配置,如以下屏幕截图所示。

Configure data source credentials for gateway

访问云数据源

如果 Power BI 可以与云数据源(如 Azure SQL DB)建立直接网络连接,则使用该源的数据集不需要数据网关。 相应地,可以使用数据集设置中的“数据源凭据”部分来管理这些数据源的配置。 如以下屏幕截图所示,你无需配置网关连接。

Configure data source credentials without a gateway

注意

每个用户在其拥有的所有数据集上,每个数据源只能有一组凭据,而不考虑数据集驻留的工作区。 并且每个数据集只能有一个所有者。 如果要为你不是其所有者的数据集更新凭据,则必须首先通过单击“数据集设置”页面上的“接管”按钮来接管此数据集。

在同一源查询中访问本地源和云源

数据集可以从多个源获取数据,这些源可以驻留在本地或云中。 但是,如前所述,一个数据集只能使用一个网关连接。 虽然云数据源不一定需要网关,但如果数据集在单个糅合查询中同时连接到本地源和云源,则需要网关。 在此方案中,Power BI 也必须使用网关来访问云数据源。 下图阐释了此类数据集如何访问其数据源。

Cloud and on-premises data sources

注意

如果数据集使用不同的糅合查询连接到本地源和云源,则 Power BI 使用网关连接访问本地源,使用直接网络连接访问云源。 如果糅合查询合并或追加​​来自本地源和云源的数据,则即使是云源,Power BI 也会切换为使用网关连接。

Power BI 数据集依靠 Power Query 来访问和检索源数据。 以下糅合列表显示了合并来自本地源和云源的数据的基本查询示例。

Let

    OnPremSource = Sql.Database("on-premises-db", "AdventureWorks"),

    CloudSource = Sql.Databases("cloudsql.database.windows.net", "AdventureWorks"),

    TableData1 = OnPremSource{[Schema="Sales",Item="Customer"]}[Data],

    TableData2 = CloudSource {[Schema="Sales",Item="Customer"]}[Data],

    MergedData = Table.NestedJoin(TableData1, {"BusinessEntityID"}, TableData2, {"BusinessEntityID"}, "MergedData", JoinKind.Inner)

in

    MergedData

可通过以下两种方式来配置数据网关,以支持合并或追加来自本地源和云源的​​数据:

  • 除本地数据源外,将云源的数据源定义也添加到数据网关。
  • 启用复选框“允许用户的云数据源通过此网关群集刷新”。

Refresh through gateway cluster

如果启用“允许用户的云数据源通过网关配置中的此网关群集刷新”复选框(如上面的屏幕截图所示),则 Power BI 可使用用户在数据集设置中的“数据源凭据”下为云源定义的配置 。 这有助于降低网关配置开销。 但是,如果希望更好地控制网关建立的连接,则不应启用此复选框。 在这种情况下,必须向网关添加要支持的每个云源的显式数据源定义。 也可以启用该复选框,并向网关添加云源的显式数据源定义。 在这种情况下,网关会使用所有匹配源的数据源定义。

配置查询参数

使用 Power Query 创建的糅合或 M 查询的复杂程度可能不同,既有可能是简单的步骤,也有可能是复杂的参数化构造。 以下列表显示了一个小型糅合查询示例,它使用两个名为 SchemaNameTableName 的参数来访问 AdventureWorks 数据库中的给定表。

let

    Source = Sql.Database("SqlServer01", "AdventureWorks"),

    TableData = Source{[Schema=SchemaName,Item=TableName]}[Data]

in

    TableData

注意

查询参数仅适用于导入模式数据集。 DirectQuery/LiveConnect 模式不支持查询参数定义。

若要确保参数化数据集访问正确的数据,必须在数据集设置中配置糅合查询参数。 也可以使用 Power BI REST API 以编程方式更新参数。 以下屏幕截图显示了一个用户界面,可在其中配置使用上述糅合查询的数据集的查询参数。

Configure query parameters

刷新和动态数据源

动态数据源是这样一种数据源,其中的部分或所有信息在 Power Query 运行查询之后才能确定是否需要连接,因为数据是在代码中生成的或从其他数据源返回的。 示例包括:SQL Server 数据库的实例名称和数据库;CSV 文件的路径;或 Web 服务的 URL。

在大多数情况下,无法在 Power BI 服务中刷新使用动态数据源的 Power BI 数据集。 有几种例外情况,可以在 Power BI 服务中刷新动态数据源,例如,将 RelativePath 和查询选项与 Web.Contents M 函数结合使用时。 也可以刷新引用 Power Query 参数的查询。

若要确定是否可以刷新动态数据源,请在 Power Query 编辑器中打开“数据源设置”对话框,然后选择“当前文件中的数据源” 。 在出现的窗口中,查找以下警告消息,如下图所示:

注意

某些数据源可能未列出,因为它们包含手动编写的查询。

Dynamic data source indicator

如果该警告显示在出现的“数据源设置”对话框中,则会显示无法在 Power BI 服务中刷新的动态数据源。

配置计划刷新

配置数据刷新时,在 Power BI 和数据源之间建立连接是目前为止最具挑战性的任务。 其余步骤(包括设置刷新计划和启用刷新失败通知)相对来说比较简单。 有关分步说明,请参阅操作指南配置计划刷新

设置刷新计划

可在“计划刷新”部分定义数据集的刷新频率和时间段。 如前所述,如果数据集位于共享容量上,则可以配置每天最多 8 个时间段,如果位于 Power BI Premium 上,则可以配置每天最多 48 个时间段。 以下屏幕截图显示了时间间隔为 12 小时的刷新计划。

Configure scheduled refresh

配置完刷新计划后,数据集设置页面会通知你下一个刷新时间,如上面的屏幕截图所示。 如果要加快数据刷新速度以执行网关和数据源配置测试等操作,请使用导航窗格的数据集菜单中的“立即刷新”选项进行按需刷新。 按需刷新不会影响下一计划的刷新时间。

提示

Power BI 没有每月刷新间隔选项。 但是,可以使用 Power Automate 创建每月发生的自定义刷新间隔,如以下 Power BI 博客文章中所述。

另请注意,配置的刷新时间可能不是 Power BI 启动下一个计划进程的确切时间。 Power BI 会尽最大努力启动计划刷新。 目标是在计划时间段的 15 分钟内启动刷新,但如果服务无法更快地分配所需资源,则可能会延迟最多一小时。

注意

Power BI 会在连续四次失败后或当服务检测到需要配置更新的不可恢复错误(例如无效或过期的凭据)时停用刷新计划。 无法更改连续失败阈值。

获取刷新失败通知

默认情况下,Power BI 通过电子邮件将刷新失败通知发送给数据集所有者,以便在发生刷新问题时,所有者可以及时采取行动。 当服务因连续失败而禁用你的计划时,Power BI 也会向你发送通知。 Microsoft 建议将复选框“向数据集所有者发送刷新失败通知电子邮件”保留为启用状态。

也可以使用“刷新失败时,向这些联系人发送电子邮件”文本框来指定其他收件人。 除数据集所有者以外,指定收件人也会接收刷新失败通知。 可以是在你度假时处理你数据集的同事。 也可以是为你的部门或组织处理刷新问题的支持团队的电子邮件别名。 向除数据集所有者以外的其他人发送刷新失败通知有助于确保及时察觉和处理问题。

请注意,Power BI 不仅会在刷新失败时发送通知,还会在服务因数据集不活动而暂停计划刷新时发送通知。 两个月后,如果没有用户访问过基于数据集生成的任何仪表板或报表,Power BI 会将数据集视为不活动。 在这种情况下,Power BI 会向数据集所有者发送一封电子邮件,指出服务已暂停数据集的刷新计划。 有关此类通知的示例,请参阅以下屏幕截图。

Email for paused refresh

若要恢复计划刷新,请访问使用此数据集生成的报表或仪表板,或使用“立即刷新”选项手动刷新数据集。

注意

不支持向外部用户发送刷新通知。 在“刷新失败时,向这些用户发送电子邮件”文本框中指定的收件人必须在 Azure Active Directory 租户中拥有帐户。 此限制适用于数据集刷新和数据流刷新。

检查刷新状态和历史记录

除了失败通知之外,最好定期检查数据集是否存在刷新错误。 一种快速方法是查看工作区中的数据集列表。 有错误的数据集会显示一个小警告图标。 选中警告图标可获取附加信息,如以下屏幕截图所示。 有关解决特定刷新错误的详细信息,请参阅刷新方案故障排除

Refresh status warning

警告图标有助于指示当前的数据集问题,但偶尔检查刷新历史记录也不失为一个好办法。 顾名思义,通过刷新历史记录可以查看过去同步周期的成功或失败状态。 例如,网关管理员可能已更新一组过期的数据库凭据。 如以下屏幕截图所示,刷新历史记录显示受影响的刷新何时再次开始工作。

Refresh history messages

注意

可以在数据集设置中找到显示刷新历史记录的链接。 也可以使用 Power BI REST API 以编程方式检索刷新历史记录。 通过使用自定义解决方案,可以集中监视多个数据集的刷新历史记录。

自动页面刷新

自动页面刷新针对报表页面执行,使用此功能,报表作者可以为页面中仅在使用页面时处于活动状态的视觉对象设置刷新间隔。 自动页面刷新仅适用于 DirectQuery 数据源。 最小刷新间隔取决于要在其中发布报表的工作区的类型,以及 Premium 工作区和嵌入工作区的容量管理设置。

有关自动页面刷新的详细信息,请参阅自动页面刷新一文。

最佳做法

若要确保报表和仪表板使用当前数据,定期检查数据集的刷新历史记录是可采用的最重要的最佳做法之一。 一旦发现问题,请及时解决,并在必要时跟进数据源所有者和网关管理员。

此外,请考虑以下建议,以便为数据集建立和维护可靠的数据刷新过程:

  • 将刷新安排在较空闲的时间进行,特别是当数据集位于 Power BI Premium 上时。 如果在更宽的时间范围内分配数据集的刷新周期,则可以帮助避开可能过度占用可用资源的高峰时间段。 延迟启动刷新周期意味着资源过载。 如果 Premium 容量完全耗尽,Power BI 甚至有可能跳过刷新周期。
  • 记住刷新限制。 如果源数据频繁更改或数据量很大,并且源中增加的负载以及对查询性能的影响是可接受的,则考虑使用 DirectQuery/LiveConnect 模式而不是导入模式。 避免不断刷新导入模式数据集。 但是,如在 Power BI Desktop 中使用 DirectQuery 所述,DirectQuery/LiveConnect 模式存在一些限制,例如返回数据的行数限制为一百万行,运行查询的响应时间限制为 225 秒。 这些限制可能会导致你仍然使用导入模式。 对于非常大的数据量,请考虑使用 Power BI 中的聚合
  • 确保数据集刷新时间不超过最大刷新持续时间。 使用 Power BI Desktop 检查刷新持续时间。 如果需要超过 2 小时,请考虑将数据集移至 Power BI Premium。 数据集可能无法在共享容量上刷新。 另请考虑对大于 1GB 或刷新时间长达几小时的数据集使用增量刷新
  • 优化数据集以仅包括报表和仪表板使用的表和列。 优化糅合查询,如有可能,避免使用动态数据源定义和高成本的 DAX 计算。 特别是避免使用测试表中每一行的 DAX 函数,因为这种函数的内存消耗和处理开销非常高。
  • 应用与 Power BI Desktop 中相同的隐私设置,确保 Power BI 可以生成有效的源查询。 记住,Power BI Desktop 不会发布隐私设置。 发布数据集后,必须手动重新应用数据源定义中的设置。
  • 限制仪表板上视觉对象的数量,尤其是在使用行级别安全性 (RLS) 时。 如本文前面所述,过多的仪表板磁贴会显著增加刷新持续时间。
  • 使用可靠的企业数据网关部署将数据集连接到本地数据源。 如果发现与网关相关的刷新故障(例如网关不可用或过载),请让网关管理员向现有群集添加其他网关或部署新群集(纵向扩展与横向扩展),直至问题得到解决。
  • 为导入数据集和 DirectQuery/LiveConnect 数据集使用不同的数据网关,以使计划刷新期间的数据导入不影响基于 DirectQuery/LiveConnect 数据集(通过每次用户交互查询数据源)的报表和仪表板的性能。
  • 确保 Power BI 可以向你的邮箱发送刷新失败通知。 垃圾邮件筛选器可能会阻止电子邮件或将其移至你可能不会立即注意到的单独文件夹中。

后续步骤

配置计划刷新
用于解决刷新问题的工具
刷新方案故障排除

更多问题? 尝试咨询 Power BI 社区