数据工厂复制活动和 ZipDeflate 吞吐量低答案

【问题标题】：Data Factory copy activity and ZipDeflate throughput low数据工厂复制活动和 ZipDeflate 吞吐量低
【发布时间】：2018-11-25 08:47:45
【问题描述】：

我目前有一个由简单的 Copy 活动组成的管道，它从第三方的 FTP 服务器获取压缩文件，解压缩文件并将它们复制到 blob 存储容器。

吞吐量非常低（7 KB/s），简单地复制文件而不解压缩不会造成任何问题（700 KB/s，这与使用 FileZilla 的 FTP 服务器的常规下载速度一致）。

对于数据工厂团队，运行 ID 为：825e15a9-aba6-47ed-8656-88c9b6bc3754

以下数据集中的部分名称已被修改。

输入数据集： { "name": "InputDataset", "properties": { "linkedServiceName": { "referenceName": "3PPFtpServer", "type": "LinkedServiceReference" }, "type": "FileShare", "typeProperties": { "compression": { "type": "ZipDeflate", "level": "Fastest" }, "fileName": "sample_file.zip", "folderPath": "/dir1/dir2/" } }, "type": "Microsoft.DataFactory/factories/datasets" }

输出数据集： { "name": "OutputDataset", "properties": { "linkedServiceName": { "referenceName": "AzureStorageLinkedService", "type": "LinkedServiceReference" }, "type": "AzureBlob", "typeProperties": { "fileName": "", "folderPath": "test-output/" } }, "type": "Microsoft.DataFactory/factories/datasets" }

我在调整减压方面有什么问题吗？

【问题讨论】：

标签： ftp azure-blob-storage azure-data-factory azure-data-factory-2

【解决方案1】：

您是否正在使用自托管集成运行时访问 ftp 服务器？还是 Azure IR？

如果是自托管的，很可能是你的处理能力不足以更快地解压和上传文件，所以最好的方案是上传压缩文件，然后在 Azure 存储中解压，所以它将文件解压缩到云中。您将有 2 个复制活动和 3 个数据集：

活动 1：将压缩文件从 ftp 复制到 Azure 存储。数据集将与您现在一样，但输出数据集将使用与输入相同的压缩类型。活动 2：将解压后的文件从 Azure 存储复制到 Azure 存储（当然是另一个文件夹）。输入数据集将与 Activity1 的输出相同，输出将是您在问题中显示的数据集。

希望这有帮助！

【讨论】：

我正在使用 Azure IR，但我会尝试使用 2 个活动。
我在使用 ZipDeflate 时也面临吞吐量低的问题。我在云端解压文件（类似于Marting所说的），解压900MB的压缩文件需要3个多小时。 @Martin Esteban Zurita 我开发了一些其他需要解压缩 .gz 文件（使用 gz 压缩类型）的管道，它的执行速度要快得多。我认为他们用于压缩文件的算法也会产生影响。这是 ADF 无法提升的。