将 Azure Synapse Analytics 专用 SQL 池迁移到 Fabric 数据仓库的方法

适用于：Microsoft Fabric 中的✅ 仓库

本文详细介绍了将 Azure Synapse Analytics 专用 SQL 池中的数据仓库迁移到 Microsoft Fabric Warehouse 的方法。

此表总结了有关数据架构 (DDL)、数据库代码 (DML) 和数据迁移方法的信息。 我们将在本文后面进一步深入介绍每个场景，并在“选项”列中链接。

选择初始迁移的工作负载

决定从哪里开始 Synapse 专用 SQL 池到 Fabric Warehouse 迁移项目时，请选择一个工作负荷区域，以便你能够：

• 通过快速提供新环境的优势，证明迁移到 Fabric Warehouse 的可行性。 从小型和简单的迁移开始，准备多个小型迁移。
• 给予内部技术人员时间，以便他们在迁移到其他领域时能够积累使用相关流程和工具的经验。
• 为进一步的迁移创建模板，该模板需特定于源 Synapse 环境以及当前已有的有用工具和流程。

初始迁移中迁移的数据量应足够大，能够体现出 Fabric Warehouse 环境的功能和优势，但不应过大以至无法快速体现出价值。 典型的大小为 1-10 TB。

使用 Fabric 数据工厂进行迁移

在本部分中，我们将讨论对熟悉 Azure 数据工厂和 Synapse Pipeline 的低代码/无代码角色使用数据工厂的选项。 这种拖放式 UI 选项提供了一个简单的步骤来转换 DDL 并迁移数据。

Fabric 数据工厂可以执行以下任务：

• 将架构 (DDL) 转换为 Fabric Warehouse 语法。
• 在 Fabric Warehouse 上创建架构 (DDL)。
• 将数据迁移到 Fabric Warehouse。

选项 1. 架构/数据迁移 - 复制向导和 ForEach 复制活动

此方法使用数据工厂复制助手连接到源专用 SQL 池，将专用 SQL 池 DDL 语法转换为 Fabric，并将数据复制到 Fabric Warehouse。 可以选择一个或多个目标表（对于 TPC-DS 数据集，有 22 个表）。 这会生成 ForEach 以循环访问 UI 中选择的表清单，并生成 22 个并行的“复制活动”线程。

• 在专用 SQL 池中生成和执行 22 个 SELECT 查询（每个选中的表各有一个）。
• 请确保具有适当的 DWU 和资源类，以允许执行生成的查询。 在这种情况下，你至少需要 DWU1000 和 staticrc10，以允许最多 32 个查询来处理提交的 22 个查询。
• 数据工厂可直接将数据从专用 SQL 池复制到 Fabric Warehouse，但需要暂存。 引入过程由两个阶段组成。
  • 第一个阶段包括将数据从专用 SQL 池提取到 ADLS 中，称为暂存。
  • 第二个阶段包括将数据从暂存位置引入到 Fabric 仓库中。 大多数数据引入计时处于暂存阶段。 总之，暂存对引入性能有巨大影响。

建议用途

使用复制向导生成 ForEach 提供了一个简便的用户界面，用于转换 DDL 并在一个步骤中将所选表从专用 SQL 池引入到 Fabric Warehouse。

然而，从总体吞吐量来看，它并不是最佳的选择。 造成性能延迟的主要因素是需要使用暂存，并且在“源到阶段”步骤中需要进行读写并行化。 建议仅对维度表使用此选项。

选项 2. DDL/数据迁移 - 使用分区选项的管道

为了提高传输率以使用 Fabric 管道加载更大的事实数据表，建议对每个具有分区选项的事实数据表使用复制活动 (Copy Activity)。 这为复制活动提供了最佳性能。

你可以选择使用源表物理分区（如果可用）。 如果表没有物理分区，则必须指定分区列并提供最小/最大值才能使用动态分区。 在以下屏幕截图中，管道 源 选项根据 ws_sold_date_sk 列指定动态分区范围。

虽然使用分区可以增加暂存阶段的吞吐量，但需要考虑进行适当的调整：

• 根据你的分区范围，它可能会使用所有的并发槽，因为它可能会在专用 SQL 池上生成超过 128 个查询。
• 你必须将规模提升至至少 DWU6000 才能执行所有查询。
• 例如，对于 TPC-DS web_sales 表，163 个查询已提交到专用 SQL 池。 在 DWU6000 中，执行了 128 个查询，同时有 35 个查询在排队。
• 动态分区会自动选择范围分区。 在这种情况下，每个提交到专用 SQL 池的 SELECT 查询的范围为 11 天。 例如：

  WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
  ...
  WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
  

建议用途

对于事实数据表，建议使用数据工厂和分区选项来提高吞吐量。

但是，增加的并行读取需要专用 SQL 池扩展到更高的 DWU，以允许执行提取查询。 利用分区后，速度比不采用分区选项提高了十倍。 可以通过计算资源增加 DWU 以获取额外的吞吐量，但专用 SQL 池最多允许 128 个活动查询。

有关 Synapse DWU 到 Fabric 映射的详细信息，请参阅博客：将 Azure Synapse 专用 SQL 池映射到 Fabric 数据仓库计算。

选项 3. DDL 迁移 - 复制向导 ForEach 复制活动

对于较小的数据库，前面的两个选项是很不错的数据迁移选项。 但是，如果需要更高的吞吐量，建议使用替代选项：

1. 将数据从专用 SQL 池提取到 ADLS，从而缓解暂存性能开销。
2. 使用数据工厂或 COPY 命令将数据引入 Fabric Warehouse。

建议用途

您可以继续使用数据工厂来转换您的模式 (DDL)。 使用复制向导，可以选择特定的表或“所有”表。 根据设计，这会通过一个步骤迁移架构和数据，使用查询语句中的 false 条件 TOP 0 提取不包含任何行的架构。

以下代码示例介涵盖了使用数据工厂进行架构 (DDL) 迁移。

代码示例：使用数据工厂进行架构 (DDL) 迁移

可以使用 Fabric 管道轻松地从任何源 Azure SQL 数据库或专用 SQL 池中迁移表对象的 DDL （架构）。 此管道通过源专用 SQL 池表的架构（DDL）迁移到 Fabric Warehouse。

管道设计：参数

此管道接受参数，该参数 SchemaName允许指定要迁移的架构。 默认为 dbo 架构。

在“默认值”字段中，输入逗号分隔的表架构列表，以指示要迁移的模式： 提供两个模式，分别为 'dbo','tpch' 和 dbo。tpch

管道设计：查找活动

创建“查找活动”并将连接设置为指向源数据库。

在“设置”选项卡中：

• 将“数据存储类型”设置为“外部”。

• 连接是你的 Azure Synapse 专用 SQL 池。 “连接类型”为“Azure Synapse Analytics”。

• “使用查询”设置为“查询”。

• 需要使用动态表达式构建“查询”字段，从而允许在返回目标源表列表的查询中使用 SchemaName 参数。 选择“查询”，然后选择“添加动态内容”。

  查找活动中的此表达式将生成一个 SQL 语句来查询系统视图，以检索架构和表的列表。 引用 SchemaName 参数以允许对 SQL 架构进行筛选。 输出将是一个包含 SQL 架构和表的数组，这将作为 ForEach 活动的输入。

  使用以下代码返回所有用户表及其架构名称的列表。

  @concat('
  SELECT s.name AS SchemaName,
  t.name  AS TableName
  FROM sys.tables AS t
  INNER JOIN sys.schemas AS s
  ON t.type = ''U''
  AND s.schema_id = t.schema_id
  AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
  ')
  

管道设计：ForEach 循环

对于 ForEach 循环，请在“设置”选项卡中配置以下选项：

• 禁用顺序选项以允许多个迭代并发运行。
• 将“批次数量”设置为 ，从而限制并发迭代的最大次数。50
• “项”字段需要使用动态内容来引用查找活动的输出。 添加以下代码片段：@activity('Get List of Source Objects').output.value

管道设计：ForEach 循环中的复制活动

在 ForEach 活动内，添加一个复制活动。 此方法使用管道中的动态表达式语言生成一个 SELECT TOP 0 * FROM <TABLE> ，以仅迁移架构而不将数据迁移到 Fabric Warehouse。

在“源”选项卡中：

• 将“数据存储类型”设置为“外部”。
• 连接是你的 Azure Synapse 专用 SQL 池。 “连接类型”为“Azure Synapse Analytics”。
• 将“使用查询”设置为“查询”。
• 在“查询”字段中，粘贴动态内容查询并使用以下表达式，该表达式将返回零行，仅返回表架构：@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

在“目标”选项卡中：

• 将“数据存储类型”设置为“工作区”。
• “工作区数据存储类型”为“数据仓库”，“数据仓库”设置为 Fabric Warehouse。
• 目标表的架构和表名称是使用动态内容定义的。
  • 架构是指当前迭代的字段，包含代码片段的 SchemaName：@item().SchemaName
  • 表通过代码片段引用 TableName：@item().TableName

管道设计：接收器

对于接收器，请指向仓库并引用源架构和表名称。

运行此管道后，你将看到数据仓库中填充了源中的每个表，并使用适当的架构。

在 Synapse 专用 SQL 池中使用存储过程进行迁移

此选项使用存储过程来执行 Fabric 迁移。

你可以在 github.com 上的 microsoft/fabric-migration 获取代码示例。 此代码作为开放源代码共享，因此尽情贡献内容并帮助社区。

迁移存储过程能做些什么：

• 将架构 (DDL) 转换为 Fabric Warehouse 语法。
• 在 Fabric Warehouse 上创建架构 (DDL)。
• 将数据从 Synapse 专用 SQL 池提取到 ADLS。
• 标记 T-SQL 代码（存储过程、函数、视图）不支持的 Fabric 语法。

建议用途

此选项非常适合于以下人员：

• 熟悉 T-SQL。
• 希望使用集成开发环境，如 SQL Server Management Studio (SSMS)。
• 希望更精细地控制要处理的任务。

可以执行架构 (DDL) 转换、数据提取或 T-SQL 代码评估的特定存储过程。

对于数据迁移，需要使用 COPY INTO 或数据工厂将数据引入 Fabric Warehouse。

使用 SQL 数据库项目进行迁移

SQL 数据库项目扩展 支持 Microsoft Fabric Data Warehouse，可在 Azure Data Studio 和 Visual Studio Code 中获得。

此扩展在 Azure Data Studio 和 Visual Studio Code 中提供。 此功能支持源代码管理、数据库测试和架构验证的功能。

有关 Microsoft Fabric 中仓库的源代码管理的详细信息，包括 Git 集成和部署管道，请参阅仓库源代码管理。

建议用途

对于喜欢使用 SQL 数据库项目进行部署的人来说，这是个绝佳选择。 此选项本质上是将 Fabric 迁移存储过程集成到 SQL 数据库项目中，以提供无缝迁移体验。

SQL 数据库项目可以：

• 将架构 (DDL) 转换为 Fabric Warehouse 语法。
• 在 Fabric Warehouse 上创建架构 (DDL)。
• 将数据从 Synapse 专用 SQL 池提取到 ADLS。
• 标记 T-SQL 代码（存储过程、函数、视图）不支持的语法。

对于数据迁移，你随后需要使用 COPY INTO 或数据工厂将数据引入 Fabric Warehouse。

Microsoft Fabric CAT 团队提供了一组 PowerShell 脚本，用于通过 SQL 数据库项目处理架构（DDL）和数据库代码（DML）的提取、创建和部署。 有关将 SQL 数据库项目与有用的 PowerShell 脚本配合使用的演练，请参阅 GitHub.com 上的 microsoft/fabric-migration。

有关 SQL 数据库项目的详细信息，请参阅 SQL 数据库项目扩展入门和生成和发布项目。

使用 CETAS 迁移数据

T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) 命令提供经济高效的最佳方法，用于将数据从 Synapse 专用 SQL 池提取到 Azure Data Lake Storage (ADLS) Gen2。

CETAS 的功能：

• 将数据提取到 ADLS 中。
  • 此选项要求用户在引入数据之前在 Fabric Warehouse 上创建架构 (DDL)。 迁移架构 (DDL) 时，请考虑本文中的选项。

此选项的优点包括：

• 仅针对源 Synapse 专用 SQL 池提交每个表的单个查询。 这不会用尽所有并发槽位，因此也不会妨碍客户生产过程中的ETL处理或查询。
• 无需缩放到 DWU6000，因为每个表仅使用单个并发槽位，因此客户可以使用较低的 DWU。
• 提取在所有计算节点之间并行运行，这是提高性能的关键。

建议用途

使用 CETAS 将数据作为 Parquet 提取到 ADLS 中。 Parquet 文件通过列式压缩提供了高效数据存储的优势，这种文件格式在网络上移动时占用的带宽更少。 此外，由于 Fabric 将数据存储为 Delta Parquet 格式，因此与文本文件格式相比，数据引入速度是文本文件格式的 2.5 倍，因为在引入期间无须转换为 Delta 格式，从而减少了开销。

增加 CETAS 吞吐量：

• 添加并行 CETAS 操作，增加并发槽的使用，但可以提高吞吐量。
• 在 Synapse 专用 SQL 池上缩放 DWU。

通过 dbt 进行迁移

在本部分中，我们将讨论 dbt 选项，此选项适用于已在其当前 Synapse 专用 SQL 池环境中使用 dbt 的客户。

dbt 的功能：

• 将架构 (DDL) 转换为 Fabric Warehouse 语法。
• 在 Fabric Warehouse 上创建架构 (DDL)。
• 将数据库代码 (DML) 转换为 Fabric 语法。

dbt 框架在每次执行时都会动态生成 DDL 和 DML （SQL 脚本）。 使用 SELECT 语句表示的模型文件，通过更改配置文件（连接字符串）和适配器类型，可以将 DDL/DML 立即转换为任何目标平台。

建议用途

dbt 框架是代码优先方法。 必须使用本文档中列出的选项（如 CETAS 或 COPY/数据工厂）迁移数据。

利用适用于 Microsoft Fabric 数据仓库的 dbt 适配器，只需进行简单的配置更改即可将针对不同平台（如 Synapse 专用 SQL 池、Snowflake、Databricks、Google Big Query 或 Amazon Redshift）的现有 DBT 项目迁移到 Fabric 仓库。

若要开始使用面向 Fabric Warehouse 的 dbt 项目，请参阅教程：为 Fabric 数据仓库设置 dbt。 本文档还列出了在不同仓库/平台之间移动的选项。

将数据引入 Fabric 仓库

若要引入 Fabric Warehouse，请使用 COPY INTO 或 Fabric Data Factory，具体取决于自己的偏好。 鉴于先决条件是文件已提取到 Azure Data Lake Storage (ADLS) Gen2，这两种方法都是推荐且性能最佳的选项，因为它们具有等效的性能吞吐量。

需要注意的几个因素，以便设计过程以获得最佳性能：

• 使用 Fabric，将多个表从 ADLS 同时加载到 Fabric 仓库时不会发生任何资源争用。 因此，在加载并行线程时不会出现性能下降。 最大引入吞吐量完全取决于 Fabric 容量的计算能力。
• Fabric 工作负荷管理可分离为加载和查询分配的资源。 当查询和数据加载同时执行时，不存在资源争用的情况。

相关内容

• Fabric 数据仓库迁移助手
• 在 Microsoft Fabric 中创建仓库
• Fabric 数据仓库性能指南
• Microsoft Fabric 中数据仓库的安全性
• 博客：将 Azure Synapse 专用 SQL 池映射到 Fabric 数据仓库计算
• Microsoft Fabric 迁移概述