借助 Power BI 数据流，可以连接到、转换、合并和分发数据以供下游分析。 数据流中的一个关键元素是刷新过程，它应用在数据流中创作的转换步骤，并更新项本身中的数据。
若要了解运行时间、性能以及是否充分利用数据流，可以在刷新数据流后下载刷新历史记录。
了解刷新
有两种类型的刷新适用于数据流：
Full，用于执行数据的完整刷新和重新加载。
增量（仅限高级），它根据所配置的基于时间的规则处理数据的子集（以筛选器表示）。 日期列上的筛选器动态将数据分区为 Power BI 服务中的范围。 配置增量刷新后，数据流会自动更改查询以包括按日期筛选。 可以在 Power Query 中使用 高级编辑器 编辑自动生成的查询，从而微调或自定义刷新。 如果自带 Azure Data Lake Storage，则可以根据设置的刷新策略查看数据的时间切片。
注释
若要详细了解增量刷新及其工作原理，请参阅 将增量刷新与数据流配合使用。
增量刷新使 Power BI 中的大型数据流具有以下优势：
第一次刷新后刷新速度更快，原因如下：
- Power BI 刷新用户指定的最后 N 个分区（其中分区为 day/week/month 等），或
- Power BI 仅刷新需要刷新的数据。 例如，仅刷新 10 年语义模型中的最后 5 天。
- 只要指定要检查更改的列，Power BI 将仅刷新已更改的数据。
刷新更可靠 - 不再需要维护与不稳定的源系统的长时间连接。
资源消耗减少 - 刷新的数据减少，减少了内存和其他资源的总体消耗量。
在可能的情况下，Power BI 对分区使用并行处理，这可能会导致刷新速度更快。
在上述任何刷新方案中，如果刷新失败，则数据不会更新。 在最新刷新完成之前，数据可能已过时，也可以手动刷新数据，然后可以完成且不会出现错误。 刷新发生在分区或实体上，因此，如果增量刷新失败，或者实体出错，则不会发生整个刷新事务。 换句话说，如果数据流的分区（增量刷新策略）或实体出现故障，则整个刷新操作将失败，并且不会更新任何数据。
了解和优化刷新次数
若要更好地了解数据流刷新作的执行方式，请导航到其中一个数据流来查看数据流的 刷新历史记录 。 选择更多选项(...)来处理数据流。 然后选择 “设置 > 刷新历史记录”。 还可以选择 工作区中的数据流。 然后选择 “更多选项”（...） > 刷新历史记录。
刷新历史记录概述了刷新，包括类型 - 按需或计划、持续时间和运行状态。 若要查看 CSV 文件形式的详细信息，请选择刷新说明行最右侧的下载图标。 下载的 CSV 包括下表中所述的属性。 高级刷新基于额外的计算和数据流功能提供更多信息，而基于 Pro 的数据流驻留在共享容量上。 因此，以下某些指标仅在高级版中可用。
| Item | Description | Pro | 高级 |
|---|---|---|---|
| 请求日期 | 计划时间刷新或立即单击刷新，以本地时间表示。 | ✔ | ✔ |
| 数据流名称 | 数据流的名称。 | ✔ | ✔ |
| 数据流刷新状态 | 对于实体，“已完成”、“失败”或“跳过”是可能的状态。 例如链接实体这样的用例是可能导致跳过的原因。 | ✔ | ✔ |
| 实体名称 | 表名。 | ✔ | ✔ |
| 分区名称 | 此项取决于数据流是否为高级数据流，如果 Pro 显示为 NA，因为它不支持增量刷新。 Premium 显示 FullRefreshPolicyPartition 或 IncrementalRefreshPolicyPartition-[DateRange]。 | ✔ | |
| 刷新状态 | 单个实体或分区的状态更新，提供正在刷新数据特定时间片段的状态。 | ✔ | ✔ |
| 开始时间 | 在 Premium 中，此项表示数据流为处理某个实体或分区而排队的时间。 如果数据流具有依赖项，并且需要等待上游数据流的结果集开始处理，这一次可能会有所不同。 | ✔ | ✔ |
| 结束时间 | 结束时间是数据流实体或分区完成的时间（如果适用）。 | ✔ | ✔ |
| 持续时间 | 数据流刷新的总运行时间（以 HH：MM：SS 表示）。 | ✔ | ✔ |
| 已处理的行 | 对于给定的实体或分区，数据流引擎扫描或写入的行数。 此项目可能并不总是包含基于所执行的作的数据。 如果未使用计算引擎，或者当使用网关处理数据时，可能会省略数据。 | ✔ | |
| 已处理的字节数 | 对于给定的实体或分区，数据流引擎写入的数据以字节表示。 在此特定数据流上使用网关时，不会提供此信息。 |
✔ | |
| 最大提交（KB） | Max Commit 是峰值提交内存，可用于诊断 M 查询未优化时的内存不足故障。 在此特定数据流上使用网关时，不会提供此信息。 |
✔ | |
| 处理器时间 | 对于给定的实体或分区，数据流引擎用于进行转换所花费的时间（以 HH:MM:SS 表示）。 在此特定数据流上使用网关时，不会提供此信息。 |
✔ | |
| 等待时间 | 对于给定的实体或分区，基于高级容量上的工作负荷，实体处于等待状态的时间。 | ✔ | |
| 计算引擎 | 对于给定的实体或分区，关于刷新操作如何使用计算引擎的详情。 值为： -那 - 折叠 -缓存 - 缓存 + 折叠 本文稍后将更详细地介绍这些元素。 |
✔ | |
| 错误 | 如果适用，则会按实体或分区描述详细的错误消息。 | ✔ | ✔ |
数据流刷新指南
刷新统计信息提供了可用于优化和加快数据流性能的宝贵信息。 在以下部分中，我们将介绍一些方案、需要注意的内容，以及如何根据提供的信息进行优化。
统筹
在同一工作区中使用数据流可以实现简单的编排。 例如，你可能在单个工作区中有数据流 A、B 和 C，并且链接类似于 A > B > C。如果刷新源（A），下游实体也会刷新。 但是，如果刷新 C，则必须单独刷新其他项。 此外，如果在数据流 B 中添加新的数据源（A 中不包括该数据源），则数据不会作为业务流程的一部分进行刷新。
你可能希望将不符合 Power BI 执行的管理编排的项链接在一起。 在这些方案中，可以使用 API 和/或使用 Power Automate。 可以参考 API 文档 和 PowerShell 脚本 进行编程刷新。 Power Automate 连接器支持在不编写任何代码的情况下执行此过程。 可以查看详细示例，并进行顺序刷新的特定演练。
监测
使用本文前面所述的增强刷新统计信息，可以获取每个数据流的详细刷新信息。 但是，如果您希望查看以租户范围或工作区范围的刷新概述为特征的数据流，以便生成监控仪表板，可以使用 API 或 Power Automate 模板。 同样，对于 发送简单通知或复杂通知等用例，可以使用 Power Automate 连接器或使用 API 生成自己的自定义应用程序。
超时错误
优化执行提取、转换和加载（ETL）方案所需的时间是理想的。 在 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 可用的容量时，可以通过增加高级实例或将内容分配给其他容量来提高性能。
每当 Power BI 需要访问不能直接通过 Internet 使用的数据时，都需要网关。 可以在本地服务器上或虚拟机上安装本地 数据网关 。
- 若要了解网关工作负荷和大小调整建议，请参阅 本地数据网关大小调整。
- 此外，还评估先将数据引入暂存数据流，并使用链接实体和计算实体在下游引用数据。
网络延迟可以通过增加请求到达 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 计算读取数据。 计算实体使用 SQL 中的表读取数据，使用的 SQL 与查询的构造相关。
如果在使用本地或云数据源时，您首先将数据加载到过渡数据流中，并在此数据流中进行了引用，则会显示折叠状态。 此状态仅适用于引用另一个实体的实体。 这意味着查询是在 SQL 引擎的基础上运行的，并且它们有可能通过 SQL 计算进行改进。 若要确保 SQL 引擎处理您的转化，请使用支持 SQL 折叠的转化，例如在查询编辑器中进行合并（联接）、分组依据（聚合）和追加（联合）操作。
缓存 + 折叠 - 当你看到 缓存 + 折叠时，数据刷新可能会得到优化，因为你拥有一个实体，该实体不仅引用了另一个实体，还被上游的另一个实体引用。 此作还会在 SQL 上运行，因此，也有可能通过 SQL 计算进行改进。 为了确保获得最佳性能，请在查询编辑器中使用支持 SQL 折叠的转换，例如合并（联接）、分组（聚合）和追加（联合）作。
计算引擎性能优化指南
以下步骤使工作负荷能够触发计算引擎，从而始终提高性能。
在同一工作区中计算和链接的实体：
若要 引入，请专注于将数据尽快放入存储中，仅当筛选器减少整体语义模型大小时，才使用筛选器。 使转换逻辑与此步骤分开。 接下来，将转换逻辑和业务逻辑划分为同一工作区中的单独的数据流。 使用关联实体或计算得出实体。 这样，引擎就可以激活和加速计算。 对于简单的类比来说，它就像厨房里的食物准备：食物准备通常是一个独立且不同的步骤，与收集原料分开，并且是将食物放入烤箱前的必需步骤。 同样，你需要单独准备你的逻辑，以便能够充分利用计算引擎。
确保执行折叠操作，例如合并、连接、转换及其他操作。
此外， 在已发布的准则和限制内生成数据流。
计算引擎打开时，但性能缓慢：
在调查计算引擎已开启但性能不佳的情况时，请执行以下步骤：
- 限制工作区中存在的计算实体和链接实体。
- 如果您的初始刷新是在计算引擎开启情况下进行的，数据将写入数据湖和缓存中。 这种双重写入会导致刷新速度较慢。
- 如果数据流链接到多个数据流，请确保计划源数据流的刷新，以便它们不会同时刷新。
注意事项和限制
Power BI Pro 许可证的数据流刷新限制为每天 8 次刷新。