数据分布的偏斜 - 图片来自 Vackground.com on Unsplash

Azure 数据工厂（ADF）是一种流行的工具，用于大规模地移动数据，特别是在企业数据湖场景下。它常用于摄取和转换数据，通常从本地环境复制数据到 Azure 存储。数据随后按照 medallion 模型在不同的区域流动。在数据损坏、恶意软件或账户删除等灾难情况下，ADF 对于备份的创建和恢复至关重要。

这表明ADF被用来移动大量数据，TB甚至PB的数据量。因此，优化复制性能以减少吞吐时间是很重要的。一种常见的提高ADF性能的方式是并行化复制活动。然而，并行化应在数据量最大的地方实施，而这在数据湖分布不均时可能会很具挑战性。

在这篇博客文章中，讨论了在数据湖中使用ADF的不同并行化策略，并部署了该项目。该项目的ADF解决方案可以在以下链接中找到：https://github.com/rebremer/data-factory-copy-skewed-data-lake。

数据湖的大小和形态各异。了解数据湖中的数据分布有助于提高复制效率，这在某些上下文中可能更贴切。例如，考虑以下情况：

• 一个 Azure 存储账户有 N 个容器。
• 每个容器都有 M 个文件夹，并且有 m 层子文件夹。
• 数据在文件夹中均匀分布，每个文件夹里的数据量大致相等。

请看下图：

2.1 数据湖中的数据 — 图片由作者制作

在这种情境下，可以在每个容器 N 内并行化复制活动。对于较大的数据量，可以通过在容器 N 内的文件夹 M 中并行化进一步提高性能。随后，可以针对每个复制活动配置多少 数据集成单元 (DIU) 以及在每个复制活动内的并行处理 复制并行化。

现在考虑这种情况：假设最后一个文件夹 Nk 和 Mk 包含 99% 的数据，如图所示。

2.2 包含分布不均数据的数据湖 — 图片由作者制作

这意味着并行化需要在Nk/Mk中的子文件夹内进行，数据就在那里。为了准确找到数据位置，需要更复杂的逻辑。可以使用集成在ADF中的Azure函数来实现这个目标。在下一章，我们将部署一个项目，并更详细地讨论并行化选项。

在这部分，项目被部署，并运行了一个复制测试，并讨论了测试结果。请参见项目：https://github.com/rebremer/data-factory-copy-skewed-data-lake。

运行脚本 [deploy_adf.ps1](https://github.com/rebremer/data-factory-copy-skewed-data-lake/blob/main/deploy_adf.ps1)。如果 ADF 成功部署了，将部署两个管道任务：

3.1.1 数据工厂项目，包含主管道和子管道 — 作者提供图片

接下来运行脚本 [deploy_azurefunction.ps1](https://github.com/rebremer/data-factory-copy-skewed-data-lake/blob/main/deploy_azurefunction.ps1)。如果 Azure Function 成功部署，则将部署相关代码。

3.1.2 Azure 函数 用于查找“数据孤岛”（即数据口袋），以帮助 ADF 更好地并行处理

要运行项目之前，请确保分配的Azure函数和数据工厂的系统托管的标识有权访问数据复制的来源和目标存储帐户。

项目部署之后，可以发现以下工具，如XXX等，被部署来通过并行化提升性能。

• 根管道（父管道）: 列出存储账户中的容器N并为每个容器触发子管道。
• 子管道（子流程）: 列出容器中的文件夹M并为每个文件夹触发递归复制活动。
• 分支结构（开关结构）: 子管道使用分支结构来决定如何列出文件夹。对于“默认”情况，使用获取到元数据；对于“非默认”情况，使用Azure函数。
• 获取到元数据: 列出给定容器中的所有根文件夹M。
• Azure函数: 列出所有包含不超过X GB数据的文件夹和子文件夹，并将它们作为整体复制。
• 复制活动: 递归复制给定文件夹中的所有数据。
• DIU: 每个复制活动的数据集成单元数量。
• 复制并行: 在复制活动内可以启动的并行复制线程数，每个线程可以复制一个文件，最多50个。

在均匀分布的数据湖中，数据均匀分布于N个容器和M个文件夹中。在这种情形下，复制活动可以在每个文件夹上并行执行。这可以通过使用“获取元数据”来列出文件夹，使用“对于每个”来遍历每个文件夹，并在每个文件夹中执行复制活动来实现。如下图所示。

3.2.1 以均匀分布的数据的子管道结构

采用这种方法，这就意味着每个复制任务都将复制相同数量的数据。总共将执行 N*M 次复制任务。

在分布不均的数据湖中，数据并未均匀分布在N个容器和M个文件夹之间。在这种情形下，复制活动需要动态确定。这可以通过Azure函数来列出数据量大的文件夹，然后使用For Each循环遍历每个文件夹并执行相应的复制活动。请参见下方图片。

3.2.2 聚焦偏斜分布数据的子管道架构

使用这种方法，复制活动在数据湖中可以根据需要动态调整规模，并且在这种情况下最需要并行处理。虽然这种解决方案相比之前的更加复杂，因为它需要使用 Azure Function，但它允许复制分布不均匀的数据。

为了比较不同并行处理选项的性能，我们设置了一个简单的测试，具体如下：

• 在 westeurope 区域使用两个存储帐户和一个 ADF 实例，并使用 Azure IR。数据从源存储帐户复制到目标存储帐户。
• 源存储账户包含三个容器，每个容器有 0.72 TB 的数据，并分布在多个文件夹和子文件夹中。
• 数据在容器中均匀分布，没有数据倾斜现象。

测试 A：复制一个容器，使用 32 DIU 和 16 个线程，复制任务均设置为自动模式 => 成功复制了 0.72 TB 的数据，耗时 12 分 27 秒，平均传输速率为 0.99 GB/s

测试 B：使用 128 DIU 和 32 个线程进行复制，复制一个容器，复制的数据量是 0.72 TB，复制时间是 6 分 19 秒，平均吞吐量是 1.95 GB/s。

测试C：将一个容器和一个复制活动复制一份，使用200 DIU和最多50个线程来 => 测试因节流而停止，与测试B相比，没有看到性能提升。

测试 D：复制 2 个数据容器，使用 128 个 DIU 并行执行，每个复制活动使用 32 个线程，复制 1.44 TB 的数据，复制耗时 07 分钟 00 秒，每秒平均吞吐量为 3.53 GB。

测试E：通过3个复制任务并使用128个DIU和每个复制任务32个线程复制3个容器的内容，复制了2.17TB的数据，复制时间为8分钟7秒，平均速度为4.56GB/s。如下图所示。

测试 E：3 个并行复制活动的吞吐量测试，每个活动使用 128 DIU 和 32 线程，数据量为共 3 个，每个 0.72TB。

在这里需要注意的是，ADF 并不会立即开始复制，因为它有一个启动延迟，这一点对于 Azure IR 来说大约是 10 秒。启动延迟是固定的，对于大规模的复制任务而言，其对吞吐量的影响可以忽略不计。此外，一个存储账户的最大传入带宽限速是 60 Gbps (=7.5 GB/s)。除非请求增加额外容量，否则无法超出这个限速。

以下是从测试中得出的一些要点：

• 仅通过增加复制活动中的 DIU 和并行设置，即可获得显著的性能提升。
• 通过并行运行复制管道，性能可以进一步提高。
• 在此测试中，数据均匀分布在两个容器之间。如果数据分布不均，例如，容器 1 的所有数据都位于容器 2 的一个子文件夹内，则两个复制活动都需要针对容器 2 进行。这可以确保与测试 D 类似的性能。
• 如果数据位置不确定或者嵌套很深，则需要使用 Azure 函数来识别数据区，以确保复制活动能够正确执行。

Azure 数据工厂（ADF）是一个广泛使用的数据大规模移动工具。它广泛用于企业数据湖中的数据导入、转换、备份及恢复。鉴于其在大规模数据移动中的作用，优化数据复制性能以减少吞吐时间至关重要。

在这篇博客文章中，我们讨论了几种提升数据在Azure存储之间复制性能的并行处理策略。

• 在复制活动中，使用标准的数据集成单元（DIU）和复制活动中的并行线程。
• 如果数据已知均匀分布，可以利用ADF的标准功能将复制活动在每个容器（N）和根文件夹（M）中并行执行。
• 在数据所在的位置运行复制活动。如果之前不清楚数据位置或数据嵌套很深，可以使用Azure函数来查找数据。然而，在ADF管道中加入Azure函数会增加复杂性，除非必要，否则应尽量避免使用。

很遗憾，没有一劳永逸的解决方案，总是需要进行分析和测试来找出提升企业数据湖性能的最佳策略。本文旨在提供选择最佳策略的指南。