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

适用于：Microsoft Fabric 中的✅ 仓库

本文介绍了从 Azure Synapse Analytics 专用 SQL 池迁移到 Microsoft Fabric Data Warehouse 的策略、注意事项和方法。

小窍门

使用Fabric 迁移助手 for Data Warehouse实现从Azure Synapse Analytics专用 SQL 池自动迁移的体验。 本文包含重要的策略和规划信息。

迁移简介

Microsoft Fabric 是一款面向企业的一体化 SaaS 分析解决方案。 它提供全面的服务套件，包括数据工厂、数据工程、数据仓储、数据科学、 Real-Time 智能和Power BI。

本文介绍了模式（DDL）、数据库代码（DML）和数据迁移的选项，并帮助你为你的场景选择合适的选项。 它采用 TPC-DS 行业基准进行示例和性能测试。 结果可能会因数据类型、表宽度和源延迟等因素而有所不同。

准备迁移

在开始迁移项目前，请仔细规划，确保你的模式、代码和数据与Fabric Data Warehouse兼容。 考虑其 局限性。 量化重构不兼容项所需的工作量及实现迁移所需的其他资源。

规划的另一个关键目标是调整设计，使解决方案充分利用Fabric Data Warehouse查询性能。 由于为了实现缩放性而设计数据仓库时会引入独特的设计模式，因此传统的方法不一定最合适。 请查看 绩效指南。 虽然迁移后可以做一些设计调整，但提前修改能节省时间和精力。 从一种技术或环境迁移到另一种技术总是一项重大工程。

下图展示了迁移生命周期及其五大支柱相关的任务： 评估与评估、 规划与设计、 迁移、 监控与治理，以及 优化与现代化。

迁移生命周期示意图，包括评估与评估、规划与设计、迁移、监控与治理，以及优化与现代化。

用于迁移的 Runbook

请将以下活动视为从 Synapse 专用 SQL 池迁移到 Fabric 数据仓库的规划手册。

  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 数据仓库的时间和成本压力。

总之，这种方法适用于针对当前 Azure Synapse 专用 SQL 池环境优化且不需要对 Fabric 进行重大改动的工作负载。

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

如果遗留数据仓库经过长时间演进，可能需要重新设计以维持所需的性能水平。

你也可以重新设计架构，利用 Fabric 工作区中可用的新引擎和功能。

设计差异：Synapse 专用 SQL 池和 Fabric 数据仓库

请考虑以下 Azure Synapse 和 Microsoft Fabric 数据仓库差异，将专用 SQL 池与 Fabric 数据仓库进行比较。

表注意事项

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

源环境中的性能优化，如索引，指示你在新环境中可能需要优化的地方。 Fabric 会自动管理这些优化。

T-SQL 注意事项

数据操作语言（DML）在语法上有若干差异需要考虑。 查看Fabric Data Warehouse 中的 T-SQL 支持范围，并在选择数据库代码迁移方法时进行代码评估。

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

数据类型映射差异

Fabric Data Warehouse与Azure Synapse Analytics专用的SQL池有若干数据类型差异。 有关详细信息，请参阅 Microsoft Fabric 中的数据类型。

下表显示了从 Azure Synapse 专用 SQL 池到 Fabric Data Warehouse 的受支持数据类型映射。

Synapse 专用 SQL 池 Fabric Data Warehouse
money 十进制（19,4）
smallmoney 十进制（10,4）
smalldatetime datetime2
datetime datetime2
nchar char
nvarchar varchar
tinyint smallint
binary varbinary
datetimeoffset* datetime2

* Datetime2 不存储 datetimeoffset 存储的额外时区偏移信息。 由于Fabric Data Warehouse目前不支持datetimeoffset数据类型，你需要将时区偏移数据提取到单独的列中。

小窍门

已准备好迁移？

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

有关更多手动迁移步骤和细节，请参见“Azure Synapse Analytics专用SQL池迁移方法到Fabric Data Warehouse。

相关内容

  • Last updated on