排查复制活动的性能问题

适用于： Azure Data Factory Azure Synapse Analytics

本文概述了如何排查Azure Data Factory中的复制活动性能问题。

运行复制活动后，可以在复制活动监视视图中收集运行结果和性能统计信息。 下图显示了一个示例。

性能优化提示

在某些情况下，运行复制活动时，顶部会显示“性能优化提示”，如上图所示。 这些提示告知服务针对此特定复制运行识别到的瓶颈，并建议如何提高复制吞吐量。 请尝试根据建议进行更改，然后再次运行复制。

作为参考，当前性能优化提示针对以下情况提供了建议：

了解复制活动执行详细信息

复制活动监视视图底部的执行详细信息和持续时间描述了复制活动所要经历的重要阶段（请参阅本文开头的示例），这对于排查复制性能问题特别有用。 复制运行的瓶颈就是持续时间最长的那个运行。 请参阅下表，了解每个阶段的定义，以及如何使用这些信息在 Azure IR 上排查复制活动和在自承载 IR 上排查复制活动。

排查 Azure IR 上的复制活动问题

遵循性能优化步骤为方案规划并执行性能测试。

当复制活动性能不符合预期时，若要排查在Azure Integration Runtime上运行的单个复制活动时，如果看到性能优化提示显示在复制监视视图中，请应用建议，然后重试。 否则，请了解复制活动执行详细信息，检查哪个阶段的持续时间最长，并应用以下指导以提升复制性能：

• “复制前脚本”的持续时间较长：表示接收器数据库中运行的复制前脚本花费了较长时间来完成。 优化指定的复制前脚本逻辑，以增强性能。 如果在改进脚本方面需要更多的帮助，请与数据库团队联系。

• “传输 - 第一个字节的时间”经历了长时间的延迟：源查询需要很长时间才能返回任何数据。 这可能意味着查询处理源需要很长时间，因为源正忙于其他任务，或者查询不是最佳的，或者数据以这样一种方式存储，因此需要很长时间才能检索。 请考虑其他查询是否同时在该源上运行，或者是否有任何可以对查询进行更新，以便它可以更快地检索数据。 如果有一个团队管理数据源，请联系他们来修改查询或检查源性能。

• “传输 - 列出源”的工作持续时间较长： 表示枚举源文件或源数据库数据分区的速度缓慢。

  • 从基于文件的源复制数据时，如果对文件夹路径或文件名使用通配符筛选器（wildcardFolderPath 或 wildcardFileName），或使用文件上次修改时间筛选器（modifiedDatetimeStart 或 modifiedDatetimeEnd），请注意，此类筛选器会导致复制活动在客户端中列出指定文件夹下的所有文件，然后应用筛选器。 此类文件枚举可能会变成瓶颈，尤其是只有少量的文件符合筛选规则时。

    • 检查是否可以基于按日期时间分区的文件路径或名称复制文件。 这样不会给列表来源端带来负担。

    • 检查是否可以改用数据存储的原生筛选器，特别是在 Amazon S3、Azure Blob 存储或 Azure Files 中使用“prefix”。 这些筛选器是数据存储服务器端筛选器，拥有更好的性能。

    • 考虑将单个大型数据集拆分为多个小型数据集，并让每个并发运行的复制作业处理一部分数据。 为此，可以使用 Lookup/GetMetadata + ForEach + Copy。 请参阅从多个容器复制文件或将数据从 Amazon S3 迁移到 ADLS Gen2 解决方案模板，其中提供了一般性的示例。

  • 检查服务是否报告了源中的任何限流错误，或者数据存储是否处于高负载状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

  • 在同一个或靠近源数据存储区域中使用 Azure IR。

• “传输 - 从源读取”的工作持续时间较长：

  • 采用特定于连接器的数据加载最佳做法（如果适用）。 例如，从 Amazon Redshift 复制数据时，请配置为使用 Redshift UNLOAD。

  • 检查服务是否报告了源中的任何节流错误，或者您的数据存储是否处于高负载状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

  • 检查复制源和接收器模式：

    • 如果复制模式支持 4 个以上的数据集成单位 (DIU) - 请参阅此部分中的详细信息，一般情况下，可以尝试增加 DIU 以获得更好的性能。

    • 否则，请考虑将单个大型数据集拆分为多个小型数据集，并让那些复制作业并发运行，使其各自处理一部分数据。 为此，可以使用 Lookup/GetMetadata + ForEach + Copy。 请参阅从多个容器复制文件、将数据从 Amazon S3 迁移到 ADLS Gen2 或使用控制表进行批量复制解决方案模板，其中提供了一般性的示例。

  • 在同一个或靠近源数据存储区域中使用 Azure IR。

• “传输 - 写入接收器”的工作持续时间较长：

  • 采用特定于连接器的数据加载最佳做法（如果适用）。 例如，将数据复制到 Azure Synapse Analytics 时，请使用 PolyBase 或 COPY 语句。

  • 检查该服务是否报告了接收器中的任何限制错误，或者数据存储是否处于高利用率状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

  • 检查复制源和接收器模式：

    • 如果复制模式支持 4 个以上的数据集成单位 (DIU) - 请参阅此部分中的详细信息，一般情况下，可以尝试增加 DIU 以获得更好的性能。

    • 否则，请逐步优化并行副本。 过多的并行复制甚至可能会损害性能。

  • 在和接收器数据存储同一区域或邻近区域中使用 Azure IR。

排查自承载 IR 中的复制活动的问题

遵循性能优化步骤为方案规划并执行性能测试。

当复制性能不符合预期时，若要排查在Azure Integration Runtime上运行的单个复制活动问题，如果看到性能优化提示显示在复制监视视图中，请应用建议，然后重试。 否则，请了解复制活动执行详细信息，检查哪个阶段的持续时间最长，并应用以下指导以提升复制性能：

• “队列”持续时间较长： 表示复制活动在队列中长时间等待，直到Self-hosted IR有资源来执行。 检查 IR 容量和使用率，并根据工作负荷进行纵向或横向扩展。

• “传输 - 距第一字节的时间”的工作持续时间较长： 表示源查询花费了较长时间来返回任何数据。 检查并优化查询或服务器。 如需更多帮助，请与数据存储团队联系。

• “传输 - 列出源”的工作持续时间较长： 表示枚举源文件或源数据库数据分区的速度缓慢。

  • 检查自托管 IR 服务器是否以较低的延迟连接到源数据存储。 如果源位于 Azure 上，则可以使用 此工具 检查自承载集成运行时计算机到 Azure 区域的延迟，延迟越小越好。

  • 从基于文件的源复制数据时，如果对文件夹路径或文件名使用通配符筛选器（wildcardFolderPath 或 wildcardFileName），或使用文件上次修改时间筛选器（modifiedDatetimeStart 或 modifiedDatetimeEnd），请注意，此类筛选器会导致复制活动在客户端中列出指定文件夹下的所有文件，然后应用筛选器。 此类文件枚举可能会变成瓶颈，尤其是只有少量的文件符合筛选规则时。

    • 检查是否可以基于按日期时间分区的文件路径或名称复制文件。 这样不会给列表来源端带来负担。

    • 检查是否可以改用数据存储的原生过滤器，特别是针对 Amazon S3、Azure Blob 存储或 Azure Files 使用 "prefix"。 这些筛选器是数据存储服务器端筛选器，拥有更好的性能。

    • 考虑将单个大型数据集拆分为多个小型数据集，并让每个并发运行的复制作业处理一部分数据。 为此，可以使用 Lookup/GetMetadata + ForEach + Copy。 请参阅从多个容器复制文件或将数据从 Amazon S3 迁移到 ADLS Gen2 解决方案模板，其中提供了一般性的示例。

  • 检查服务是否报告了源中的任何限流错误，或者数据存储是否处于高负载状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

• “传输 - 从源读取”的工作持续时间较长：

  • 检查自托管 IR 服务器是否以较低的延迟连接到源数据存储。 如果源位于Azure中，则可以使用 此工具检查自承载 IR 计算机到Azure区域的延迟，越好越好。

  • 检查自承载 IR 计算机是否具有足够的入站带宽，可以有效地读取和传输数据。 如果源数据存储位于Azure中，可以使用 此工具检查下载速度。

  • 在 Azure 门户 -> 数据工厂或 Synapse 工作区 -> 概述页面查看自承载 IR 的 CPU 和内存使用率趋势。 如果 CPU 使用率较高或可用内存不足，请考虑对 IR 进行纵向或横向扩展。

  • 采用特定于连接器的数据加载最佳做法（如果适用）。 例如：

    • 从 Oracle 复制数据时，Netezza， Teradata、SAP HANA、SAP Table 和 SAP Open Hub），使数据分区选项能够并行复制数据。

    • 从 HDFS复制数据时，请配置为使用 DistCp。

    • 从 Amazon Redshift 复制数据时，请配置为使用 Redshift UNLOAD。

  • 检查服务是否报告了源中的任何节流错误，或者您的数据存储是否处于高负载状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

  • 检查复制源和接收器模式：

    • 如果从启用分区选项的数据存储复制数据，请考虑逐步优化并行副本。 过多的并行复制甚至可能会损害性能。

    • 否则，请考虑将单个大型数据集拆分为多个小型数据集，并让那些复制作业并发运行，使其各自处理一部分数据。 为此，可以使用 Lookup/GetMetadata + ForEach + Copy。 请参阅从多个容器复制文件、将数据从 Amazon S3 迁移到 ADLS Gen2 或使用控制表进行批量复制解决方案模板，其中提供了一般性的示例。

• “传输 - 写入接收器”的工作持续时间较长：

  • 采用特定于连接器的数据加载最佳做法（如果适用）。 例如，将数据复制到 Azure Synapse Analytics 时，请使用 PolyBase 或 COPY 语句。

  • 检查自承载 IR 计算机是否以较低的延迟连接到接收器数据存储。 如果接收器位于 Azure 中，则可以使用此工具检查自托管 IR 机器到 Azure 区域的延迟，延迟越小越好。

  • 检查自承载 IR 计算机是否具有足够的出站带宽，可以有效地传输和写入数据。 如果接收器数据存储位于Azure中，则可以使用 此工具来检查上传速度。

  • 在 Azure 门户 -> 数据工厂或 Synapse 工作区 -> 概述页中检查自承载 IR 的 CPU 和内存使用率趋势是否存在。 如果 CPU 使用率较高或可用内存不足，请考虑对 IR 进行纵向或横向扩展。

  • 检查该服务是否报告了接收器中的任何限制错误，或者数据存储是否处于高利用率状态。 如果是，请减少数据存储上的工作负荷，或者尝试联系数据存储管理员来提高限流或增加资源的可用性。

  • 请考虑逐步调整并行复制。 过多的并行复制甚至可能会损害性能。

连接器和 IR 性能

本部分探讨特定连接器类型或集成运行时的一些性能故障排除指南。

活动执行时间因AZURE IR 与 Azure 虚拟网络 IR 而异

当数据集基于不同的Integration Runtime时，活动执行时间会有所不同。

• 症状：只需在数据集中切换“链接服务”下拉列表就可以执行相同的管道活动，但运行时间会明显不同。 当数据集基于托管虚拟网络集成运行时时，平均运行时间比基于默认集成运行时的时间要长。

• Cause：检查管道运行的详细信息，可以看到慢速管道在托管虚拟网络（Virtual Network）IR 上运行，而正常管道在 Azure IR 上运行。 根据设计，托管虚拟网络集成运行时 (Managed Virtual Network IR) 的排队时间比 Azure 集成运行时 (Azure IR) 更长，因为我们没有为每个服务实例单独预留计算节点，因此每个复制活动在启动时都需要进行预热，这种预热主要发生在虚拟网络加入过程中，而不是在 Azure 集成运行时中。

将数据加载到 Azure SQL Database 时性能低

• Symptoms：将数据复制到 Azure SQL Database 的速度变慢。

• cause：问题的根本原因主要由Azure SQL Database端的瓶颈触发。 下面是一些可能的原因：

  • Azure SQL Database服务层级不够高。

  • Azure SQL Database DTU 使用率接近 100%。 可以监视性能，并考虑升级Azure SQL Database层。

  • 索引未正确设置。 请在加载数据之前先删除所有索引，并在加载完成之后再重新创建索引。

  • WriteBatchSize 不够大，无法容纳架构行大小。 若要解决此问题，请尝试增大该属性。

  • 使用的是存储过程，而不是批量插入，这会使性能更差。

分析大型 Excel 文件时超时或性能较低

• 表现：

  • 在创建 Excel 数据集并从连接/存储导入架构、预览数据、列出或刷新工作表时，如果 Excel 文件很大，则可能会遇到超时错误。

  • 在使用复制活动将大型 Excel 文件 (>= 100 MB) 中的数据复制到其他数据存储时，可能会遇到性能低下或 OOM 问题。

• 原因：

  • 对于导入架构、预览数据以及在 Excel 数据集上列出工作表等操作， 超时时间固定为 100 秒。 对于大型 Excel 文件，这些操作可能无法在超时值内完成。

  • 复制活动将整个 Excel 文件读入内存，然后查找指定的工作表和单元格来读取数据。 此行为是由服务使用的基础 SDK 导致的。

• 解决方法：

  • 对于导入架构，你可以生成一个较小的示例文件（原始文件的一部分），并选择“从示例文件导入架构”而不是“从连接/存储导入架构”。

  • 若要列出工作表，可以改为在工作表下拉框中选择“编辑”并输入工作表名称/索引。

  • 若要将大型 Excel 文件（>100 MB）复制到其他存储中，可以使用支持流式读取且执行性能更佳的 Data Flow Excel 源。

读取大型 JSON/Excel/XML 文件时出现 OOM 问题

• 症状：读取大型 JSON/Excel/XML 文件时，在活动执行期间遇到内存不足 (OOM) 问题。

• 原因：

  • 如果读取的是大型 XML 文件：读取大型 XML 文件时出现内存不足问题是有意这样设计的。 原因是整个 XML 文件必须作为单个对象读取到内存中，然后再推断架构并检索数据。
  • 对于大型 Excel 文件：读取大型 Excel 文件时出现内存不足（OOM）问题是设计使然。 原因是使用的 SDK (POI/NPOI) 必须将整个 Excel 文件读取到内存中，然后再推断架构并获取数据。
  • 如果读取的是大型 JSON 文件：当 JSON 文件是单个对象时，读取大型 JSON 文件出现内存不足问题是有意这样设计的。

• 建议做法：采用以下其中一个选项来解决此问题。

  • 选项 1：使用性能强（CPU 性能强/内存容量大）的电脑注册联机自承载集成运行时，通过复制活动读取大型文件中的数据。
  • 选项 2：使用优化的内存和大型群集（例如，48 个核心），通过映射数据流活动读取大型文件中的数据。
  • 选项 3：将大型文件拆分成多个小文件，然后使用复制或映射数据流活动读取文件夹。
  • 选项 4：如果在复制 XML/Excel/JSON 文件夹期间卡住或是遇到 OOM 问题，请使用管道中的 foreach 活动 + 复制/映射数据流活动来处理每个文件或子文件夹。
  • 选项 5：其他：
    • 使用内存优化集群的笔记本活动读取 XML 文件中的数据，前提是每个文件的架构都相同。 目前，Apache Spark 提供多种实现方法来处理 XML 文件。
    • 在映射数据流源的“JSON 设置”中，针对 JSON 文档使用不同的格式（例如，“单个文档”、“每行一个文档”和“文档数组”）。 如果 JSON 文件内容为“每行文档”，则其占用的内存很少。

其他参考资料

这里是一些支持的数据存储的性能监测和调优参考资料：

• Azure Blob 存储：Blob 存储的可扩展性和性能目标和 Blob 存储的性能与可扩展性清单。
• Azure表存储：表存储的可缩放性和性能目标和表存储的性能和可伸缩性清单。
• Azure SQL Database：可以监视性能并检查数据库事务单位（DTU）百分比。
• Azure Synapse Analytics：其功能以数据仓库单位（DWU）度量。 请参阅 Azure Synapse Analytics 中的 管理计算资源（概述）。
• Azure Cosmos DB：Azure Cosmos DB性能级别。
• SQL Server：监控和调整性能。
• 本地文件服务器：文件服务器性能优化。

相关内容

请参阅其他复制活动文章：

• 复制活动概述
• Copy activity性能和可伸缩性指南
• Copy activity性能优化功能
• 将数据从数据湖或数据仓库迁移到 Azure
• 将数据从 Amazon S3 迁移到 Azure Storage