通过

迁移规划：从 Azure Synapse Analytics 专用 SQL 池迁移到 Fabric 数据仓库

适用于：✅ Microsoft Fabric 中的仓库

本文详细介绍了将 Azure Synapse Analytics 专用 SQL 池中的数据仓库迁移到 Microsoft Fabric Warehouse 的策略、注意事项和方法。

提示

使用适用于数据仓库的 Fabric 迁移助手可实现从 Azure Synapse Analytics 专用 SQL 池迁移的自动化体验。 本文包含重要的策略和规划信息。

迁移简介

微软推出了 Microsoft Fabric，这是一款面向企业的一体化 SAAS 分析解决方案，可提供一套全面的服务，包括数据工厂、数据工程、数据仓库、数据科学、实时智能和 Power BI。

本文重点介绍架构 (DDL) 迁移、数据库代码 (DML) 迁移和数据迁移的选项。 Microsoft 提供了多个选项，在此我们将详细讨论每个选项，并就你的方案应考虑哪些选项提供指导。 本文使用 TPC-DS 行业基准进行说明和性能测试。 实际结果可能会因多种因素而异，包括数据类型、数据类型、表宽度、数据源延迟等。

准备迁移

在开始之前，请仔细规划迁移项目，并确保架构、代码和数据与 Fabric Warehouse 兼容。 有一些限制需要考虑。 量化不兼容项目的重构工作，以及迁移交付之前所需的任何其他资源。

规划的另一个重要目的是调整设计，以确保解决方案充分利用 Fabric Warehouse 可提供的高查询性能。 由于为了实现缩放性而设计数据仓库时会引入独特的设计模式，因此传统的方法不一定最合适。 请查看 Fabric Warehouse 性能指南，尽管可以在迁移后进行一些设计调整，但在迁移过程中尽早进行更改将节省你的时间和精力。 不管怎么说，从一种技术/环境迁移到另一种技术/环境都是一项大工程。

下图描述了迁移生命周期，其中列出了包括评估和评估、计划和设计、迁移、监视和管理、优化和现代化支柱在内的主要支柱，以及每个支柱中关联的任务，以规划和准备顺利迁移。

迁移生命周期关系图。

用于迁移的 Runbook

考虑以下活动作为您从 Synapse 专用 SQL 池迁移到 Fabric Warehouse 的计划指南。

  1. 评估和评价
    1. 确定目标和动机。 建立明确的期望结果。
    2. 发现、评估现有体系结构并设定其基线。
    3. 确定关键利益干系人和发起人。
    4. 定义要迁移的内容的范围。
      1. 从小而简单的地方开始，准备好进行多次小型迁移。
      2. 监视和记录进程的所有阶段。
      3. 生成用于迁移的数据和进程的清单。
      4. 定义数据模型更改（如果有）。
      5. 设置 Fabric 工作区。
    5. 你的技能或偏好是什么？
      1. 尽可能自动化。
      2. 使用 Azure 内置工具和功能来减少迁移工作量。
    6. 尽早在新平台上培训员工。
      1. 确定技能需求和培训资产，包括 Microsoft Learn。
  2. 规划和设计
    1. 定义所需的体系结构。
    2. 选择迁移的方法/工具以完成以下任务：
      1. 从源提取数据。
      2. 架构 (DDL) 转换，包括表和视图的元数据
      3. 数据引入，包括历史数据。
        1. 根据需要，重新设计数据模型（使用新的平台性能和可伸缩性）。
      4. 数据库代码 (DML) 迁移。
        1. 迁移或重构存储过程和业务流程。
    3. 从源中清点和提取安全功能和对象权限。
    4. 设计和规划替换或修改现有的 ETL/ELT 流程，以实现增量加载。
      1. 在新环境中创建并行的 ETL/ELT 过程。
    5. 准备详细的迁移计划。
      1. 将当前状态映射到新的所需状态。
  3. 迁移
    1. 执行架构、数据、代码迁移。
      1. 从源提取数据。
      2. 架构 (DDL) 转换
      3. 数据引入
      4. 数据库代码 (DML) 迁移。
    2. 如有必要，请暂时扩展专用 SQL 池资源，以帮助加快迁移速度。
    3. 应用安全性和权限。
    4. 迁移用于增量加载的现有 ETL/ELT 进程。
      1. 迁移或重构 ETL/ELT 增量加载流程。
      2. 测试和比较并行递增负载进程。
    5. 根据需要调整详细迁移计划。
  4. 监视和监管
    1. 并行运行，与源环境进行比较。
      1. 测试应用程序、商业智能平台和查询工具。
      2. 评估和优化查询性能。
      3. 监视和管理成本、安全性和性能。
    2. 治理基准和评估。
  5. 优化和现代化
    1. 当业务状况稳定时，将应用程序和主要报告平台迁移到 Fabric。
      1. 随着工作负荷从 Azure Synapse Analytics 转移到 Microsoft Fabric，向上/向下扩展资源。
      2. 根据获得的经验构建一个可重复的模板，用于将来的迁移。 循环访问。
      3. 确定成本优化、安全性、可伸缩性和卓越运营的机会
      4. 发现利用最新 Fabric 功能实现数据资产现代化的机会。

“直接转移”还是现代化？

通常，无论计划迁移的目的和范围如何，都有两种类型的迁移：直接原样迁移，或是包含架构和代码更改的分阶段方法。

直接迁移

在直接迁移中，现有数据模型将迁移到新的 Fabric 仓库，但会有一些细微更改。 这种方法可减少实现迁移优势所需的新工作，从而将风险和迁移时间降至最低。

直接迁移非常适合以下情况：

  • 你的现有环境中包含少量要迁移的数据市场。
  • 具有现成的环境，其中的数据已具备精心设计的星型或雪花型架构。
  • 你在迁移到 Fabric Warehouse 时面临时间和成本双重压力。

总之，这种方法非常适合那些使用你当前的 Synapse 专用 SQL 池环境进行优化的工作负载，因此不需要对结构进行重大更改。

通过更改体系结构，分阶段实现现代化

如果旧的数据仓库已经发展了很长时间，可能需要对其进行重新设计，从而维持所需的性能级别。

你可能还希望重新设计体系结构，以利用 Fabric 工作区中提供的新引擎和新功能。

设计差异：Synapse 专用 SQL 池和 Fabric Warehouse

请考虑 Azure Synapse 与 Microsoft Fabric 数据仓库之间的下列差异，将专用 SQL 池与 Fabric Warehouse 进行比较。

表注意事项

在不同环境之间迁移表时，通常只有原始数据和元数据会进行物理迁移。 源系统中的其他数据库元素（例如索引）通常不会迁移，因为在新环境中它们可能是不必要的，或者实现方式不同。

源环境中的性能优化（如索引等）可以指示出在哪些位置可以在新环境中添加性能优化，而现在 Fabric 会为你自动处理这些优化。

T-SQL 注意事项

有若干个数据操作语言 (DML) 语法差异需要注意。 请参阅 Microsoft Fabric 中的 T-SQL 表面区域。 在选择数据库代码（数据操作语言）迁移方法时，还要考虑进行代码评估。

根据迁移时的差异性，您可能需要重写部分 T-SQL DML 代码。

数据类型映射差异

Fabric Warehouse 中有几种数据类型差异。 有关详细信息，请参阅 Microsoft Fabric 中的数据类型。

下表提供了支持的数据类型从 Synapse 专用 SQL 池到 Fabric Warehouse 的映射。

Synapse 专用 SQL 池 Fabric Warehouse
money decimal(19,4)
smallmoney decimal(10,4)
smalldatetime datetime2
datetime datetime2
nchar char
nvarchar varchar
tinyint smallint
binary varbinary
datetimeoffset* datetime2

* Datetime2 不会存储额外时区偏移信息（原本是存储的）。 由于 Fabric Warehouse 目前不支持 datetimeoffset 数据类型，因此需要将时区偏移量数据提取到单独的列中。

提示

已准备好迁移？

若要开始使用自动化迁移体验，请参阅适用于数据仓库的 Fabric 迁移助手。

有关手动迁移步骤的更多内容和详细信息，请参阅迁移方法：从 Azure Synapse Analytics 专用 SQL 池迁移到 Fabric 数据仓库。

相关内容