wpf listview 切换数据源 位置不刷新_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 中。 数据集刷新要求因存储模式/数据集类型而异。

导入模式下的数据集

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

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

DirectQuery/LiveConnect 模式下的数据集

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

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

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

备注
“数据集”选项卡的“计划的缓存刷新”部分不适用于导入模式下的数据集 。 这些数据集不需要单独刷新磁贴，因为 Power BI 会在每次计划或按需数据刷新期间自动刷新磁贴。

推送数据集

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

备注
如 Power BI REST API 限制中所述，推送模式存在若干限制。

Power BI 刷新类型

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

数据刷新

对 Power BI 用户而言，刷新数据通常意味着根据刷新计划或按需将数据从原始数据源导入到数据集。 可以每天执行多次数据集刷新，如果基础源数据经常更改，则可能必须执行多次刷新。 Power BI 将共享容量上的数据集限制为每天最多刷新 8 次。 如果数据集驻留在 Premium 容量上，则每天最多可在数据集设置中计划 48 次刷新。 有关详细信息，请参阅本文后面的配置计划刷新。 在以编程方式使用 TMSL 或 PowerShell 进行配置时，XMLA 终结点已启用读写操作的 Premium 容量中的数据集支持无限刷新操作。

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

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

OneDrive 刷新

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

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

重要
注意如何在 OneDrive 上处理文件管理。 如果将 OneDrive 文件设置为数据源，Power BI 在执行刷新时会引用该文件的项 ID，这可能会在某些情况下引发问题。 请考虑这种情况：你有主文件 A 和该文件的生产副本 B，同时你为文件 B 配置了 OneDrive 刷新。如果随后复制文件 A 而不是文件 B，则复制操作会删除旧的文件 B，并新建具有不同项 ID 的文件 B，而这会中断 OneDrive 刷新 。 所以应改为上传并替换文件 B，这样即可保留相同的项 ID。

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

若要查看过去的同步周期，请检查刷新历史记录中的 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 次）的数据集关联的报表和仪表板，使用查询缓存的意义不大。

磁贴刷新

Power BI 为仪表板上的每个磁贴视觉对象维护一个缓存，并在数据更改时主动更新磁贴缓存。 换句话说，在数据刷新之后会自动进行磁贴刷新。 计划刷新操作和按需刷新操作都是如此。 还可以通过选择仪表板右上角的“更多选项”(...) 并选择“刷新仪表板磁贴”来强制进行磁贴刷新 。

由于它是自动发生的，因此可以将磁贴刷新视为数据刷新固有的一部分。 此外，你可能会注意到刷新持续时间随着磁贴数量的增加而增加。 磁贴刷新开销可能很大。

默认情况下，Power BI 为每个磁贴维护一个缓存，但如果使用动态安全性根据用户角色来限制数据访问（如 Power BI 行级别安全性 (RLS) 一文所述），则 Power BI 必须为每个角色和每个磁贴维护一个缓存。 磁贴缓存的数量乘以角色的数量。

如教程通过 Analysis Services 表格模型实现动态行级别安全性中所强调的那样，如果数据集通过 RLS 实时连接到 Analysis Services 数据模型，则情况会更加复杂。 在这种情况下，Power BI 必须为每个磁贴和每个查看过仪表板的用户维护和刷新缓存。 此类数据刷新操作的磁贴刷新部分会远远超出从源提取数据所花费的时间，且这种情况并不少见。 有关磁贴刷新的更多详细信息，请参阅磁贴错误故障排除。

报表视觉对象刷新

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

后续请看下篇文章。

文章来源：Microsoft Power BI官网
编辑翻译：Power BI学堂