在本文中，我们将以 Azure SQL 数据库为参考，讨论能帮助你使用 SQL 数据库源来优化复制活动的技术。 我们讨论了优化的不同方面，包括数据传输速度、成本、监视、开发便利性以及平衡这些不同的注意事项以获得最佳结果。
复制活动选项
注意
本文中包含的指标是测试用例在各种功能之间比较和对比行为的结果，并非正式的工程基准。 所有测试用例都将数据从美国东部 2 区域移动到美国西部 2 区域。
从管道复制活动开始时，在开始开发之前，请务必了解源系统和目标系统。 应说明要优化的内容，并了解如何监视源、目标和管道，以实现最佳资源利用率、性能和消耗。
从 Azure SQL 数据库进行溯源时，请务必了解：
- 每秒输入/输出操作数 (IOPS)
- 数据量
- 一个或多个表的 DDL
- 分区架构
- 主键或其他具有良好数据分布（倾斜）的列
- 计算分配的和关联的限制，例如并发连接数
这同样适用于你的目标。 了解这两者后，可以设计管道，以便在源和目标的边界和限制内运行，同时针对优先级进行优化。
注意
源和目标之间的网络带宽以及每个源和目标的每秒输入/输出 (IOP) 都可能成为吞吐量的瓶颈，因此建议了解这些边界。 但是，网络不在本文的讨论范围内。
了解您的源和目标后，您可以使用复制活动中的各种选项来根据您的优先事项提高其性能。 这些选项可能包括：
- 源分区选项 – 无、物理分区、动态范围
- 源隔离级别 - 无、读取未提交、读取已提交、快照
- 智能吞吐量优化设置 – 自动、标准值、平衡值、最大值
- 复制并行度设置 – 自动、指定值
- 逻辑分区 - 管道设计用于生成多个并发复制活动
源详细信息：Azure SQL 数据库
为了提供具体示例，我们测试了多个应用场景，将数据从 Azure SQL 数据库移动到 Fabric Lakehouse（表）和 Fabric Warehouse 表。 在这些示例中，我们测试了四个源表。 全都有相同的架构和记录计数。 第一个使用堆，第二个使用聚集索引，而第三个和第四个分别使用 8 个和 85 个分区。 此示例使用了 Microsoft Fabric（美国西部 2）中的试用容量 (F64)。
- 服务层级：常规用途
- 计算层：无服务器
- 硬件配置：标准系列 (Gen5)
- 最大 vCore 数：80
- 最小 vCore 数：20
- 记录计数：1,500,000,000
- 地区：美国东部 2
默认评估
在设置源“分区选项”之前，请务必了解复制活动的默认行为。
默认设置为：
来源
- 分区选项 - 无
- 隔离级别 - 无
高级设置
- 智能吞吐量优化 - 自动
- 复制并行度 - 自动
为了给将来的比较设置初始基准，我们使用了复制活动运行的默认设置，将 15 亿条记录加载到每个目标，且每个复制活动花费 2 个多小时。
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Lakehouse | 无 | 自动 | 1 | 02:10:37 |
在本文中，我们重点关注总持续时间。 总持续时间包含其他阶段，例如队列、预复制脚本和传输持续时间等。 有关这些阶段的更多信息，请参阅复制活动执行详细信息。 有关将 Azure SQL 数据库作为源的复制活动属性的全面概述，请参阅复制活动的 Azure SQL 数据库源属性。
设置
智能吞吐量优化 (ITO)
ITO 可确定活动可以消耗的 CPU、内存和网络资源分配的最大量。 如果将 ITO 设置为“最大值”（或 256），服务将选择提供最优化吞吐量的最高值。 在本文中，所有测试用例均将 ITO 设置为“最大值”，但服务仅使用其所需的值，实际值低于 256。
要更深入地了解 ITO，请参阅智能吞吐量优化。
注意
当复制活动接收器是 Fabric 仓库时，需要进行暂存。 “复制并行度”和“智能吞吐量优化”等选项仅适用于从源到暂存的情况。 Lakehouse 的测试用例尚未启用暂存功能。
分区选项
当源是关系数据库（如 Azure SQL 数据库）时，可以在“高级”部分中指定“分区选项”。 默认情况下，此设置为“无”，另外两个选项是“表的物理分区”和“动态范围”。
动态范围
堆表
动态范围允许服务智能地生成对源的查询。 生成的查询数等于服务在运行时选择的“已用并行副本”的数量。 在优化使用动态范围分区选项时，需重点考虑复制并行度和使用的并行副本。
分区边界
分区上限和下限是可选字段，可用于指定分区步幅。 在这些测试用例中，我们对上限和下限进行了预定义。 如果未指定这些字段，系统在查询源时以确定范围时会产生额外开销。 为了优化性能，建议预先确定范围，特别是对于单次历史加载。
有关更多信息，请参考 Azure SQL 数据库连接器文章的从 SQL 数据库并行复制部分中的表。
以下 SQL 查询确定了范围的最小值和最大值：
然后，我们在“动态范围”配置中提供这些详细信息。
下面是“复制活动”使用动态范围生成的一个示例查询：
SELECT * FROM [dbo].[orders] WHERE [o_orderkey] > '4617187501' AND [o_orderkey] <= '4640625001'
复制并行度
默认情况下，“复制并行度”指定为“自动”。 但是，“自动”可能无法达到最佳的并行复制数量。 并行副本与在源数据库上建立的会话数相关联。 如果生成了过多的并行副本，则源数据库 CPU 将面临超负荷的风险，导致查询处于挂起状态。
在“动态范围”的原始测试用例中使用“自动”时，服务实际上在运行时生成了 251 个并行副本。 在“复制并行度”中指定一个值，就可以设置最大并行副本数。 通过此设置，可以限制对源进行的并发会话数量，从而更好地控制资源管理。 在这些测试用例中，将值指定为 50，总持续时间和源的资源利用率都得到了提高。
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Warehouse | 动态范围 | 50 | 50 | 00:13:05 |
具有“复制并行度”的“动态范围”可以显著提高性能。 但是，使用该设置需要预定义边界，或者允许服务在运行时确定值。 允许服务在运行时确定值可能会影响总持续时间，具体取决于源表的 DDL 和数据量。 此外，允许服务在运行时确定值的同时还应了解源可以处理的并行副本数。 如果值过高，源系统和复制活动性能可能会降低。
有关并行副本的更多信息，请参阅复制活动性能特点：并行复制。
具有动态范围的 Fabric 仓库
默认情况下，未指定“隔离级别”，并且“并行度”设置为“自动”。
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Warehouse | 动态范围 | 自动 | 251 | 00:39:03 |
具有动态范围的 Fabric Lakehouse（表）
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Lakehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Lakehouse | 动态范围 | 自动 | 251 | 00:36:40 |
| Fabric Lakehouse | 动态范围 | 50 | 50 | 00:12:01 |
聚集索引
与堆表相比，具有动态范围分区列所选列上的聚集键索引的表大大提高了性能和资源利用率。 即使将“复制并行度”设置为“自动”，情况也是如此。
具有聚集索引的 Fabric 仓库
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Warehouse | 动态范围 | 自动 | 251 | 00:09:02 |
| Fabric Warehouse | 动态范围 | 50 | 50 | 00:08:38 |
具有聚集索引的 Fabric Lakehouse（表）
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Lakehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Lakehouse | 动态范围 | 自动 | 251 | 00:06:44 |
| Fabric Lakehouse | 动态范围 | 50 | 50 | 00:06:34 |
逻辑分区设计
逻辑分区设计模式更为高级，需要开发人员付出更多努力。 但是，这种设计适用于对数据加载要求严格的应用场景。 这种设计最初是为了满足本地 Oracle 数据库在 1.5 小时内加载 180 GB 数据的需求而开发的。 最初的设计使用了复制活动的默认值，耗时超过 65 个小时。 使用逻辑分区设计后，我们看到相同的数据在 1.5 小时内传输完成。
此设计也在此博客系列中使用： 管道性能改进第 1 部分：如何将时间间隔转换为秒）。 当加载大型源表并需要使用设置数据范围等技术对源数据读取进行分区来优化加载性能时，这种设计非常适合在环境中进行模拟。 这种设计生成了许多子日期范围。 接着使用 For-Each 操作遍历这些范围，执行多个复制操作以在指定范围之间传输数据。 在 For-Each 活动中，所有复制活动都并行运行（批计数最多为 50），并且复制并行度设置为“自动”。
对于以下示例，分区日期值设置为以下值：
- 起始值：1992-01-01
- 结束值：1998-08-02
- 存储桶间隔天数：50
并行复制和总持续时间是在已创建的所有 50 个复制活动中观察到的最大值。 由于所有 50 个复制活动是并行运行的，所以总持续时间的最大值就是所有复制活动并行完成所需的时间。
具有逻辑分区设计的 Fabric Warehouse
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Warehouse | 逻辑设计 | 自动 | 1 | 00:12:11 |
采用逻辑分区设计的 Fabric Lakehouse（表）
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Lakehouse | 无 | 自动 | 1 | 02:10:37 |
| Fabric Lakehouse | 逻辑设计 | 自动 | 1 | 00:09:14 |
表的物理分区
注意
使用物理分区时，将根据物理表定义自动确定分区列和机制。
要使用表的物理分区，必须对源表进行分区。 为了解分区数如何影响性能，我们创建了两个分区表，一个具有 8 个分区，另一个具有 85 个分区。
物理分区的数量限制了“复制并行度”。 你仍可以通过指定小于分区数的值来限制数字。
具有物理分区的 Fabric Warehouse
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Warehouse | 无 | 自动 | 1 | 02:23:21 |
| Fabric Warehouse | 物理 | 自动 | 8 | 00:26:29 |
| Fabric Warehouse | 物理 | 自动 | 85 | 00:08:31 |
具有物理分区的 Fabric Lakehouse（表）
| 目标 | 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 |
|---|---|---|---|---|
| Fabric Lakehouse | 无 | 自动 | 1 | 02:10:37 |
| Fabric Lakehouse | 物理 | 自动 | 8 | 00:36:36 |
| Fabric Lakehouse | 物理 | 自动 | 85 | 00:12:21 |
隔离级别
我们将指定不同的“隔离级别”设置对性能的影响做个对比。 选择“隔离级别”并将“复制并行度”设置为“自动”时，复制活动可能面临源系统超负荷和活动失败的风险。 如果希望将“复制并行度”设置为“自动”，建议将“隔离级别”保留为“无”。
注意
Azure SQL 数据库默认为 *隔离级别Read_Committed_Snapshot。
扩展“动态范围”的测试用例，并将“复制并行度”设置为 50，了解“隔离级别”如何影响性能。
| 隔离级别 | 总持续时间 | 容量单位 | DB 最大 CPU % | DB 最大会话数 |
|---|---|---|---|---|
| 无(默认) | 00:14:23 | 93,960 | 70 | 76 |
| 读取未提交 | 00:13:46 | 89,280 | 81 | 76 |
| 读取已提交 | 00:25:34 | 97,560 | 81 | 76 |
为数据库源查询选择的“隔离级别”更多的是要求，而不是优化路径，但重要的是要了解每个选项之间性能和容量单位消耗的差异。
有关隔离级别的详细信息，**请参阅 IsolationLevel 枚举。
ITO 和容量消耗
与“并行副本程度”类似，“智能吞吐量优化”(ITO) 是另一个可以设置的最大值。 如果你正在优化成本，那么 ITO 是一个很好的设置，可以考虑进行调整以满足期望的结果。
ITO 范围：
| ITO | 最大值 |
|---|---|
| 自动 | 未指定 |
| 标准 | 64 |
| 均衡 | 128 |
| 最大值 | 256 |
虽然下拉列表允许进行上述设置，但我们也允许使用 4 到 256 之间的自定义值。
注意
在复制活动的输出字段 usedDataIntegrationUnits 中可以找到实际使用的 ITO 数量。
对于将“复制并行度”设置为“自动”的“动态范围”堆测试用例，服务选择了“均衡”，其实际值为 100。 我们来看看指定自定义值为 50 来将 ITO 减半时会发生什么情况：
| 指定的 ITO | 总持续时间 | 容量单位 | DB 最大 CPU % | DB 最大会话数 | 使用优化的吞吐量 |
|---|---|---|---|---|---|
| 最大值 (256) | 00:13:46 | 89,280 | 81 | 76 | 平衡 (100) |
| 50 | 00:18:28 | 48,600 | 76 | 61 | 标准值 (48) |
将 ITO 减少 50% 后总持续时间增加了 34%，但服务使用的容量单位减少了 45.5%。 如果不是为了改进总持续时间而进行优化，并且希望减少使用的容量单位，则最好将 ITO 设置为一个较低值。
总结
以下图表将加载行为汇总成了 Fabric 仓库表和 Fabric Lakehouse 表。 如果表具有物理分区，则使用“分区选项”：对于传输持续时间、容量单位和源上的计算开销来说，“表的物理分区”是最平衡的方法。 如果在数据移动期间针对数据库运行更多会话，则此设置特别适用。
如果表不具有物理分区，仍可以选择使用“分区选项”：“动态范围”。 此选项需要事先确定上限和下限，但与默认选项相比，传输持续时间仍得到了显著改进，代价是容量消耗和源计算利用率稍高，并需要测试最佳的并行度。
将复制作业性能最大化的另一个重要因素是将数据移动保持在单个云区域中。 例如，使用美国西部的数据工厂从美国西部的源数据存储和目标数据存储进行的数据移动，其表现会优于将数据从美国东部移动到美国西部的复制作业。
最后，如果速度是优化最重要的方面，那么在使用物理分区选项时，拥有优化的源表 DDL 就至关重要。 对于非分区表，请尝试“动态范围”，如果此设置不够快，请考虑逻辑分区或子边界内逻辑分区加“动态范围”的混合方法。
准则
成本 调整“智能吞吐量优化”和“复制并行度”。 “速度”对于分区表，如果存在大量分区，则使用“分区选项”：表的物理分区。 否则，如果数据倾斜或分区数量有限，请考虑使用“动态范围”。 对于具有索引的堆和表，请使用“动态范围”和“复制并行度”来限制源上暂停的查询数量。 如果可以预定义分区上限/下限，则可以实现进一步的性能提升。
考虑可维护性和开发人员的工作量。 虽然保留默认选项来移动数据花费的时间最长，但使用默认选项运行可能是最好的选择，尤其是在源表的 DDL 未知的情况下。 这样容量单位消耗也很合理。
测试案例
Fabric Warehouse 测试用例
| 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 | 容量单位 | 最大 CPU % | 最大会话计数 |
|---|---|---|---|---|---|---|
| 无 | 自动 | 1 | 02:23:21 | 51,839 | < 1 | 2 |
| 物理(8) | 自动 | 8 | 00:26:29 | 49,320 | 3 | 10 |
| 物理(85) | 自动 | 85 | 00:08:31 | 108,000 | 15 | 83 |
| 动态范围(堆) | 自动 | 242 | 00:39:03 | 282,600 | 100 | 272 |
| 动态范围(堆) | 50 | 50 | 00:13:05 | 92,159 | 81 | 76 |
| 动态范围(聚集索引) | 自动 | 251 | 00:09:02 | 64,080 | 9 | 277 |
| 动态范围(聚集索引) | 50 | 50 | 00:08:38 | 55,440 | 10 | 77 |
| 逻辑设计 | 自动 | 1 | 00:12:11 | 226,108 | 91 | 50 |
Fabric Lakehouse（表）测试用例
| 分区选项 | 复制并行度 | 已用并行副本 | 总持续时间 | 容量单位 | 最大 CPU % | 最大会话计数 |
|---|---|---|---|---|---|---|
| 无 | 自动 | 1 | 02:10:37 | 47,520 | <1% | 2 |
| 物理(8) | 自动 | 8 | 00:36:36 | 64,079 | 2 | 10 |
| 物理(85) | 自动 | 85 | 00:12:21 | 275,759 | ||
| 动态范围(堆) | 自动 | 251 | 00:36:12 | 280,080 | 100 | 276 |
| 动态范围(堆) | 50 | 50 | 00:12:01 | 101,159 | 68 | 76 |
| 动态范围(聚集索引) | 自动 | 251 | 00:06:44 | 59,760 | 11 | 276 |
| 动态范围(聚集索引) | 50 | 50 | 00:06:34 | 54,760 | 10 | 76 |
| 逻辑设计 | 自动 | 1 | 00:09:14 | 164,908 | 82 | 50 |