Power BI 中的数据刷新

项目
05/03/2024
20 个参与者

反馈

借助 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 模式
Direct Lake 模式
LiveConnect 模式
推送模式

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

导入模式下的语义模型

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

刷新语义模型时，或者完全刷新，或者部分刷新。部分刷新将在包含具有增量刷新策略的表的语义模型中进行。在这些语义模型中，只会刷新表分区的子集。此外，高级用户可使用 XMLA 终结点刷新任何语义模型中的特定分区。

刷新语义模型所需的内存量取决于是执行完全刷新还是部分刷新。刷新期间将保留语义模型的副本，以便处理对语义模型的查询。这意味着，如果要执行完全刷新，将需要两倍语义模型所需的内存量。

建议规划容量使用情况，确保考虑到语义模型刷新所需的额外内存。在刷新操作期间，拥有足够的内存可以防止语义模型所需内存超出可用内存导致的刷新问题。要了解高级容量上每个语义模型的可用内存量，请参阅容量和 SKU 表。

有关高级容量中的大型语义模型的详细信息，请参阅大型语义模型。

DirectQuery 模式下的语义模型

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

注意

实时连接报告将查询提交到托管语义模型或模型的容量或 Analysis Services 实例。使用外部分析服务，如 SQL Server Analysis Services (SSAS) 或 Azure Analysis Services (AAS) 时，资源在 Power BI 外部消耗。

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

注意

导入模式下的语义模型以及结合导入模式和 DirectQuery 模式的复合语义模型不需要单独刷新磁贴，因为 Power BI 会在每次计划或按需数据刷新期间自动刷新磁贴。基于 XMLA 终结点更新的语义模型只会清除缓存的磁贴数据（使缓存失效）。在每个用户访问仪表板之前，磁贴缓存不会刷新。对于导入模型，可以在“语义模型”选项卡的“计划刷新”部分中找到刷新计划。对于复合语义模型，“计划刷新”部分位于“优化性能”部分。
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 和 Direct Lake 表。

在 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 服务中编辑数据模型时使用编辑表时，才可用于 Direct Lake 模式下的语义模型。请记住例如，如果在浏览器中打开报表，计划的刷新将对导入的表执行数据刷新，打开的浏览器中的报表视觉对象直到启动刷新才会更新。重命名或删除源列或表时，对 Power BI 服务的数据刷新将会失败。失败是因为 Power BI 服务也不包含架构刷新。若要更正此错误，需要在 Power BI Desktop 中进行架构刷新，并且需要将语义模型重新发布到服务。数据源中经过重命名或删除的列或表将通过架构刷新来删除，并且它可能会破坏视觉对象和 DAX 表达式（度量值、计算列、行级别安全性等）并删除依赖于这些列或表的关系。

数据刷新

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

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

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

注意

在共享容量中，数据刷新必须在 2 小时内完成。如果语义模型的刷新操作需要较长时间，请考虑将语义模型移到高级容量。在高级版中，最长刷新持续时间为 5 小时，但使用 XMLA 终结点刷新数据可以绕过 5 小时的限制。

OneDrive 刷新

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

与 Power BI 将数据从数据源导入语义模型时的语义模型刷新不同，OneDrive 刷新会将语义模型和报表与其源文件同步。默认情况下，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 选项卡。以下屏幕截图显示了示例语义模型的完整同步周期。

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

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

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

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

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

查询缓存刷新

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

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

报表视觉对象刷新

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

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

查看数据基础结构依赖项

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

语义模型使用驻留在本地的数据源
语义模型使用云中的数据源
语义模型使用来自本地源和云源的数据

连接到本地数据源

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

你有以下选择：

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

注意

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

使用企业数据网关

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

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

注意

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

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

注意

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

部署个人数据网关

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

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

访问云数据源

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

注意

每个用户在其拥有的所有语义模型上，每个数据源只能有一组凭据，无论语义模型驻留的工作区是什么。每个语义模型只能有一个所有者。如果想要更新语义模型的凭据，但不是语义模型所有者，必须先单击语义模型设置页面上的“接管”按钮来接管语义模型。

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

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

注意

如果语义模型使用不同的糅合查询连接到本地源和云源，则 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

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

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

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

配置查询参数

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

let

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

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

in

    TableData

注意

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

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

刷新和动态数据源

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

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

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

注意

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

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

配置计划刷新

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

设置刷新计划

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

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

提示

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

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

注意

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

获取刷新失败通知

默认情况下，Power BI 通过电子邮件将刷新失败通知发送给语义模型所有者，以便在发生刷新问题时，他们可以及时采取行动。如果所有者在其移动设备上具有 Power BI 应用，则他们也会在那里收到失败通知。当服务由于连续失败而禁用计划刷新时，Power BI 也会向你发送电子邮件通知。 Microsoft 建议将复选框“向语义模型所有者发送刷新失败通知电子邮件”保留为启用状态。

另外，最好是使用“刷新失败时，向这些联系人发送电子邮件”文本框来指定计划刷新失败通知的其他收件人。指定的收件人可通过电子邮件接收刷新失败通知，并将通知推送到移动应用，就像语义模型所有者所做的那样。指定的收件人可以是在休假时负责处理语义模型的同事，也可以是负责处理部门或组织的刷新问题的支持团队的电子邮件别名。向除语义模型所有者以外的其他人发送刷新失败通知有助于确保及时察觉和处理相关问题。

注意

向移动应用推送通知不支持组别名。

请注意，Power BI 不仅会在刷新失败时发送通知，还会在服务因数据集不活动而暂停计划刷新时发送通知。两个月后，当没有用户访问基于语义模型构建的任何仪表板或报表时，Power BI 会认为该语义模型处于非活动状态。在这种情况下，Power BI 会向语义模型所有者发送一封电子邮件，指出该服务已暂停语义模型的刷新计划。有关此类通知的示例，请参阅以下屏幕截图。

若要恢复计划刷新，请访问使用此语义模型生成的报表或仪表板，或使用“立即刷新”选项手动刷新语义模型。

注意

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

检查刷新状态和历史记录

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

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

注意

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

自动页面刷新

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

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

语义模型刷新历史记录

Power BI 语义模型的刷新尝试可能并非总是顺畅进行，或者可能需要比预期更长的时间。可以使用“刷新历史记录”页来帮助诊断刷新可能未按预期发生的原因。

如果语义模型刷新失败，Power BI 会自动多次尝试刷新语义模型。不深入了解刷新的历史活动时，可能看起来只是刷新花费的时间比预期要长。使用“刷新历史记录”页时，可以查看这些失败的尝试，并深入了解失败的原因。

以下屏幕截图显示了失败的刷新，其中包含 Power BI 每次自动尝试成功完成刷新的详细信息。

还可以查看 Power BI 在先前几次尝试失败后成功，如下图所示，该图显示 Power BI 仅在先前失败三次后就成功了。请注意，成功的数据刷新和查询缓存具有相同的索引号，表示它们均在第四次尝试时成功。

可以选择失败旁边的“显示”链接，以获取失败的刷新尝试相关的详细信息，它有助于排查问题。

此外，每个 Power BI 刷新尝试分为两个操作：

数据 - 将数据加载到语义模型中
查询缓存–高级查询缓存和/或仪表板磁贴刷新

下图显示了刷新历史记录如何分隔这些操作，并提供有关每个操作的信息。

大量使用仪表板磁贴或高级缓存可能会延长刷新持续时间，因为这两个操作都会在每次刷新后将许多查询排队。可以减少仪表板数或禁用自动缓存刷新设置，以帮助减少查询数。

数据和查询缓存阶段彼此独立，但按顺序运行。首先运行数据刷新，成功后，运行查询缓存刷新。如果数据刷新失败，则不会启动查询刷新。有可能数据刷新成功运行了，但查询缓存刷新失败。

使用 XMLA 终结点进行的刷新不会在“刷新历史记录”窗口中显示尝试详细信息。

刷新取消

如果要在高峰时间段停止刷新大型语义模型，则停止语义模型刷新非常有用。使用刷新取消功能停止刷新驻留在 Premium、Premium Per User (PPU) 或 Power BI Embedded 容量上的语义模型。

若要取消语义模型刷新，你必须是语义模型工作区的参与者、成员或管理员。语义模型刷新取消仅适用于使用导入模式或复合模式的语义模型。

注意

不支持作为数据市场的一部分创建的语义模型。

若要开始刷新，请转到要刷新的语义模型，然后选择“立即刷新”。

若要停止刷新，请执行以下步骤：

转到正在刷新的语义模型，然后选择“取消刷新”。
在“取消刷新”弹出窗口中，选择“是”。

最佳做法

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

此外，请考虑以下建议，以便为语义模型建立和维护可靠的数据刷新过程：

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

Power BI 中的数据刷新-QQ皇族馆