Elaborare in modo efficiente molti file utilizzando l'elaborazione dei lavori

Supponi di avere molti file archiviati in un bucket IBM Cloud Object Storage e di voler utilizzare l'elaborazione batch in Code Engine. L'obiettivo è leggere i file da un bucket, manipolare i file e archiviarli in un bucket diverso Object Storage nel modo più efficace. Supponiamo che tu abbia 2000 file nel bucket di input ogni giorno. Tutti i file hanno un nome diverso e i nomi dei file iniziano con un carattere alfabetico (A-Z, a - z).

Quando si pianifica una soluzione per questo scenario, si pensa prima a una soluzione basata sull'evento. In questo caso, per ogni file scritto nel bucket di input Object Storage, viene creato un evento e viene richiamata un'applicazione Code Engine. Utilizzando gli eventi, un singolo file potrebbe attivare l'elaborazione individuale, che può essere inefficiente per molti file.

L'esecuzione di un lavoro batch può essere un approccio migliore? Sì che può! Vediamo perché i lavori batch sono più adatti per la gestione di più file insieme.

1. Determinare un approccio per dividere la serie di file in flussi paralleli. Dividiamo i file in base al primo carattere del nome file. Con questo approccio, è possibile avere 26 flussi, con ogni flusso responsabile per i file che inizia con un carattere specifico. È possibile identificare un flusso specifico leggendo la variabile d'ambiente JOB_INDEX inserita automaticamente di una istanza di lavoro in esecuzione. Consultare Variabili di ambiente inserite automaticamente per i lavori. Per questo esempio, è possibile configurare le istanze del lavoro specificando il numero di istanze come 26 o gli indici di array come 0-25.

   A ogni istanza di processo in esecuzione viene assegnato un indice compreso tra 0 e 25. Nel codice, utilizzare il modello seguente per distribuire i dati di input alle istanze di job.

   • istanza lavoro con JOB_INDEX=0 funziona su file che iniziano con A o a
   • L'istanza di lavoro con JOB_INDEX=1 funziona sui file che iniziano con B o b
   • istanza di lavoro con JOB_INDEX=2 funziona su file che iniziano con C o c
   • [D ... y]
   • istanza di lavoro con JOB_INDEX=25 funziona su file che iniziano con Z o z

   Poiché ogni flusso sta elaborando più file, definire la lunghezza della coda di un flusso come il numero di file elaborati dal singolo flusso.

2. In Code Engine, crea il lavoro e la relativa configurazione.

   • Specificare gli indici dell'array del lavoro come 0-25, che rappresenta 26 flussi paralleli.
   • Specificare la CPU e le risorse di memoria per il proprio lavoro oppure utilizzare i valori predefiniti. Ogni indice del lavoro ottiene le stesse risorse di CPU e memoria specificate per il lavoro; ad esempio, 1 vCPU e 4 GB di memoria.

3. Esegui il lavoro. Nella console Code Engine, puoi vedere il numero di indici di job in sospeso, in esecuzione e completati. Il lavoro termina quando l'ultimo indice del lavoro completa l'esecuzione.

Elaborare un sottoinsieme di dati e assegnare dinamicamente il lavoro alle istanze di esecuzione dei lavori in parallelo

Si supponga di non voler essere limitati a un determinato numero di istanze parallele.

Nello scenario precedente, sono stati definiti 26 flussi paralleli e le esecuzioni del lavoro inoltrate sono state eseguite nei 26 flussi paralleli definiti.

Tuttavia, si supponga di non voler essere limitati a un determinato numero di istanze parallele e di voler eseguire un job che assegna dinamicamente i flussi di lavoro a una determinata istanza di esecuzione del job. In questo caso, è possibile utilizzare sia le variabili di ambiente JOB_INDEX che JOB_ARRAY_SIZE per derivare un valore che determina quale flusso di lavoro viene elaborato. Queste variabili di ambiente vengono inserite automaticamente per i lavori.

• La variabile di ambiente JOB_INDEX è il valore dell'indice di una specifica istanza di esecuzione lavoro.
• La variabile di ambiente JOB_ARRAY_SIZE specifica il numero di istanze di lavori da eseguire in parallelo. Questo valore viene specificato direttamente come dimensione della schiera di esecuzione del lavoro o calcolato contando gli indici della schiera specificati.

Ad esempio, si supponga di aver configurato una dimensione di array di 10 in modo che ogni istanza di esecuzione lavoro funzioni sul 10% dei dati globali (10 istanze di esecuzione lavoro eseguite in parallelo). Con questa impostazione di configurazione, la variabile d'ambiente JOB_INDEX determina quale dei 10% di dati viene utilizzato e il valore calcolato per JOB_ARRAY_SIZE è 10.

Tuttavia, si supponga di voler eseguire di nuovo 3 delle 10 istanze di esecuzione del lavoro iniziali perché in precedenza non sono riuscite. Il restante 70% dei dati è stato elaborato correttamente. Si desidera specificare i 3 indici in errore quando si inoltra nuovamente l'esecuzione del job. Si supponga di voler rieseguire gli indici 3, 7 e 9.

Per questa nuova esecuzione del lavoro, si supponga di aggiornare solo gli indici di array; ad esempio "3, 7, 9". Poiché il valore della variabile di ambiente JOB_ARRAY_SIZE viene automaticamente calcolato quando vengono specificati gli indici dell'array invece della dimensione dell'array, il valore di JOB_ARRAY_SIZE è ora 3 invece di 10, poiché sono stati specificati 3 indici dell'array.

Invece, per essere certi che l'azione di inoltro (o reinoltro) dell'esecuzione del lavoro elabori i blocchi di dati corretti per gli indici specificati 3, 7 e 9, è possibile sovrascrivere il valore calcolato automaticamente della variabile di ambiente JOB_ARRAY_SIZE utilizzando l'opzione --array-size-var-override nella CLI o specificando un valore personalizzato nel campo di input JOB_ARRAY_SIZE nella console.

Impostando il valore di override della dimensione dell'array personalizzato a 10, le istanze di esecuzione del lavoro calcolano correttamente la dimensione del chunk come 10% e le istanze di esecuzione del lavoro ripresentate elaborano i dati desiderati (indici 3, 7 e 9). È possibile utilizzare questa opzione per applicare un valore di dimensione array costante per gli scenari di riesecuzione del lavoro, in cui vengono inoltrate o reinoltrate solo alcune istanze del lavoro.

Dopo aver implementato questo approccio di esecuzione del job, è possibile aumentare o diminuire in modo dinamico il numero di esecuzioni di job paralleli.

A differenza dell'approccio di assegnazione dell'utilizzo della variabile di ambiente JOB_INDEX per definire la relazione del flusso di lavoro di esecuzione lavoro, questo metodo di sovrascrittura della variabile di ambiente JOB_ARRAY_SIZE per assegnare dinamicamente i flussi di lavoro è più flessibile e consente di adattare una particolare esecuzione del lavoro in base alle proprie esigenze.

Vantaggi dell'esecuzione di lavori batch paralleli

Questo approccio di implementazione dei job batch paralleli offre vantaggi.

• Inizializzazione ridotta - Poiché un indice di lavoro elabora i file con caratteri iniziali simili, è richiesta una sola inizializzazione o configurazione di connessione per indice di lavoro. Questo approccio consente di risparmiare risorse e costi se confrontato con l'inizializzazione individuale per file. Con la soluzione del job parallelo, ci sono 26 inizializzazioni invece di 2000.

• Utilizzo efficiente delle risorse - Dizionando l'attività in flussi di esecuzione paralleli più lunghi, questa soluzione utilizza le risorse disponibili in modo più efficiente, mentre la velocità di elaborazione è massimizzata.

Considerazioni sulla pianificazione di job batch paralleli

Considerare i seguenti punti quando si pianificano soluzioni di job batch paralleli.

• Bilanciamento degli indici dei job paralleli e della lunghezza della coda - È essenziale trovare un buon equilibrio tra il numero di flussi (indici dei job paralleli) e la lunghezza della coda. Un numero troppo basso di indici del lavoro non può utilizzare completamente le risorse disponibili, mentre un numero troppo elevato di indici può aumentare l'elaborazione dell'inizializzazione e il carico sui servizi cloud, come Object Storage. Questo effetto può causare limiti di velocità quando si richiamano altri servizi cloud.

• Tempo di elaborazione lavoro simile - Quando si pianifica la propria soluzione, considerare che ogni indice lavoro impiega circa lo stesso tempo per completare la propria attività. Evitare scenari in cui un indice del lavoro impiega molto più tempo di altri, poiché il tempo di elaborazione potrebbe causare inefficienze nell'utilizzo delle risorse e aumentare il tempo di elaborazione del lavoro.

• Utilizzo di più lavori - Per lo scenario precedente, un approccio diverso consiste nell'utilizzare più lavori. Questi lavori multipli non si basano su indici di array configurati. Si consiglia, invece, di creare 2 lavori batch, uno per i file che iniziano con A - Z e un altro per i file che iniziano con a - z. Senza alcuna modifica al codice, è possibile attivare questi 2 job sia in parallelo che in sequenza, in base ai requisiti di elaborazione e alla disponibilità delle risorse.

• Meccanismo di attivazione del lavoro - Puoi scegliere di attivare il lavoro con una sottoscrizione cron a intervalli specifici o con un'applicazione trigger che monitora il bucket Object Storage per nuovi file e avvia l'elaborazione batch come necessario. A seconda del tuo scenario, puoi ottimizzare l'utilizzo di Code Engine per l'efficienza dei costi rispetto al tempo di risposta per la velocità con cui i file vengono elaborati dopo essere stati scritti nel bucket.