阶段 1：迁移策略和规划

本文是 Azure Synapse Spark 到 Microsoft Fabric 迁移最佳做法系列中的第 1 阶段。

在迁移任何笔记本、Spark 作业定义、池或湖元数据之前，请从此处开始。 本文可帮助你评估 Synapse Spark 系统的范围，选择与对风险的承受能力和交付时间表相匹配的迁移方法，并了解影响规划的 Fabric（指技术框架）差异。

在此步骤结束时，你应该知道需要迁移的内容、要使用的迁移模式、主要兼容性风险所在以及需要考量的回滚或并行运行的约束条件。

在这篇文章中，你将学会如何：

• 评估 Synapse Spark 资源使用情况。
• 在迁移并转换、分阶段现代化和并行执行之间进行选择。
• 考虑回滚和同步约束。
• 查看 Synapse Spark 与 Fabric Spark 之间的主要功能和体系结构差异。

评估 Synapse Spark 使用情况

Azure Synapse Analytics包含多个工作负荷类型。 本指南重点介绍如何将 Spark 池、笔记本、Spark 作业定义、Lake 数据库和 Hive 元存储元数据迁移到Microsoft Fabric。 有关专用 SQL 池、管道、数据资源管理器和安全迁移指南，请参阅配套指南。

运行Fabric评估工具

在规划迁移之前，请运行Fabric评估工具，生成 Synapse 源工作区的综合报告。 该工具会扫描工作区并聚合所有对象的摘要（Spark 池、笔记本、Spark 作业定义、湖数据库、链接服务及其配置），从而清楚地了解迁移范围。

1. 下载该工具。 Fabric评估工具在 微软 Fabric 工具箱 GitHub 存储库的 microsoft/fabric-toolbox 中提供。

2. 运行评估。 将工具指向Azure Synapse工作区。 它扫描所有与 Spark 相关的项，并生成包含对象计数、配置、依赖项和潜在兼容性问题的报表。

3. 查看报告。 使用评估输出了解迁移的范围：需要迁移多少个笔记本、池、SDK 和数据库、哪些链接服务正在使用，以及可能存在哪些潜在的阻止程序（GPU 池、不支持的功能和其他）。

迁移模式

根据组织约束、风险容忍度和时间线选择迁移模式。

提取迁移模式

使用迁移助手一次性迁移所有 Spark 工作负载，但更改最少。 专注于尽快在 Fabric 中运行笔记本和作业 — 只重构导致中断的部分（例如链接服务、文件路径、不支持的 API）。 接受当前体系结构 as-is。

在以下情况下使用“迁移并提升”方法：

• Synapse 工作区即将在固定截止时间停用，需要快速移动。
• Spark 工作负载已构建良好（Delta-first、干净代码、很少有链接服务依赖项）。
• 工作区的占用空间足以进行一次性迁移，你的团队可以在一个迭代周期内完成重构工作。
• 下游使用者（Power BI API）可以容忍短暂的切换窗口。

分阶段现代化

按优先级逐步迁移工作负载，并在此过程中重新构建架构。 首先从最高值或最低风险工作负荷开始。 在迁移每个批处理时，将 Spark 池合并到更少的环境中，采用 Lakehouse 最佳做法（Delta-first、V-Order for BI 使用者）、启用 NEE，并为 Direct Lake 重新设计。

在以下情况下使用分阶段现代化：

• 你有一个大型或复杂的 Synapse 环境，其中包含多个团队和不同的工作负载，无法一次性迁移。
• 当前的架构中存在需要解决的技术债务（非 Delta 格式、挂载点依赖关系、扩展过大的 Spark 池）。
• 在时间线上具有灵活性，并希望在迁移期间提高性能和成本效益。
• 不同的工作负荷具有不同的所有者，需要独立的迁移计划。

并行运行模式

在转换期间同时运行这两个环境。 将新的 Spark 工作负载路由到 Fabric，而旧版工作负载在 Synapse 上继续运行。 在切换之前，通过并排比较结果进行验证迁移的工作负载。 随着信心增强，逐渐停用 Synapse。

在以下情况下使用并行运行：

• 工作负荷具有严格的 SLA 或法规要求，要求在切换之前进行充分验证。
• 在利益干系人批准退役之前，你需要证明Fabric的性能达到或超过Synapse。
• 下游使用者（仪表板、API、ML 模型）在转换期间不能容忍任何差异。
• 你正在迁移生产流水线，其中错误的结果具有重大业务影响（财务报告、合规性）。

并行运行引入了必须提前设计的数据同步问题。 选择以下模式之一：

• 共享存储层：让 Synapse 和 Fabric 通过 OneLake 快捷方式对同一个 ADLS Gen2 存储进行读取和写入。 这样可以让两个平台使用相同的 Delta 文件，但必须通过确保在任意时间只有一个平台向指定表写入来防止写入冲突。
• 一次写入、两者读取：在转换过程中保留 Synapse 作为主要编写器，并允许 Fabric 通过快捷方式读取相同的数据。 在验证并迁移笔记本至Fabric后，将写入路径切换至Fabric，并将Synapse设为只读模式，直至停用。 这是大多数迁移的最安全选项。
• 双写： 避免同时在两个环境中运行相同的 ETL，除非你已有自动化的比较和对帐工具。 双重写入往往会导致偏差、重复和操作负担。

并行运行还会影响更改管理。 虽然 Synapse 仍然是活动开发环境，但 Synapse 中所做的任何笔记本、Spark 作业定义、Spark 池配置或湖数据库架构更改不会自动在 Fabric 中体现。 必须重新迁移受影响的资产，以使这两个环境保持一致。

• Notebook 代码更改：重新运行 Spark 迁移助手或手动重新导出和重新导入更新的笔记本。 重新应用任何 Fabric 特定的代码重构，包括 notebookutils、文件路径更新以及 密钥保管库 机密。
• Spark 作业定义更改：重新通过 迁移助手 迁移或在 Fabric 中手动重新创建更新的 Spark 作业定义。
• Spark 池配置更改：更新相应的Fabric环境，以匹配修改后的节点大小、自动缩放设置和库。
• Lake 数据库架构更改：重新运行 HMS 导出/导入笔记本，或者在 Fabric lakehouse 中手动创建或更改受影响的表。

若要减少重新迁移开销，在开始迁移后，在 Synapse 端建立更改冻结。 如果更改不可避免，请保留更改日志，以便在切换之前在Fabric中重播这些更改。

回滚注意事项

Synapse-to-Fabric 迁移是复制操作 ， 它不会修改或删除源 Synapse 工作区。 在整个过程中，原始 Spark 池、笔记本和数据保持不变。 这使得回滚变得简单：

• 如果迁移结果不尽如人意，请继续使用现有的 Synapse 工作区。 无需还原任何更改。
• 删除迁移Fabric项目（笔记本、环境、Spark 作业定义）并在解决问题后重试。
• OneLake 快捷方式指向现有的 ADLS Gen2 存储 ， 删除快捷方式不会影响基础数据。
• 在Fabric中验证所有迁移的工作负载并重新路由下游使用者之前，请不要关闭Synapse工作区。

功能对等性与主要差异

了解 Synapse 和 Fabric 之间的体系结构差异对于规划至关重要。 下表突出了计算体系结构和 Spark 功能的主要差异。

有关完整比较，请参阅 Compare Fabric 和 Azure Synapse Spark：关键差异。

计算和体系结构

Spark：Synapse Spark 与 Fabric Spark

相关内容

• 阶段 1：迁移策略和规划
• 阶段 2：Spark 工作负荷迁移
• 阶段 3：Hive 元存储和数据迁移
• 阶段 4：安全性和治理迁移