DTU 利用率未超过 56%
DTU utilization is not going above 56%
我正在使用 azure 数据工厂 v2 在 azure sql 服务器上加载数据。我开始加载数据，数据库设置为具有 800 个 DTU 的标准定价层。它很慢，所以我将 DTU 增加到 1600。（我的管道在 7 小时后仍然 运行）。
我决定更改定价等级。我将定价层更改为高级，DTU 设置为 1000。（我没有进行任何其他更改）。
管道因失去连接而失败。我重新运行管道。
现在，当我监控管道时，它工作正常。当我监控数据库时。 DTU 使用率平均不超过 56%。
我正在处理海量数据。我怎样才能加快这个过程？
我预计 DTU 必须达到最大值。但平均利用率约为 56%。
请遵循此文档Copy activity performance and scalability guide。
本教程为我们提供了Performance tuning steps。
其中一种方法是使用更多 DTU 增加 Azure SQL 数据库层。您已将 Azure SQL 数据库层增加了 1000 个 DTU，但平均利用率约为 56%。我认为您不需要那么高的价格等级。
您需要考虑其他提高性能的方法。比如设置更多Data Integration Units(DIU).
数据集成单元是一种度量，表示 Azure 数据工厂中单个单元的能力（CPU、内存和网络资源分配的组合）。数据集成单元仅适用于 Azure 集成运行时，不适用于自托管集成运行时。
希望这对您有所帮助。
Microsoft 的标准答案似乎是您需要调整目标数据库或向上扩展到更高层。这表明 Azure 数据工厂不是复制性能的限制因素。
不过，我们对单个 table、单个副本 activity、约 15 GB 的数据进行了一些测试。 table没有包含varchar(max)，高精度，只是简单明了的数据。
结论：你选择什么样的层几乎没有关系（当然也不会太低），大约在 S7 / 800 DTU，8 个 vcores 以上，副本的性能 activity 是 ~10 MB/s 并且不会上升。目标数据库的负载为50%-75%。
我们的假设是，由于我们可以继续使用更高的数据库层来解决这个问题，但没有看到副本 activity 性能有任何改善，这与 Azure 数据工厂有关。
我们的解决方案是，由于我们正在加载大量单独的 tables，因此通过 for each 循环横向扩展而不是纵向扩展，并将批次计数设置为至少 4。
增加DIU的方法只适用于某些情况：
https://docs.microsoft.com/en-us/azure/data-factory/copy-activity-performance#data-integration-units
Setting of DIUs larger than four currently applies only when you copy
multiple files from Azure Storage, Azure Data Lake Storage, Amazon S3,
Google Cloud Storage, cloud FTP, or cloud SFTP to any other cloud data
stores.
在我们的例子中，我们从关系数据库中复制数据。
我正在使用 azure 数据工厂 v2 在 azure sql 服务器上加载数据。我开始加载数据，数据库设置为具有 800 个 DTU 的标准定价层。它很慢，所以我将 DTU 增加到 1600。（我的管道在 7 小时后仍然 运行）。
我决定更改定价等级。我将定价层更改为高级，DTU 设置为 1000。（我没有进行任何其他更改）。
管道因失去连接而失败。我重新运行管道。
现在，当我监控管道时，它工作正常。当我监控数据库时。 DTU 使用率平均不超过 56%。
我正在处理海量数据。我怎样才能加快这个过程？
我预计 DTU 必须达到最大值。但平均利用率约为 56%。
请遵循此文档Copy activity performance and scalability guide。
本教程为我们提供了Performance tuning steps。
其中一种方法是使用更多 DTU 增加 Azure SQL 数据库层。您已将 Azure SQL 数据库层增加了 1000 个 DTU，但平均利用率约为 56%。我认为您不需要那么高的价格等级。
您需要考虑其他提高性能的方法。比如设置更多Data Integration Units(DIU).
数据集成单元是一种度量，表示 Azure 数据工厂中单个单元的能力（CPU、内存和网络资源分配的组合）。数据集成单元仅适用于 Azure 集成运行时，不适用于自托管集成运行时。
希望这对您有所帮助。
Microsoft 的标准答案似乎是您需要调整目标数据库或向上扩展到更高层。这表明 Azure 数据工厂不是复制性能的限制因素。
不过，我们对单个 table、单个副本 activity、约 15 GB 的数据进行了一些测试。 table没有包含varchar(max)，高精度，只是简单明了的数据。
结论：你选择什么样的层几乎没有关系（当然也不会太低），大约在 S7 / 800 DTU，8 个 vcores 以上，副本的性能 activity 是 ~10 MB/s 并且不会上升。目标数据库的负载为50%-75%。
我们的假设是，由于我们可以继续使用更高的数据库层来解决这个问题，但没有看到副本 activity 性能有任何改善，这与 Azure 数据工厂有关。
我们的解决方案是，由于我们正在加载大量单独的 tables，因此通过 for each 循环横向扩展而不是纵向扩展，并将批次计数设置为至少 4。
增加DIU的方法只适用于某些情况： https://docs.microsoft.com/en-us/azure/data-factory/copy-activity-performance#data-integration-units
Setting of DIUs larger than four currently applies only when you copy multiple files from Azure Storage, Azure Data Lake Storage, Amazon S3, Google Cloud Storage, cloud FTP, or cloud SFTP to any other cloud data stores.
在我们的例子中，我们从关系数据库中复制数据。