如何优化数据加载与数据预处理

在本节中，我们将讨论如何提高数据预处理能力，并尽可能精简常用函数以进一步增强数据加载效率。

使用多个工作程序执行数据加载与预处理

TensorFlow、MXNet Gluon 以及 PyTorch 都提供用于并行加载数据的数据加载器库。在以下 PyTorch 示例中，增加工作程序的数量能够让更多工作程序并行处理数据条目。作为一项通行原则，我们可以将工作程序的数量扩展至 CPU 数量减1的水平。这通常代表每个程序对应一个进程，并充分发挥 Python 的多线处理能力，当然具体实现细节因框架而异。多处理机制的引入能够避免 Python 全局解释器锁（GIL）使用全部 CPU 进行完全并行，进而导致资源余量不足；但这同时也意味着内存利用率将与工作程序的数量等比例增加，因为每个进程都需要在内存中保留自己的对象副本。当大家开始增加工作程序数量时，可能会引发内存不足问题。在这种情况下，我们需要选择 CPU 内存容量更高的实例类型。

为了跟踪工作程序的运行效果，我们参考以下示例数据集。在这套数据集中，__get_item__操作的休眠时长为1秒，用于模拟读取下一条记录时的对应延迟：

在示例中，我们创建一个只包含一个工作程序的数据加载器实例：

在使用单一工作程序的情况下，大家会看到它在逐一检索各个条目，且每次检索之间的延迟（间隔）为 1 秒钟：

如果将该实例上的工作程序数量增加到 3 个，则该实例至少需要 4 个 CPU 以保证并行处理的顺畅执行，具体参见以下代码：

在示例数据集中，我们可以看到 3 个工作程序正尝试并行检索 3 个条目，且操作的完成时间大约为 1 秒钟。此后，继续检索接下来的 3 个条目：

在此演示 noteobok 示例中，我们使用 Caltech-256 数据集，其中包含约 30600 张图像。在 Amazon SageMaker 训练任务中，我们使用单一 ml.p3.2xlarge 实例，其中包含 1 个 GPU 与 8 个 vCPU 。在只使用 1 个工作程序的情况下，每轮处理周期约为 260 秒，期间由单一 GPU 每秒处理大约100 张图像。而在7个工作程序的情况下，每轮处理周期为 96 秒，每秒能够处理约 300 张图像，相当于性能提高了 3 倍。

下图所示，为单一工作程序在峰值利用率为 50% 时捕捉的 GPUUtilization 指标。

下图所示，为多工作程序、平均资源利用率为 95% 时捕捉的 GPUUtilization 指标。

对 num_workers 做出的细微调整能够进一步加快数据加载速度，缩短数据的等待时长，从而让 GPU 的训练速度得到提升。这表明优化数据加载器中的 I/O性能，确实能够提高GPU资源利用率。

在单一 GPU 上完成优化调整之后，接下来大家应选择在多 GPU 或多主机分布式 GPU 上进行模型训练。因此，在实际进行分布式训练之前，首先要保证能够在单一 GPU 上获得最理想的资源利用率。

优化常用函数

尽可能减少资源成本高昂的操作，同时在可能的情况下（使用 GPU 或 CPU ）检索各个记录项以提高训练性能。大家可以通过多种方式优化常用函数，例如使用正确的数据结构。

在演示 notebook 示例中，我们这套简单的实现方案会加载图像文件并调整各个条目的大小，具体参见以下示例代码。我们通过预处理 Caltech 256 数据集来优化函数，包括提前调整图像大小并保存处理后的图像文件版本。其中 __getitem__ 函数仅尝试对图像进行随机裁剪，这就让 __getitem__ 函数变得非常精简。 GPU 用于等待 CPU 预处理数据的时间更短，数据也将更快被交付至 GPU 内存。具体参见以下代码：

仅仅凭借这一项简单的更改，我们就成功将每轮处理周期缩短至 96 秒，每秒处理的图像增长至 300 张，速度相当于单一工作程序处理未优化数据集时的 3 倍。另外，即使进一步增加工作程序的数量， GPU 受到的影响也不大，因为数据加载过程不再构成性能瓶颈。

在某些情况下，大家可能需要不断增加工作程序数据并优化代码，借此实现 GPU 资源利用率最大化。

下图所示，为优化后数据集配合单一工作程序时的 GPU 资源利用率。

下图所示，为使用未优化数据集时的 GPU 资源利用率。

了解您的 ML 框架

不同深度学习框架中的数据加载库可以提供多种数据加载优化选项， TensorFlow 数据加载器、MXNet 以及 PyTorch 数据加载器都有相关功能。您应该探索最适合当前用例与取舍方向的数据加载器与库参数。其中部分相关选项包括：

CPU 固定内存 —— 允许您加快从 CPU（主机）内存到 GPU（设备）内存的数据传输速度。之所以能够实现加速，是因为我们直接分配页面锁定（或者称固定）内存（而非先分配页面内存、再将数据从 CPU 分页内存传输至 CPU 固定内存、再到 GPU 内存）以实现性能提升。在 PyTOrch 与 MXNet 中，我们可以在数据加载器内启用 CPU 固定内存。这里的取舍在于，相较于分页内存，固定 CPU 内存机制更可能引发内存不足异常。
Modin —— 这是一种轻量化并行处理数据框，允许大家以并行方式执行类似于Pandas数据框的操作，从而充分利用设备上的 CPU 资源。 Modin 可以使用多种不同类型的并行处理框架，包括 Dask 与 Ray 。
CuPy —— 该开源矩阵库与 NumPy 类似，能够配合 Python 实现 GPU 计算加速。

以启发式方法找到 I/O 瓶颈

Amazon SageMaker 能够立足训练阶段提供关于 GPU、CPU 以及磁盘利用率等多种 Amazon CloudWatch 指标。

以下启发式方法，能够帮助大家通过各类开箱即用的指标发现关于 I/O 的各类性能问题：

如果您的训练作业启动时间很长，则代表大部分时间被用于数据下载。您应该了解从 Amazon S3 下载数据方面的优化方法，具体请参阅前文内容。
如果 GPU 利用率过低，但磁盘或者 CPU 的利用率过高，则代表数据加载或预处理可能正是引发瓶颈的根源。您可能需要在训练之前进行数据预处理；另外，大家也可以遵循前文建议优化各项常用函数。
如果数据集已经非常庞大，但 GPU 使用率低下且 CPU 与磁盘利用率一直很低（但不为零），则可能意味着当前代码未能充分利用基础设施资源。如果您发现 CPU 内存的利用率同样很低，那么最有效的快速解决办法可能是增加深度学习框架数据加载器 API 中的工作程序数量。