了解和优化数据流刷新

借助 Power BI 数据流，你可以连接、转换、合并和分发数据以进行下游分析。 数据流中的一个关键元素是刷新过程，该过程将应用你在数据流中创作的转换步骤，并更新项本身的数据。

若要了解运行时间、性能以及数据流是否得到充分利用，可以在数据流刷新后下载刷新历史记录。

了解刷新

有两种类型的刷新适用于数据流：

• 完整，它会完整刷新并重载数据。

• 增量(仅限 Premium) ，它根据你配置的基于时间的规则（表示为筛选器）处理数据子集。 对日期列的筛选用于动态地将数据划分为 Power BI 服务中的多个范围。 配置增量刷新后，数据流会自动更改查询以包括按日期筛选。 你可以使用 Power Query 中的“高级编辑器”编辑自动生成的查询，以便微调或自定义刷新。 如果自带 Azure Data Lake Storage，则可以根据已设置的刷新策略查看数据的时间段。

  备注

  你可以详细了解增量刷新及其工作原理。

增量刷新支持 Power BI 中的大型数据流，并具备以下优势：

• 首次刷新后，刷新速度更快，原因如下：

• Power BI 将刷新用户指定的最后 N 个分区（分区为日/周/月，依此类推），或者：

• Power BI 仅刷新需要刷新的数据。 例如，仅刷新 10 年数据集中最近 5 天的数据。

• 只要指定了要检查更改的列，Power BI 就只刷新已更改的数据。

• 刷新更可靠 - 不再需要维护与不稳定的源系统的长期连接。

• 降低资源消耗 - 要刷新的数据量减少，这降低了内存和其他资源的整体消耗。

• Power BI 会尽可能对分区采用并行处理，这也可以加快刷新速度。

在以上任一刷新方案中，如果刷新失败，则不会更新数据。这意味着在最近一次刷新完成之前，或者进行手动刷新并且正常完成之前，你的数据可能还是旧数据。 刷新发生在分区或实体上，因此，如果增量刷新失败，或者实体出现错误，则不会发生整个刷新事务。 换句话说，如果特定数据流的分区（增量刷新策略）或实体失败，则整个刷新操作将设置为失败，并且不会更新任何数据。

了解和优化刷新

为了更好地了解数据流刷新操作的执行方式，请导航到“数据流”>“设置”>“刷新历史记录”，查看数据流的刷新历史记录>>。 也可以在“工作区”>“上下文菜单(…)”>“刷新历史记录”中选择数据流>>。

“刷新历史记录”提供对刷新的概述，包括类型（按需或计划）、持续时间和运行状态。 若要查看 CSV 文件格式的详细信息，请选择刷新说明行最右侧的下载图标。 下载的 CSV 包含下表所述的属性。 与共享容量上基于 Pro 的数据流相比，Premium 刷新基于附加的计算和数据流功能提供更多信息。 因此，以下某些指标仅在 Premium 中提供。

数据流刷新指导

刷新统计信息提供了许多有用信息，可用于优化和提高数据流的性能。 在以下部分中，我们将介绍一些应用场景、需要注意的事项以及如何根据所提供的信息进行优化。

资源协调

在同一工作区中使用数据流可让编排任务变得简单直接。 如果在单个工作区中具有数据流 A、B 和 C，其链接方式为 A > B > C，那么在刷新源 (A) 时，下游实体也会刷新。 但是，如果刷新 C，则必须单独刷新其他数据流。 此外，如果在数据流 B（不包含在 A 中）中添加新数据源，则数据将不会在编排过程中进行刷新。

如果你想将不适合由 Power BI 进行托管编排的项目链接在一起，或者想进行混合和匹配，则可以使用 API 和/或使用 PowerAutomate。 若要进行编程刷新，可以参阅 API 文档和 PowerShell 脚本。 若要在不编写任何代码的情况下执行此操作，可以使用 Power Automate 连接器。 你可以看到详细的示例，其中包含针对顺序刷新的特定演练。

监视

使用本文前面介绍的增强刷新统计信息，可以获取每个数据流的详细刷新信息。 但是，如果你想查看数据流在租户范围或工作区范围内的刷新概况（也许是为了生成监视仪表板），则可以使用 API 或 PowerAutomate 模板。 同样，对于诸如发送简单或复杂通知之类的用例，你可以使用 PowerAutomate 连接器，或使用我们的 API 生成自己的自定义应用程序。

超时错误

优化执行提取、转换和加载方案所用的时间是理想之举。 在 Power BI 中，以下情况适合这样做：

• 某些连接器具有可配置的显式超时设置。 有关详细信息，请查看 Power Query 连接器参考

• 使用 Power BI Pro 运行 Power BI 数据流时，实体中长时间运行的查询或数据流本身也有可能出现超时。 Power BI Premium 工作区不存在该限制。

超时指导

Power BI Pro 数据流的超时阈值如下：

• 单个实体级别为两小时

• 整个数据流级别为三小时

例如，如果你的数据流包含三个表，那么，单个表所花费的时间不能超过两小时，并且如果持续时间超过三小时，则整个数据流将超时。

如果出现超时，请考虑优化数据流查询，并考虑在源系统上使用查询折叠。

另外，请考虑升级到 Premium Per User，该版本不受这些超时限制，并且由于许多 Power BI Premium Per User 功能而提供更高的性能。

持续时间较长

复杂或大型数据流可能需要更多时间来刷新，优化效果不佳的数据流也是如此。 以下部分提供了有关如何缓解刷新持续时间较长这一问题的指导。

有关刷新持续时间较长的指导

数据流最佳做法

改善数据流刷新持续时间较长问题的第一步是根据我们的最佳做法生成数据流。 值得注意的模式包括：

• 将链接实体用于稍后可在其他转换中使用的数据

• 使用计算实体缓存数据，以减轻源系统的数据加载和数据引入负担

• 将数据拆分为临时数据流和转换数据流，并将 ETL（提取、转换、加载）分离到不同的数据流中

• 优化展开表操作

• 遵循复杂数据流指导

接下来，它可以帮助你评估是否可以使用增量刷新。

使用增量刷新可以提升性能。 提交查询以执行刷新操作时，请务必将分区筛选器推送到源系统。 向下推送筛选意味着数据源应支持查询折叠，或者你可以通过函数或其他可帮助 Power Query 消除和筛选文件或文件夹的方法来表达业务逻辑。 大多数支持 SQL 查询的数据源都支持查询折叠，某些 OData 源还可以支持筛选。

但是，平面文件、blob 和 API 等数据源通常不支持筛选。 如果数据源后端不支持筛选器，则无法将其向下推送。 在这种情况下，混合引擎会在本地补偿和应用筛选器，这可能需要从数据源中检索完整数据集。 此操作可能导致增量刷新非常慢，并且该进程可能耗尽 Power BI 服务或本地数据网关（如果使用）中的资源。

由于已对每个数据源提供各种级别的查询折叠支持，建议执行验证以确保源查询中包含筛选器逻辑。 为了简化操作，Power BI 尝试使用 Power Query Online 的逐步折叠指示器为你执行此验证。 这些优化中有很多是设计时体验，但在发生刷新后，你将有机会分析和优化刷新性能。

最后，请考虑优化环境。 你可以通过纵向扩展容量、调整数据网关的大小和减少网络延迟来优化 Power BI 环境，具体优化如下：

• 当使用 Power BI Premium 或 Premium Per User 提供的容量时，可以通过增加 Premium 实例或将内容分配给其他容量来提升性能。

• 每当 Power BI 需要访问不能直接通过 Internet 获取的数据时，就需要一个网关。 你可以将本地数据网关安装在本地服务器或虚拟机上。 * 若要了解网关工作负载和大小调整建议，请参阅本地数据网关大小调整。 * 此外，评估是否可以先将数据引入临时数据流，然后在下游使用链接实体和计算实体引用它。

• 网络延迟会增加请求到达 Power BI 服务以及传输响应所需的时间，从而影响刷新性能。 Power BI 中的租户被分配到一个特定区域。 若要确定租户的位置，请参阅我的 Power BI 租户位于何处？ 当来自租户的用户访问 Power BI 服务时，他们的请求将始终路由到该区域。 请求到达 Power BI 服务后，服务就可以发送其他请求（例如，到基础数据源或数据网关的请求），这也会受到网络延迟的影响。

• 诸如 Azure 速度测试之类的工具可提供客户端与 Azure 区域之间的网络延迟的指示。 一般来说，为了尽量降低网络延迟的影响，请争取使数据源、网关和 Power BI 群集尽可能地靠近。 最好是位于同一区域。 如果网络延迟成为一个问题，请尝试将网关和数据源放在云托管的虚拟机内，以查找与 Power BI 群集更近的网关和数据源。

处理器时间较长

如果发现处理器时间较长，则可能是有耗费大量资源的转换未折叠，这是由于所应用的步骤数或正在进行的转换类型所致，这两种原因都会导致刷新时间较长。

有关处理器时间较长的指导

可通过两种方法优化处理器时间较长的问题。

首先，在数据源中使用查询折叠，这样应该可以直接减少数据流计算引擎上的负载。 数据源中的查询折叠可以让源系统完成大部分工作，让数据流以源的本机语言传递查询，而不必在初始查询后在内存中执行所有计算。

并非所有数据源都可以进行查询折叠，即使可以进行查询折叠，也可能会有数据流执行某些无法折叠到源的转换。 在这种情况下，可以使用增强型计算引擎，它是 Power BI 引入的一项功能，可以将性能（特别是转换性能）提升多达 25 倍。

使用计算引擎最大程度地提升性能

Power Query 对查询折叠具有设计时可见性，计算引擎列则提供有关是否使用内部引擎本身的详细信息。 当你有复杂的数据流并且要在内存中执行转换时，计算引擎非常有用。 这就是增强型刷新统计信息的作用所在，因为计算引擎列提供了有关是否使用引擎本身的详细信息。

以下部分提供了有关如何使用计算引擎及其统计信息的指导。

警告

在设计时，编辑器中的折叠指示器可能会显示：当使用来自其他数据流的数据时，查询不会折叠。 如果启用了增强计算，请检查源数据流，以确保源数据流上的折叠功能已开启。

有关计算引擎状态的指导

启用增强型计算引擎并了解各种状态非常有用。 在内部，增强型计算引擎使用 SQL 数据库读取和存储数据。 最好在此处针对查询引擎执行转换。 以下各段提供了各种情况，并对每种情况的处理进行了指导。

NA - 此状态表示未使用计算引擎，原因如下：你正在使用 Power BI Pro 数据流；你已将其显式关闭；你正在数据源上使用查询折叠；或者你正在执行复杂的转换，而这些转换不能使用 SQL 引擎来加速查询。

如果在等待较长时间后，仍然显示“NA”状态，请确保计算引擎已启用且未意外关闭。 推荐的一种模式是使用临时数据流，先将数据引入 Power BI 服务，一旦数据进入临时数据流，就在此数据的基础上生成数据流。 这种模式可以减少源系统上的负载，通过与计算引擎结合使用，可提高转换速度，改善性能。

已缓存 - 如果看到“已缓存”状态，则表示数据流数据已存储在计算引擎中，可在执行其他查询时引用。 这种数据非常适合用作链接实体，因为它会被缓存起来供下游使用，而且不需要在同一个数据流中多次刷新。 将其用于 DirectQuery 也是一个不错的选择。

缓存后，对初始引入的性能提升将在以后在同一数据流或同一工作区中的不同数据流中得到体现。

如果实体的持续时间较长，请考虑关闭计算引擎。 为了缓存实体，Power BI 将其写入存储和 SQL。 如果它是一次性实体，那么用户获得的性能收益可能抵不过重复引入所付出的代价。

已折叠 - 已折叠意味着数据流能够使用 SQL Compute 读取数据。 计算实体使用 SQL 中的表读取数据，使用的 SQL 与查询的构造有关。

如果在使用本地或云数据源时，首先将数据加载到临时数据流中，然后在此数据流中引用该数据，则会显示“已折叠”状态。 此状态仅适用于引用另一个实体的实体。 这意味着你的查询是在 SQL 引擎之上运行的，因此有可能通过 SQL Compute 获得性能提升。 为了确保你的转换由 SQL 引擎进行处理，请使用支持 SQL 折叠的转换，例如查询编辑器中的合并（联接）、分组（聚合）和追加（联合）操作。

已缓存 + 已折叠 - 如果看到“已缓存 + 已折叠”状态，可能表示数据刷新已优化，因为你有一个实体既引用另一个实体，又被上游的另一个实体引用。 这种查询也在 SQL 之上运行，因此，也有可能通过 SQL Compute 获得性能提升。 为确保获得最佳性能，请使用支持 SQL 折叠的转换，例如查询编辑器中的合并（联接）、分组（聚合）和追加（联合）操作。

计算引擎性能优化指导

以下步骤将使工作负载能够触发计算引擎，从而不断提升性能：

同一工作区中的计算实体和链接实体：

对于引入，重点是尽可能快地将数据导入存储，并且仅当筛选器能够减小总体数据集大小时才使用筛选器。 将转换逻辑与此步骤分开。 接下来，使用链接实体或计算实体将转换和业务逻辑分离到同一工作区中的单独数据流；这样做可以使引擎激活并加快计算速度。 打个简单的比方，这就像是在厨房里准备食物：食物准备通常是一个与收集原材料不同的单独步骤，也是把食物放进烤箱的前提。 同样，逻辑也需要单独准备，然后才能利用计算引擎。

确保执行折叠的操作，例如合并、联接、转换及其他操作。

同时，在已发布的指导原则和限制内生成数据流。

计算引擎已启用，但性能较差：

在调查计算引擎已启用但性能较差的情况时，请执行以下步骤：

• 限制跨工作区存在的计算实体和链接实体。

• 如果在启用计算引擎的情况下进行初始刷新，数据将写入数据湖和缓存中。 这种双重写入会导致刷新速度变慢。

• 如果你有一个链接到多个数据流的数据流，请确保计划对源数据流的刷新，使其不会同时刷新。

注意事项和限制

使用 Power BI Pro 许可证时，数据流刷新限制为每天 8 次。