Fabric 中的 Dataflow

Published: | Updated:
Picture of Ruben Van de Voorde
内容贡献者

Ruben Van de Voorde 是 Tabular Editor 的内容贡献者。他目前是 Datashift 的 Power BI 专家，致力于指导企业和社区在其数据文化中最大化 BI 的价值。

此内容由人工智能翻译，尚未经过人工编辑审核。图像和图表保持其原始语言。

要点速览

  • 当你希望在单个语义模型之外复用并治理 Power Query 转换时，应在语义模型中使用 Dataflow，而不要使用 Power Query，尤其是当同一套转换逻辑原本会被重复实现，并可能随着时间推移而逐渐偏离时。
  • Gen1 可在 Pro Workspace 中使用，但像 增量刷新、计算/链接实体以及 DirectQuery 等实用能力，需要 Premium 或 PPU 容量。 Gen2 需要 Fabric capacity，但可提供更好的生命周期自动化、更强的跨多种写入目标（Lakehouse、SharePoint 等）的复用性，并通过自动保存和后台验证带来更佳的用户体验。
  • 在 Gen2 场景下，Dataflows 非常适合以低代码方式进行数据接入、转换并写入多种数据存储目标。 从 CU 透视来看，笔记本通常更划算；在大规模或自定义需求（比如复杂的 Spark 逻辑、库、测试）上也仍然更占优势，但代价是更多工程开销。 Data Wrangler 在笔记本中提供了一个类似 Power Query 的 GUI，可为常见转换选择代码片段，并提供 Copilot 协助编写代码。

这段摘要由作者撰写，不是 AI 生成的。


本文将简要介绍 Dataflow 是什么、Gen1 与 Gen2 的差异、有哪些值得关注的更新，以及在导入型语义模型和 Fabric 笔记本中，Dataflow 相比 Power Query 的优势。

Dataflow 入门

Dataflow 是 Power BI（Dataflow Gen1）和 Microsoft Fabric（Dataflow Gen2）中的可复用、低代码数据转换项。 它们连接到数据源，执行以 Power Query M 定义的转换，并将生成的表持久化保存。 可以把它们理解为：把导入语义模型里的 Power Query 层“移出来”，从而让 Power Query 转换能够在语义模型之外独立复用并进行治理。

V004 Figure 2 - Screenshot of the Power Query Online UI in dataflow authoring experience. When transforming data from a source that gets periodic manual updates like Excel spreadsheets, dataflows can be a pragmatic and user-friendly choice for re-usability and refresh failure isolation

一些常见的 Dataflow 使用场景包括：

  • 将重复的数据转换集中化，并与语义模型解耦。
  • 将数据从多种来源移动到多种 Fabric 和 Azure 目标。
  • 对外提供来自某个源的数据——该源不适合让用户直接操作，或需要以更适合用户的格式呈现。

在实践中，Dataflow 处在一个最佳平衡点：介于嵌入到各个语义模型中的 Power Query（构建快，但难复用与治理）和完整的数据工程管道或笔记本（最灵活，但开销更大）之间。

下图有助于你理解 Dataflow 在 Fabric 与 Power BI 的“大局”中处于什么位置。

dataflows-in-the-fabric-landscape

Gen1 与 Gen2

Dataflow 已经存在一段时间了。 自 Microsoft Fabric 推出后，2 代产品并行存在：Dataflow Gen1（“Gen1”）和 Dataflow Gen2（“Gen2”）。 Gen2 仅在 Fabric 中提供，是 Gen1 的继任者，并以不同方式扩展了功能。 它们仍有重叠，但也有一些关键差异如下所示：

features-of-dataflows-gen1-and-gen2

  • 创作体验。 Gen1 与 Gen2 都在 Power BI 服务中使用 Power Query Online 体验，但 Gen2 提供自动保存（包括草稿）和后台验证。
  • 输出目标。 Gen1 默认将输出保存到 Power BI 提供的内部存储中，或保存到 由你提供的 ADLS Gen2 存储账户。 Gen2 可以将查询输出到 多种目标：Azure SQL 数据库表、Azure Data Explorer（Kusto）表、ADLS Gen2 文件、Fabric Lakehouse Delta 表、Fabric Lakehouse 文件、Fabric Warehouse 表、Fabric KQL 数据库表、Fabric SQL 数据库表以及 SharePoint 文件。 目标是按 每个查询 进行配置的，因此单个 Gen2 Dataflow 可以将不同查询加载到不同目标中。
  • 输出形态。 Gen1 会在托管存储中发布实体，设计用途是通过 Dataflow/CDM 连接器把它们当作表来使用，而不是作为用户自定义的文件。 Gen2 可以发布表或文件，其中“文件”是面向下游文件型工作流的一等输出目标。
  • 许可。 Gen1 可在 Pro Workspace 中使用。 Gen1 Dataflow 的一些重要功能，如增强计算引擎、DirectQuery、增量刷新以及计算/链接实体，仅在 Fabric、Premium 或 PPU 容量的 Workspace 中提供。 Gen2 要求 Workspace 运行在 Fabric 或 Fabric 试用容量上。
  • 执行与计算。 Pro Workspace 中的 Gen1 Dataflow 运行在共享的 Power BI 容量上，刷新限制更严格。 如果 Gen1 位于 Fabric、Premium 或 PPU 容量的 Workspace 中，则可以启用 增强计算引擎（ECE），随后就能用到针对该 Gen1 Dataflow 的 DirectQuery 等功能。 之后，也可以通过引用（链接实体）复用现有 Dataflow 中的查询，并将其用于新的 计算实体。 Gen2 Dataflow 运行在由 Fabric capacity 支撑的 Fabric SQL 计算引擎上，并且 会自动创建 Lakehouse、Warehouse 等暂存资产用于数据访问与存储。 这些暂存资产存在于 Workspace 中，并且 Microsoft 建议不要直接访问或修改它们。
  • 增量刷新。 Gen1 的增量刷新机制是 基于分区的。 分区会被选择性重新加载，并且随着时间推移，当它们移出增量范围时可能会被择机合并，例如将月合并为季度，以提升存储与查询性能。 Gen2 Dataflow 的增量刷新使用固定的 单一时间单位分桶（例如按天或按周或按月等），并在目标端对其处理的数据分桶采用替换方式写入（即在该时间范围内先删除再插入）。 它直接在 Gen2 Dataflow 编辑器中配置，并且有 明确的限制（例如分桶数量）。
  • 与其他 Fabric 资产的集成。 Gen1 默认的 Power BI 存储可通过语义模型和 Dataflow 中提供的 Power Query dataflows 连接器进行使用。 其他 Fabric 资产只有在你自行提供 ADLS Gen2 存储时，才能使用 Gen1 Dataflow。 对于 Gen2 Dataflow，其他 Fabric 资产属于第一类支持对象：可以将存储输出到前面提到的多种目标位置，管道也能编排 Gen2 Dataflow 的运行。
  • DevOps 与生命周期。 Gen1 Dataflow 在 Fabric 部署管道中受支持（但存在一些限制），但不支持 Workspace Git 集成。 在实际 CI/CD 中，这意味着你需要一些变通方法，例如通过 REST API 导出和导入 Gen1 Dataflow 定义。 Fabric 部署管道和 Workspace Git 集成都完全支持 Gen2 Dataflow。
  • 架构变更。 Gen1 以 Dataflow 管理的格式存储数据，因此架构以刷新时的结果为准。 更改 Dataflow 的架构会清空所有数据，并且始终需要全量重新加载。 相比之下，Gen2 可以输出到一些必须处理架构变更的目标：要么严格模式（固定架构，不匹配就失败），要么灵活模式（动态/托管：自动调整目标端架构以匹配）。
  • 监控。 Gen1 在 Power BI 服务的用户界面中为每个 Dataflow 提供刷新历史记录。 Gen2 Dataflow 的刷新记录可在“Monitoring Hub”界面中查看，并提供更多运行元数据和活动级别的详细信息。
  • 权限。 Gen1 Dataflow 可以供 Workspace 查看者使用，但不支持行级安全性。 Gen2 Dataflow 只能被 Workspace 参与者及以上角色使用；不支持查看者。 行级安全性可通过目标端实现。
  • Gateway 限制。 Gen1 和 Gen2 Dataflow 都只能为每个 Dataflow 使用一个 Gateway。 Gen2 目前在某些目标上存在已知的 Gateway 出站 1433 端口问题。
  • 平台限制。 共享容量上的 Gen1 限制更严格（例如刷新超时：每个表 2 小时、每个 Dataflow 3 小时），而且像增量刷新这类实用功能还受容量要求限制。 Gen2 的限制更具体，并且与 Data Factory 相关，例如权限和租户约束。
  • Copilot 和 AI 集成。 Gen1 Dataflow 没有任何 AI 集成或 Copilot 支持。 如果你已在 Fabric 中通过相应订阅配置好 Copilot，那么 Gen2 即支持Copilot，可通过自然语言提示创建查询并生成示例数据。

这些差异揭示了一个清晰的总体方向：在大多数情况下，Gen2 已经取代了 Gen1 Dataflow。 Microsoft 的开发重心显然在 Gen2 上，因此功能差距预计会进一步拉大。 如果你主要在 Pro/共享 Workspace 中工作，且暂时还没准备好采用 Fabric，那么 Gen1 仍然是一个务实的选择。 不过，在 Pro/共享 Workspace 中缺少增量刷新等高级功能，再加上更严格的刷新限制，可能会带来不小的掣肘。

Dataflows 与导入语义模型中的 Power Query

在导入模式语义模型中使用 Power Query 往往是最快的入门方式，但当你有多个模型、多个团队，或需要在整个租户/组织内保持一致的重复数据转换时，它的可扩展性就不理想了。

通常在以下场景下，Dataflow 更合适：

  • 跨模型复用转换。如果相同的转换逻辑在多个模型中重复实现，你不仅要承担跨模型维护的开销，还要面对模型之间逐渐偏离的风险。 把逻辑集中到一个 Dataflow 中可以降低维护成本，并消除偏离风险。
  • 可控的源系统访问。与其让每个语义模型或用户都直接访问源系统，不如让 Dataflow 成为受管的摄取与转换层。 当只希望使用源系统中的特定数据时，这一点尤其有用。
  • 刷新分离。 Dataflow 的刷新与语义模型的刷新相互独立。 它们可以按各自的计划运行；即使失败，也不会导致下游模型刷新失败。 这也意味着需要协调两层刷新：先是一个或多个 Dataflow(s)，然后才是语义模型。
  • 支持多使用者。 语义模型中的 Power Query 只能服务于该模型。 Gen2 Dataflow 可以将转换后的表落地到 Lakehouse 或 Warehouse，然后再供语义模型、笔记本、基于 SQL 的使用者等消费。

不过，在以下情况下，在语义模型中嵌入 Power Query 往往仍然是正确的选择：

  • 转换逻辑仅针对该模型，无法上推到上游 ，并且不太可能被其他模型复用。
  • 你希望只需要考虑一次刷新（也就是语义模型刷新）。
警告

选对工具

Dataflow 是为低代码的数据摄取与转换而设计的。 它们可以持久化结果，但无法替代你通常在 Warehouse 中采用的治理模式，例如稳定的架构、显式建模、数据血缘关系，以及受控的变更管理。 如果你发现 Dataflow 成了一切都依赖的核心系统，这通常说明应该引入 Lakehouse/Warehouse 层，并简化 Dataflow。


Dataflows 与 Fabric 笔记本

笔记本和 Dataflow 之所以有重叠，是因为两者都能摄取和转换数据。 差别不在于“能做什么”，而在于主要使用者是谁，以及你愿意承担多少工程化开销。

当你希望做到以下目标时，Dataflow 通常更合适：

  • 你希望优先优化简单性。 这最适合去中心化或自助服务场景：由非技术团队负责并拥有 ETL。
  • 在图形界面中用 Power Query M 做低代码转换。 Power BI 开发者通常已经会 Power Query，所以可以很快上手 Dataflow。
  • 用一种简单方式以不同格式发布可复用的表。 Gen2 可以按查询把表或文件落地到受支持的目标位置。
  • 在很少需要重工程化转换、且 Power Query M 已广泛采用的环境中，采用更轻量的 BI 摄取运营模式。

在以下情况下，笔记本通常是更好的选择：

  • 你希望优先优化成本。 在很多场景下，Fabric 中的笔记本通常被认为比替代方案更省钱、性能也更好（但并不是处处都这样）。
  • 你需要工程级的灵活性或可观测性，比如自定义库、测试、复杂逻辑和结构化日志。 这通常更适合集中式场景：由 BI 或 IT 团队负责 ETL 流程；或者去中心化团队更习惯用代码工作。
  • 你希望采用代码优先的生命周期。 笔记本通常用 PySpark、Python 或 T-SQL 编写。 当你使用 LLM 以及像 Claude Code 这样的编码代理来辅助笔记本开发时，这一点尤其值得关注。 Data Wrangler 通过提供 GUI 让你为常见转换挑选代码片段，并集成 Copilot 帮你写代码，从而降低用代码的“入门门槛”。
  • 工作负载通常很重或规模很大。

data-wrangler-a-gui-for-notebook-coding

开始使用 Dataflow

刚开始用 Dataflow 时，第一个决定是创建 Gen1 还是 Gen2 Dataflow：

  • 如果你不在 Fabric capacity 上，Gen1 是你唯一的选择。
  • 如果你能用 Fabric capacity，那么就可以考虑 Gen2。 不过，你也不一定非得选 Gen2。 如果语义模型会是 Dataflow 的唯一使用者，而且你不需要把数据落地到 Lakehouse/Warehouse/SharePoint 等，Gen1 可以作为务实的入门选择。
  • 如果 Dataflow 会被语义模型之外的对象使用，或者数据必须落地到 Lakehouse/Warehouse/SharePoint 等，Gen2 是唯一的 Dataflow 选项。

选定代际之后，接下来的选择主要与范围、契约和运维有关：

  • 让范围可复用，而不是模型专用。 Dataflow 在产出经过整理、用途广泛的表时最有价值。 如果你发现自己在添加只适用于某一个语义模型的转换，这说明这些逻辑更应该放到该语义模型的 Power Query 里。
  • 把输出架构当作契约。 无论是发布到 Gen1 的托管存储，还是 Gen2 的目标位置（Lakehouse、SharePoint 等），下游使用者都会依赖特定的列名、类型和含义。 如果其中任何一项在未提前通知的情况下发生变化，刷新就会失败，并可能影响用户。 当预计会频繁变更时，要提前规划（尤其是在 Gen2 目标位置中，你可以在严格或灵活的架构处理之间进行选择）。
  • 有意识地进行刷新编排。 把转换逻辑移到 Dataflow 会引入另一层刷新。 这种拆分可能是优势（独立计划、隔离失败），但也意味着你得确保在下游使用者开始刷新之前 ，Dataflow 已经成功刷新。
  • 根据谁需要数据来选择目标位置。 在 Gen2 里，输出目标位置是设计的一部分。 选择最符合消费模式的目标位置：
    • 当你想要一个持久、经过整理的层，并让多个语义模型、笔记本或基于 SQL 的使用者都能消费时，用 Lakehouse 或 Warehouse 的表。
    • 当下游流程是基于文件的（比如导出用于对外共享、或与 Spark 互操作）时，用文件。
  • 制定何时切换到笔记本的规则。 Dataflow 适合做低代码转换和简单的 ETL。 如果转换的工程复杂度变高（例如复杂算法、大规模联接等），Notebook 通常更适合作为长期方案。
  • 像对待共享资产一样给 Dataflow 命名并编写文档。 一旦被复用，Dataflow 就会成为高依赖性的对象。 采用清晰的命名、简短的说明和归属约定，方便大家（安全地）发现并采用它们。

从小处着手，以复用为优先进行优化，避免让 Dataflows 在无意中演变成一个 Warehouse。

进一步推荐阅读

 

结论

Dataflow 最好视为位于数据源与语义模型之间、可复用的低代码转换层。 在以 Pro 为主的 Power BI 场景中，Gen1 仍是务实之选；而在 Fabric capacity 上，Gen2 是更面向未来的选择——尤其当你需要更丰富的写入目标、更紧密的集成，以及更利于自动化的生命周期管理时。 如果转换的工程复杂度变高，或者成本/性能是首要考量，Notebook 往往更适合作为长期方案。

Related articles