本文介绍了 从 Dataflow Gen1 迁移到 Dataflow Gen2时可以考虑的不同迁移方案。 它还提供指导和执行建议。 这些方案可能会激励你根据业务需求和情况确定正确的迁移方法。
在迁移数据流时,重要的是要超越仅仅复制现有解决方案的思维。 相反,我们建议利用数据流 Gen2 的最新创新和功能来现代化解决方案。 此方法可确保解决方案能够支持不断增长的业务需求。
例如,数据流 Gen2 具有名为 快速复制的功能,这大大减少了为某些转换和连接器引入数据所需的时间。 Dataflow Gen2 还改进了增量刷新,通过仅更新已更改的数据来优化数据刷新过程。 这些改进不仅能提高性能和效率,还能确保解决方案规模化。
重要
Dataflow Gen1 和 Dataflow Gen2 的 CPU 消耗可能因多种原因而有所不同,例如使用 Dataflow Gen2 中的新功能,包括湖屋暂存和数据仓库计算。 我们建议在迁移数据流之前,通过深入分析(例如概念证明 (POC))来量化 Dataflow Gen1 和 Dataflow Gen2 之间的 CPU 消耗差异。
迁移方案
数据流提供了一个通用的平台,用于创建可缩放的 ETL(提取、转换和加载)和 ELT(提取、加载和转换)解决方案,满足从 个人 BI 到 企业 BI的一系列使用方案。
下面是三种可能启发本文的迁移方案:
- 个人或团队使用情况:小型团队或个人使用数据流自动执行数据引入和准备任务,使他们能够专注于数据分析和见解。 例如,团队可以使用数据流从各种源中提取数据,例如Microsoft Excel 或Microsoft SharePoint。 其数据流根据其特定需求转换源数据,并将其加载到语义模型中,以便进行报告。
- 部门使用情况:组织内的部门使用数据流来管理更大的数据源和复杂的转换。 他们可能会创建可组合的数据流,以促进跨部门报表的可重用性和一致性,确保所有团队成员都处理同一版本的数据。
- 企业使用情况:在企业级,数据流有助于大规模跨多个部门引入大量数据。 它们充当一个集中式数据准备层,可馈送成许多语义模型,支持广泛的商业智能和分析应用程序。 整个组织都能受益于可靠且最新的数据,从而在各个层面实现合理的决定。
在上述每个方案中,数据流都有助于创建可靠且可缩放的 ETL/ELT 解决方案,这些解决方案可以随团队、部门或组织的需求而增长。 设计良好的数据流可确保数据管理过程保持高效且有效。
有关使用方案的详细信息,请参阅 Microsoft Fabric 实现规划。
迁移方案 1
在此迁移方案中,组织使用 Power BI 数据流进行自助数据准备,以支持个人或团队使用方案。 数据流包含在分配给 Fabric 容量的单个工作区内。
数据流创建者希望利用数据流 Gen2 的高级功能进行创作工作。 同时,他们计划在分阶段迁移期间暂时继续使用数据流表作为数据源。 此方法可确保内容创建者在使用现有 Power BI 语义模型、Excel 电子表格或 Dataverse 表时的易操作性和连接性,至少在过渡到支持的数据目标源完成之前是这样。
若要迁移其解决方案,数据流创建者需要:
- 如果创建新的工作区来存储新的数据流,请更新工作区 ID。
- 将现有解决方案从原始(Gen1)数据流 ID 更新为新的(Gen2)数据流 ID。
下面是一个示例查询,该查询已更新以便检索日期维度表数据。
let
Source = PowerPlatform.Dataflows(null),
Workspaces = Source{[Id="Workspaces"]}[Data],
Workspace = Workspaces{[workspaceId="<enter new workspace ID>"]}[Data],
DataflowId = Workspace{[dataflowId="<enter new dataflow ID"]}[Data],
DimDateTable = DataflowId{[entity="DimDate", version=""]}[Data]
in
DimDateTable
提示
如果在语义模型中对 workspaceId
和 dataflowId
值进行参数化,则可以使用数据集 - 更新组中的参数 REST API 操作以编程方式更新 mashup 参数详细信息。
重要
虽然可以使用数据流连接器 获取数据,但使用数据流 Gen2 时不建议使用此方法。 相反,我们建议尽可能使用数据目标功能将所有创建的表从 Dataflow Gen2 输出到 Fabric 项或其他目标。 这是因为数据流连接器使用基础系统实现存储层(称为 DataflowsStagingLakehouse),在添加新功能或功能时可能会更改。
迁移方案 2
在此迁移方案中,组织使用 Power BI 数据流进行自助服务数据准备,以支持跨多个工作区的可组合数据流和链接表的部门使用方案。
数据流创建者希望利用数据流 Gen2 的高级功能进行创作,同时有效地将数据流表共享和输出到 Fabric Lakehouse。 此方法利用 OneLake 快捷方式。 OneLake 快捷方式通过减少传统上与跨工作区链接表关联的进程延迟以及消除冗余数据副本来简化解决方案管理。
若要迁移其解决方案,数据流创建者需要:
- 将链接表替换为 OneLake 快捷方式,使下游使用者能够直接访问数据。
- 通过将
PowerPlatform.Dataflows
或PowerBI.Dataflows
函数替换为 Fabric 中Lakehouse.Contents
数据访问函数来更新现有解决方案和转换查询。
下面是已更新为从客户维度表检索数据的示例 PowerQuery 查询。
let
Source = Lakehouse.Contents([]),
WorkspaceId = Source{[workspaceId="<0000aaaa-11bb-cccc-dd22-eeeeee333333>"]}[Data],
LakehouseId = WorkspaceId{[lakehouseId="1111bbbb-22cc-dddd-ee33-ffffff444444"]}[Data],
DimCustomerTable = LakehouseId{[Id="DimCustomer", ItemKind="Table"]}[Data]
in
DimCustomerTable
注意
可以通过使用 XMLA 终结点,并更新表的分区 M 表达式,以编程方式编辑发布到 Fabric 的 Power BI 语义模型中的查询表达式。
但是,请注意,使用 XMLA 终结点修改语义模型后,将无法从 Power BI 服务下载它。
迁移方案 3
在此迁移方案中,组织使用 Power BI 数据流进行自助数据准备,以支持跨多个工作区的可组合数据流的部门使用方案。
数据流创建者希望利用 Dataflow Gen2 的高级功能进行创作,同时从具有精细用户权限的 Fabric 仓库输出和共享数据流表。 此方法提供灵活性,可以通过 行级别安全性(RLS)、列级安全性(CLS)以及 动态数据掩码(DDM)来实现数据访问。
若要迁移其解决方案,数据流创建者需要:
- 通过 SQL 计算引擎的 精细权限授予数据访问权限,通过限制对特定表和架构的访问以及实现 RLS 和 CLS,从而为某些用户提供更选择性的访问。
- 通过将
PowerPlatform.Dataflows
或PowerBI.Dataflows
函数替换为 Fabric 中Fabric.Warehouse
数据访问函数来更新现有解决方案和转换查询。
下面是已更新为从客户维度表检索数据的示例 PowerQuery 查询。
let
Source = Fabric.Warehouse([]),
WorkspaceId = Source{[workspaceId="0000aaaa-11bb-cccc-dd22-eeeeee333333"]}[Data],
WarehouseId = WorkspaceId{[warehouseId="1111bbbb-22cc-dddd-ee33-ffffff444444"]}[Data],
DimCustomerTable = WarehouseId{[Schema="dbo", Item="DimCustomer"]}[Data]
in
DimCustomerTable
迁移指南
我们建议您整理您的数据流和依赖项的清单。 我们还建议考虑使用 Power Query 模板。
库存
为了帮助你规划迁移,第一步是清点数据流和依赖于数据流的所有下游解决方案。 识别依赖项有助于避免停机和中断。
- 数据流作为 Power BI 中的源
- 使用数据流 - 获取组内上游数据流 REST API 操作,以识别使用链接表的数据流之间的世系和依赖项。 值得注意的是,链接表的深度最多可以有 32 个引用。
- 或者,可以使用 语义链接实验室
list_upstream_dataflows
函数来简化以递归方式调用Get Upstream Dataflows In Group
REST API 操作的过程。 该函数循环访问所有链接的数据流,直到遇到包含空值的记录,指示链的末尾。
- 或者,可以使用 语义链接实验室
- 使用管理员 - 数据集 GetDatasetToDataflowsLinksInGroupAsAdmin REST API 操作编译一个清单,列出在工作区中使用数据流的 Power BI 语义模型,并确定需要更新的模型。
- 使用 Microsoft Fabric 扫描程序 API 从租户中的语义模型中检索混合查询表达式。 然后,可以在表达式中搜索任何数据流 ID,以了解整个租户的完整世系。
- 使用数据流 - 获取组内上游数据流 REST API 操作,以识别使用链接表的数据流之间的世系和依赖项。 值得注意的是,链接表的深度最多可以有 32 个引用。
- 数据流作为 Power Apps 中的源
- 访问应用解决方案 Power Platform 数据流中数据流表的混合查询表达式。 然后,可以在表达式中搜索任何数据流 ID,以了解租户内应用程序之间的完整世系。 若要了解如何在 Microsoft Dataverse 上运行的 Dynamics 365 中安装和管理应用,请参阅 管理 Power Apps。
- 数据流作为 Excel 中的源
- 虽然 Excel 工作簿没有 REST API 来跟踪来源和依赖项,但可以使用 Visual Basic for Applications(VBA)和 WorkbookConnection 对象 来确定连接字符串是否包含文本
Provider=Microsoft.Mashup.OleDb.1
,这表示 Power Query 连接。 此外,可以使用 WorkbookQuery.Formula 属性提取 Power Query 公式。 - 跟踪数据流的世系后,建议更新 Excel for Fabric 项中的现有数据流连接,如下所示:
- 要访问 Fabric 湖屋、仓库或 SQL 数据库的 SQL 分析终结点,请使用 SQL Server 连接器,该连接器使用
Sql.Database
数据访问功能。 - 若要访问 Fabric Lakehouse 文件内容,请使用 Azure Data Lake Gen2 存储连接器,该连接器使用
AzureStorage.DataLake
数据访问函数。 - 若要访问 Fabric eventhouse 数据库,请使用 Azure 数据资源管理器连接器,该连接器使用
AzureDataExplorer.Contents
数据访问函数。
- 要访问 Fabric 湖屋、仓库或 SQL 数据库的 SQL 分析终结点,请使用 SQL Server 连接器,该连接器使用
- 虽然 Excel 工作簿没有 REST API 来跟踪来源和依赖项,但可以使用 Visual Basic for Applications(VBA)和 WorkbookConnection 对象 来确定连接字符串是否包含文本
Power Query 模板
Power Query 模板 简化在不同 Power Query 集成之间传输项目的过程。 它们有助于简化其他可能很复杂且耗时的任务。 模板将整个 Power Query 项目(包括脚本和元数据)封装到单个可移植文件中。
Power Query 模板旨在与各种集成(如 Power BI 数据流(Gen1)和 Fabric 数据流(Gen2))兼容,以确保这些服务之间的平稳转换。
相关内容
有关本文的详细信息,请查看以下资源:
Fabric 合作伙伴可用于帮助组织在迁移过程中取得成功。 若要与 Fabric 合作伙伴联系,请访问 Fabric 合作伙伴门户。