迁移: Azure Synapse Analytics 专用 SQL 池到 Fabric

项目
07/17/2024

适用于：✅Microsoft Fabric 中的仓库

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

迁移简介

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

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

准备迁移

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

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

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

用于迁移的 Runbook

请考虑以下活动作为计划 Runbook，以便从 Synapse 专用 SQL 池迁移到 Fabric Warehouse。

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

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

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

直接迁移

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

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

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

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

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

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

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

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

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

表注意事项

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

源环境中的性能优化（例如索引）体现了可以在新环境中添加性能优化的位置，但 Fabric 现在可以为你自动处理。

T-SQL 注意事项

有若干个数据操作语言 (DML) 语法差异需要注意。请参阅 Microsoft Fabric 中的 T-SQL 外围应用。还要考虑为数据库代码 (DML) 选择迁移方法时的代码评估事宜。

根据迁移时的奇偶校验差异，可能需要重写 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 数据类型，因此需要将时区偏移量数据提取到单独的列中。

架构、代码和数据迁移方法

查看和确定这些选项中哪些选项适合你的方案、员工技能集以及数据的特征。选择的选项取决于你的体验、首选项以及每个工具的优点。我们的目标是继续开发迁移工具，以减少阻力和手动干预，从而实现无缝迁移体验。

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

选项编号	选项	作用	技能/首选项	方案
1	数据工厂	架构 (DDL) 转换数据提取数据引入	ADF/管道	简化的一体式架构 (DDL) 和数据迁移。建议用于维度表。
2	具有分区的数据工厂	架构 (DDL) 转换数据提取数据引入	ADF/管道	使用分区选项增加读/写并行度，与选项 1（事实数据表的建议选项）相比，吞吐量是其 10 倍。
3	具有加速代码的数据工厂	架构 (DDL) 转换	ADF/管道	首先转换和迁移架构 (DDL)，然后使用 CETAS 提取，使用 COPY/数据工厂来引入数据，以获得最佳的整体接收性能。
4	存储过程加速代码	架构 (DDL) 转换数据提取代码评估	T-SQL	使用 IDE 的 SQL 用户可以更精细地控制要处理的任务。使用 COPY/数据工厂引入数据。
5	Azure Data Studio 的 SQL 数据库项目扩展	架构 (DDL) 转换数据提取代码评估	SQL 项目	用于部署的 SQL 数据库项目与选项 4 的集成。使用 COPY 或数据工厂引入数据。
6	CREATE EXTERNAL TABLE AS SELECT (CETAS)	数据提取	T-SQL	将高性能数据提取到 Azure 数据湖存储 (ADLS) Gen2 中，经济高效。使用 COPY/数据工厂引入数据。
7	使用 dbt 进行迁移	架构 (DDL) 转换数据库代码 (DML) 转换	dbt	现有 dbt 用户可以使用 dbt Fabric 适配器转换其 DDL 和 DML。然后，必须使用此表中的其他选项迁移数据。

选择初始迁移的工作负载

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

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

提示

创建需要迁移的对象的清单，并记录从开始到结束的迁移过程，以便可以对其他专用 SQL 池或工作负荷重复此过程。

初始迁移中迁移的数据量应足够大，能够体现出 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。可以选择 1 个或多个目标表（对于 TPC-DS 数据集，有 22 个表）。这会生成 ForEach 以循环访问 UI 中选择的表清单，并生成 22 个并行的“复制活动”线程。

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

建议用途

使用复制向导生成 ForEach，这将提供一个简单 UI，用于在一个步骤中将所选表从专用 SQL 池引入到 Fabric Warehouse 中。

但是，对于总体吞吐量并不是最佳的。造成读取和写入出现性能延迟的主要因素是要求使用暂存求，并且“源到阶段”步骤需要将并行读写。建议仅对维度表使用此选项。

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

为了提高吞吐量以使用 Fabric 数据管道加载较大事实数据表，建议对每个事实数据表使用带分区选项的复制活动。这为复制活动提供了最佳性能。

你可以选择使用源表物理分区（如果可用）。如果表没有物理分区，则必须指定分区列并提供最小/最大值才能使用动态分区。在下面的屏幕截图中，数据管道的“源”选项根据 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，以允许执行提取查询。利用分区后，速度是不采用分区选项的 10 倍。可以通过计算资源增加 DWU 以获取额外的吞吐量，但专用 SQL 池最多允许 128 个活动查询。

注意

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

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

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

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

建议用途

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

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

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

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

Fabric 数据工厂的屏幕截图，其中显示了一个引致 For Each 对象的 Lookup 对象。在 For Each 对象中，有用于迁移 DDL 的活动。

管道设计：参数

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

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

数据工厂的屏幕截图，其中显示了数据管道的“参数”选项卡。在“名称”字段中输入了“SchemaName”。在“默认值”字段中输入了“'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 Loop 活动“设置”选项卡的屏幕截图。

管道设计：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 数据库项目进行迁移

Azure Data Studio 和 Visual Studio Code 中提供的 SQL 数据库项目扩展支持 Microsoft Fabric Data Warehouse。

此扩展在 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。

除了 Azure Data Studio 对 Fabric 的支持之外，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 Synapse 数据仓库的 dbt 适配器，只需进行简单的配置更改即可将针对不同平台（如 Synapse 专用 SQL 池、Snowflake、Databricks、Google Big Query 或 Amazon Redshift）的现有 DBT 项目迁移到 Fabric Warehouse。

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

将数据引入 Fabric Warehouse

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

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

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

通过

迁移: ​Azure Synapse Analytics 专用 SQL 池到 Fabric

迁移简介

准备迁移

用于迁移的 Runbook

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

直接迁移

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

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

表注意事项

T-SQL 注意事项

数据类型映射差异

架构、代码和数据迁移方法

选择初始迁移的工作负载

使用 Fabric 数据工厂进行迁移

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

建议用途

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

建议用途

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

建议用途

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

管道设计：参数

管道设计：查找活动

管道设计：ForEach 循环

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

管道设计：接收器

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

建议用途

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

建议用途

使用 CETAS 迁移数据

建议用途

通过 dbt 进行迁移

建议用途

将数据引入 Fabric Warehouse

相关内容

反馈

其他资源

迁移: Azure Synapse Analytics 专用 SQL 池到 Fabric