使用作業處理高效處理許多文件

假設您有許多檔案儲存在 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 使用，以取得成本效率與回應時間，以瞭解在將檔案寫入儲存區之後處理檔案的速度。