Power BI Dataflows Gen1（数据流 Gen1）上线多年，一直是不少企业在 Power Query（数据查询）逻辑复用上的主力。但微软的重心早已转向 Fabric Dataflows Gen2（CI/CD），Gen1 进入“遗留维护”状态，新功能基本不再追加。对很多团队来说，迁移不是“要不要做”的问题，而是“什么时候、以什么方式做”的问题。现在，微软在 Fabric 容量（Capacity）对应的工作区里，推出了 Dataflows Upgrade Wizard（数据流升级向导，预览版），把原本需要手动重建的迁移过程，压缩成一次有引导、有评估、可分批执行的操作。
这个向导的核心价值在于：它不要求你一次性把整个数据资产全部搬完。你可以先挑几个有代表性的数据流试水，验证结果没问题，再逐步扩大范围。升级过程中，原有的 Power Query 逻辑、数据流 ID、刷新计划、连接信息都会被保留，下游的 Semantic Model（语义模型）和报表不需要重新映射数据源。换句话说，这是一条“低摩擦”的现代化路径，而不是“推倒重来”。
升级向导到底帮你做了什么
打开某个 Dataflows Gen1 项旁边的菜单，选择 Upgrade to Dataflow Gen2 (Preview)，向导就会启动。它允许你从同一个工作区里勾选多个 Gen1 数据流一起升级。在真正动手之前，向导会对每个数据流做一次“体检”，给出三类状态：
- Ready to migrate（可直接迁移）：没有检测到需要手动处理的步骤，但建议你仍然过一遍已知限制清单，因为评估并不能覆盖所有边界情况。
- Needs Attention（需要注意）：可以继续升级，但需要你先了解具体原因，并在升级前后完成推荐操作。
- Upgrade unavailable（无法升级）：你不是该数据流的所有者，需要先让所有者操作，或者使用 Take over（接管）功能获得所有权。
这个评估环节很实用。它能识别出增量刷新（Incremental Refresh）、Bring Your Own Lake（自带湖存储）、链接数据流（Linked Dataflows）、可能的 DirectQuery（直接查询）下游消费者，以及命名冲突等问题。把鼠标悬停在状态上，就能看到具体原因。虽然目前评估覆盖的场景还不算全面，但至少能让你在动手前对“升级范围”和“后续动作”有个清晰预期。
升级后，功能上限和运维体验都变了
Fabric Dataflows Gen2（CI/CD）并不是简单换个壳。它继承了 Gen1 的 Power Query 编辑体验，但底层能力完全不同。最直观的变化是数据目标（Destinations）大幅扩展：Azure SQL Database、Azure Data Explorer (Kusto)、Azure Data Lake Storage Gen2、Fabric Lakehouse 表/文件、Fabric Warehouse、Fabric KQL Database、Fabric SQL Database、SharePoint Files、Snowflake、PostgreSQL 都在支持列表里。你不需要在升级当天就把所有目标都配上，先保持原有输出，等团队准备好再逐步添加。
作为 Fabric 原生项，Gen2（CI/CD）天然支持 Git 集成和 Fabric 部署管道。数据流定义可以纳入版本控制，团队能走标准的开发、测试、生产发布流程。刷新历史（Refresh History）和 Fabric 监控体验也提供了更细粒度的运行细节，排查失败时不用再靠猜。
性能方面，Fast Copy（快速复制）、Modern Evaluator（现代计算引擎）、Partitioned Compute（分区计算）这些能力针对不同负载模式做了优化。微软官方公布的基准测试显示，Gen2 的刷新时间相比 Gen1 提升了 1.6 到 21 倍。当然，具体提升幅度取决于你的数据量、容量大小、连接器类型、网关使用情况和查询设计，所以拿自己的典型工作负载实测一下，比看任何宣传数字都靠谱。
成本结构也值得关注。Gen2（CI/CD）采用分层定价（Tiered Standard Compute），每个 mashup-engine 查询的前 10 分钟按标准费率计费，之后费率降低。高规模计算（High-scale Compute）和 Fast Copy 数据传输则单独计费。对于长时间运行的复杂查询，这种模式比 Gen1 的固定计费更灵活。
另外，Copilot in Data Factory（数据工厂中的 Copilot）已经能辅助 Gen2 数据流的编写工作。它可以用自然语言生成转换步骤、创建查询，甚至总结一段查询及其应用步骤的含义。对于接手别人写的数据流，或者排查复杂逻辑，这个能力能省下不少时间。
升级前必须知道的几个关键点
向导虽然简化了操作，但有几个事实需要提前接受：
- 升级不可逆。升级完成后，原来的 Power BI Dataflows Gen1 项会被替换成 Fabric Dataflows Gen2（CI/CD）项，无法回退。如果你确实需要保留原 Gen1 项，就不要用升级向导，而是用 Save As（另存为） 创建一个新的 Gen2 项。
- ID 保持不变。这是升级向导最贴心的设计之一。数据流的 ID 被保留，意味着下游的 Semantic Model（语义模型）和报表不需要重新映射数据源。但要注意，数据流名称默认不变，除非评估检测到命名冲突。
- 升级后需要手动验证。向导跑完不代表万事大吉。你需要依次完成：刷新每个升级后的数据流确认数据加载正常；打开并保存每个下游数据流以重新绑定；处理评估中标记的 Needs Attention 项；检查是否有消费者还在用旧版 Power BI Dataflows 连接器，如果有，需要切换到新版 Power Platform Dataflows 连接器——这个情况评估是检测不到的。
迁移节奏自己定，但别拖太久
微软明确表示，Gen1 会继续以遗留状态运行，但新功能投资基本都集中在 Gen2 上。这意味着，你现在不升级，短期内不会出问题，但长期来看，你会错过性能优化、新数据目标、Git 集成、Copilot 辅助这些持续演进的能力。而且，越晚迁移，数据资产积累越多，手动重建的成本就越高。
升级向导的价值在于，它把“一次性大迁移”拆成了“可分批执行的小步骤”。你可以先从一两个数据流开始，验证输出结果和下游依赖，再逐步扩大范围。对于详细的迁移规划和资产盘点，微软也提供了专门的迁移指南（Migrate from Dataflow Gen1 to Dataflow Gen2），建议在动手前先过一遍。
说到底，升级本身不是目的，现代化才是。向导帮你把“升级”这个动作变得足够轻，让你有余力去思考“现代化”的节奏——什么时候加新的数据目标，什么时候接入 Git 流程，什么时候用 Copilot 优化查询逻辑。先把数据流迁到 Gen2，再按需逐步引入新能力，这才是这条路径最合理的打开方式。
