Best practice per nuovi tentativi di job e checkpoint

Le singole attività dei job o anche l'esecuzione dei job possono non riuscire per diversi motivi. Questa pagina contiene le best practice per la gestione di questi errori, incentrate sui riavvii delle attività e sui checkpoint dei job.

Pianifica i riavvii delle attività del job

Rendi i job idempotenti in modo che il riavvio dell'attività non comporti output danneggiato o duplicato. In altre parole, scrivi una logica ripetibile che abbia lo stesso comportamento per un determinato insieme di input, indipendentemente da quante volte viene ripetuto o quando viene eseguito.

Scrivi l'output in una posizione diversa rispetto ai dati di input, lasciando intatti i dati di input. In questo modo, se il job viene eseguito di nuovo, può ripeterlo dall'inizio e ottenere lo stesso risultato.

Evita di duplicare i dati di output riutilizzando lo stesso identificatore univoco o controllando se l'output esiste già. I dati duplicati rappresentano danni dei dati a livello di raccolta.

Utilizza checkpointing

Se possibile, controlla i job in modo che, se un'attività si riavvia dopo un errore, possa riprendere da dove si era interrotta, anziché riavviare il lavoro all'inizio. In questo modo, i job saranno più veloci e i costi inutili saranno ridotti.

Scrivi periodicamente risultati parziali e indicazioni dell'avanzamento in una posizione di archiviazione permanente, come Cloud Storage o un database. All'avvio dell'attività, cerca risultati parziali all'avvio. Se vengono trovati risultati parziali, inizia l'elaborazione dal punto in cui erano stati interrotti.

Se il tuo job non si presta al checkpoint, valuta la possibilità di suddividerlo in blocchi più piccoli ed eseguire un numero maggiore di attività.

Esempio di checkpoint 1: calcolo di Pi greco

Se hai un job che esegue un algoritmo ricorsivo, come il calcolo di Pi su più cifre decimali, e utilizza il parallelismo impostato su 1:

  • Scrivi i tuoi progressi ogni 10 minuti o qualsiasi cosa consenta la tolleranza relativa al lavoro perso, in un oggetto Cloud Storage pi-progress.txt.
  • Quando viene avviata un'attività, esegui una query sull'oggetto pi-progress.txt e carica il valore come punto di partenza. Utilizza questo valore come input iniziale della funzione.
  • Scrivi il risultato finale in Cloud Storage come un oggetto denominato pi-complete.txt per evitare la duplicazione tramite esecuzioni parallele o ripetute oppure pi-complete-DATE.txt per differenziare in base alla data di completamento.

Esempio di checkpoint 2: elaborazione di 10.000 record da Cloud SQL

Se hai un job che elabora 10.000 record in un database relazionale come Cloud SQL:

  • Recupera i record da elaborare con una query SQL come SELECT * FROM example_table LIMIT 10000
  • Scrivi i record aggiornati in batch da 100 in modo che il lavoro di elaborazione significativo non vada perso in caso di interruzione.
  • Quando vengono scritti i record, prendi nota di quali sono stati elaborati. Puoi aggiungere una colonna booleana elaborata alla tabella che è impostata su 1 solo se l'elaborazione è confermata.
  • Quando un'attività viene avviata, la query utilizzata per recuperare gli elementi per l'elaborazione deve aggiungere la condizione elaborata = 0.
  • Oltre ai nuovi tentativi puliti, questa tecnica supporta anche la suddivisione del lavoro in attività più piccole, ad esempio modificando la query in modo da selezionare 100 record alla volta (LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100) ed eseguire 100 attività per elaborare tutti i 10.000 record. CLOUD_RUN_TASK_INDEX è una variabile di ambiente integrata presente all'interno del container che esegue job Cloud Run.

Utilizzando tutti questi elementi insieme, la query finale potrebbe essere la seguente: SELECT * FROM example_table WHERE processed = 0 LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100

Passaggi successivi