Best practice per i nuovi tentativi di job e i checkpoint

Le singole attività dei job o persino le esecuzioni di job possono non riuscire per diversi 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 questo sono temporanei e l'attività avrà esito positivo dopo un nuovo tentativo.

Per impostazione predefinita, ogni attività verrà ritentata automaticamente fino a tre volte. Questo aiuta a garantire un job verrà eseguito fino al completamento anche se rileva errori temporanei dell'attività. Puoi anche personalizzare il numero massimo di tentativi. Tuttavia, se modifichi il valore predefinito, devi specificare almeno un nuovo tentativo.

Pianifica i riavvii delle attività di job

Rendi i tuoi job idempotenti, in modo che il riavvio di un'attività non causi output corrotti o duplicati. Ciò significa che scrivi una logica ripetibile che ha lo stesso comportamento per un determinato insieme di indipendentemente dal numero di ripetizioni o dall'esecuzione.

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 il processo. dall'inizio e ottenere lo stesso risultato.

Evita di duplicare i dati di output riutilizzando lo stesso identificatore univoco oppure per controllare 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 i risultati parziali vengono trovati, iniziare a elaborare dal punto in cui erano stati interrotti.

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 π

Se hai un job che esegue un algoritmo ricorsivo, come il calcolo di Pi molte posizioni decimali e usa 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 viene avviata un'attività, esegui una query sull'oggetto pi-progress.txt e carica il valore come un punto di partenza. Utilizza questo valore come input iniziale per la funzione.
  • Scrivi il risultato finale in Cloud Storage come oggetto denominato pi-complete.txt per evitare duplicati tramite esecuzione parallela o ripetuta 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 un job 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 i record vengono scritti, 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.

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

Passaggi successivi