使用作业处理功能高效处理多个文件

假设您有许多文件存储在 IBM Cloud Object Storage 存储区中，并且要在 Code Engine中使用批处理。 目标是从一个存储区中读取文件，处理文件并以最有效的方式将文件存储在另一个 Object Storage 存储区中。 假设您每天在输入存储区中有 2000 个文件。 所有文件都具有不同的文件名，文件名以字母字符 (A-Z 和 a-z) 开头。

在为此方案规划解决方案时，首先要考虑基于事件的解决方案。 在此情况下，对于写入输入 Object Storage 存储区的每个文件，将创建一个事件并调用 Code Engine 应用程序。 通过使用事件，单个文件可能会触发个别处理，这对于许多文件而言可能是低效的。

运行批处理作业可以是更好的方法吗? 可以! 让我们来了解为什么批处理作业更适合同时处理多个文件。

1. 确定将文件集划分为并行流的方法。 让我们根据文件名的第一个字符来划分文件。 通过此方法，您可以拥有 26 个流，每个流负责以一个特定字符开头的文件。 您可以通过读取正在运行的作业实例的自动注入的 JOB_INDEX 环境变量来标识特定流。 请参阅 自动为作业注入环境变量。 对于此示例，您可以通过将实例数指定为 26 或将数组下标指定为 0-25 来配置作业实例。

   将为每个正在运行的作业实例分配一个从 0 到 25 的索引。 在代码中，使用以下模式将输入数据分发到作业实例。

   • 具有 JOB_INDEX=0 的作业实例处理以 A 或 a 开头的文件
   • 具有 JOB_INDEX=1 的作业实例处理以 B 或 b 开头的文件
   • 具有 JOB_INDEX=2 的作业实例处理以 C 或 c 开头的文件
   • [D ... y]
   • 具有 JOB_INDEX=25 的作业实例处理以 Z 或 z 开头的文件

   由于每个流都在处理多个文件，因此请将流的队列长度定义为单个流所处理的文件数。

2. 在 Code Engine中，创建作业及其配置。

   • 将作业数组下标指定为 0-25，这表示 26 个并行流。
   • 指定作业的 CPU 和内存资源，或者采用缺省值。 每个作业索引获取为作业指定的相同 CPU 和内存资源; 例如，1 vCPU 和 4 GB 内存。

3. 运行作业。 在 Code Engine 控制台中，可以查看暂挂，运行和完成的作业索引数。 当最后一个作业索引完成其运行时，该作业结束。

处理数据子集，并将工作动态分配给并行作业运行实例

假设您不希望限制为特定数量的并行实例。

在先前方案中，定义了 26 个并行流，提交的作业运行在定义的 26 个并行流中运行。

但是，假设您不希望限制为特定数量的并行实例，并且您希望运行将工作流动态分配给特定作业运行实例的作业。 在这种情况下，您可以使用 JOB_INDEX 和 JOB_ARRAY_SIZE 环境变量来派生确定要处理的工作流的值。 自动为作业注入 这些环境变量。

• JOB_INDEX 环境变量是特定作业运行实例的索引值。
• JOB_ARRAY_SIZE 环境变量指定要并行运行的作业实例数。 此值直接指定为作业运行数组大小，或者通过计算指定的数组下标来计算。

例如，假设您配置了 10 的数组大小，以便希望每个作业运行实例处理 10% 的总体数据 (10 个作业运行实例以并行方式运行)。 通过此配置设置，JOB_INDEX 环境变量将确定要处理的 10% 数据块中的哪个数据块，并且 JOB_ARRAY_SIZE 的计算值为 10。

但是，假定您要重新运行初始 10 个作业运行实例中的 3 个，因为它们先前已失败。 其他 70% 的数据已成功处理。 您希望在重新提交作业运行时指定特定的 3 失败索引。 假定您要重新运行索引 3，7 和 9。

对于此新作业运行，假设您仅更新数组下标; 例如，"3, 7, 9"。 因为 JOB_ARRAY_SIZE 环境变量的值是在指定数组下标而不是数组大小时自动计算的，所以 JOB_ARRAY_SIZE 的值现在是 3 而不是 10，因为指定了 3 个数组下标。

相反，为了确保作业运行提交 (或重新提交) 操作处理指定索引 3，7 和 9 的正确数据块，您可以通过在 CLI 中使用 --array-size-var-override 选项或通过在控制台中的 JOB_ARRAY_SIZE 输入字段中指定定制值来覆盖 JOB_ARRAY_SIZE 环境变量的自动计算值。

通过将定制数组大小覆盖值设置为 10，作业运行实例将块大小正确计算为 10%，并且重新提交的作业运行实例将处理所需数据 (索引 3，7 和 9)。 您可以使用此选项对仅提交或重新提交某些作业实例的作业重新运行方案强制实施常量数组大小值。

实现此作业运行方法后，可以动态增加或减少并行作业运行数。

与使用 JOB_INDEX 环境变量来定义作业运行工作流关系的分配方法相反，这种覆盖 JOB_ARRAY_SIZE 环境变量以动态分配工作流的方法更灵活，使您能够调整特定作业运行以满足您的需求。

运行并行批处理作业的优点

这种实现并行批处理作业的方法具有优势。

• 减少初始化-由于一个作业索引处理具有相似起始字符的文件，因此每个作业索引只需要一个初始化或连接设置。 与逐个文件初始化相比，此方法节省了资源和成本。 通过并行作业解决方案，有 26 个初始化，而不是 2000 个初始化。

• 高效资源使用-通过将任务划分为并行运行时间较长的流，此解决方案更高效地使用可用资源，同时将处理速度最大化。

规划并行批处理作业时的注意事项

在规划并行批处理作业解决方案时，请考虑以下几点。

• 平衡并行作业索引和队列长度-必须在流数 (并行作业索引) 和队列长度之间找到良好的平衡。 太少的作业索引无法完全使用可用资源，而太多的索引会增加初始化处理并增加云服务 (例如 Object Storage) 上的负载。 当您调用其他云服务时，此影响可能会导致速率限制。

• 类似的作业处理时间-在规划解决方案时，请考虑每个作业索引需要大约相同的时间来完成其任务。 避免出现一个作业索引比其他作业索引耗时长得多的情况，因为处理时间可能会导致资源使用效率低下，并增加作业处理时间。

• 使用多个作业-对于先前方案，另一种方法是使用多个作业。 这些多个作业不依赖于已配置的数组下标。 请改为考虑创建 2 批处理作业，一个用于以 A - Z 开头的文件，另一个用于以 a - z 开头的文件。 如果未对代码进行任何更改，那么可以根据您的处理需求和资源可用性来并行或按顺序触发这些 2 作业。

• 作业触发机制-您可以选择按特定时间间隔使用 cron 预订 来触发作业，也可以选择使用触发器应用程序来监视 Object Storage 存储区以获取新文件并根据需要启动批处理。 根据您的方案，您可以优化 Code Engine 用于成本效益与响应时间，以了解文件在写入存储区后的处理速度。