Best practice per i tentativi di ripetizione dei job e i checkpoint

Le singole attività dei job o persino le esecuzioni dei job possono non riuscire per vari motivi. Questa pagina contiene le best practice per gestire questi errori, incentrate su riavvii delle attività e controllo dei punti di controllo dei job.

Utilizzare i tentativi di attività

Le singole attività dei job possono non riuscire per diversi motivi, tra cui problemi con le dipendenze delle applicazioni, le quote o persino gli eventi di sistema interni. Spesso questi problemi sono temporanei e l'attività andrà a buon fine dopo un nuovo tentativo.

Per impostazione predefinita, ogni attività verrà riprovata automaticamente fino a tre volte. In questo modo, un job verrà eseguito fino al completamento anche se si verificano errori temporanei delle attività. Puoi anche personalizzare il numero massimo di tentativi. Tuttavia, se modifichi il valore predefinito, devi specificare almeno un nuovo tentativo.

Pianificare i riavvii delle attività dei job

Rendi i tuoi job idempotenti, in modo che il riavvio di un'attività non causi output corrotti o duplicati. In altre parole, scrivi una logica ripetibile che abbia lo stesso comportamento per un determinato insieme di input, indipendentemente dal numero di volte in cui viene ripetuta o da quando viene eseguita.

Scrivi l'output in una posizione diversa rispetto ai dati di input, lasciandoli invariati. In questo modo, se il job viene eseguito di nuovo, può ripetere la procedura 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 un danneggiamento dei dati a livello di raccolta.

Utilizzare i checkpoint

Se possibile, esegui il checkpoint dei job in modo che, se un'attività viene riavviata dopo un errore, possa riprendere da dove si era interrotta anziché riavviare il lavoro dall'inizio. In questo modo, velocizzerai i job e ridurrai al minimo i costi non necessari.

Scrivi periodicamente risultati parziali e un'indicazione dell'avanzamento in una collocazione di archiviazione permanente, come Cloud Storage o un database. Quando inizia l'attività, cerca risultati parziali all'avvio. Se vengono trovati risultati parziali, inizia l'elaborazione da dove si era interrotto.

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

Esempio 1 di controllo: calcolo del numero pi

Se hai un job che esegue un algoritmo ricorsivo, ad esempio il calcolo di Pi con molte cifre decimali, e utilizzi il parallelismo impostato su un valore pari a 1:

  • Scrivi i tuoi progressi ogni 10 minuti o in base alla tolleranza per i lavori persi consentita in un oggetto pi-progress.txt Cloud Storage.
  • Quando un'attività inizia, 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 oggetto denominato pi-complete.txt per evitare duplicazioni tramite esecuzione parallela o ripetuta o pi-complete-DATE.txt per distinguerli in base alla data di completamento.

Esempio 2 di controllo dei checkpoint: 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 di 100 in modo che il lavoro di elaborazione significativo non venga perso in caso di interruzione.
  • Quando vengono scritti i record, prendi nota di quelli che sono stati elaborati. Potresti aggiungere alla tabella una colonna booleana elaborata impostata su 1 solo se l'elaborazione è confermata.
  • Quando un'attività viene avviata, la query utilizzata per recuperare gli elementi da elaborare deve aggiungere la condizione elaborata = 0.
  • Oltre ai tentativi di nuovo senza errori, questa tecnica supporta anche la suddivisione del lavoro in attività più piccole, ad esempio modificando la query per selezionare 100 record alla volta: LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100 ed eseguendo 100 attività per elaborare tutti i 10.000 record. CLOUD_RUN_TASK_INDEX è una variabile di ambiente integrata presente all'interno del contenutore che esegue i job Cloud Run.

Se utilizzi tutti questi elementi insieme, la query finale potrebbe avere il seguente aspetto: SELECT * FROM example_table WHERE processed = 0 LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100

Passaggi successivi