Risolvere gli errori di Dataflow

Se riscontri problemi con la pipeline o il job Dataflow, questa pagina elenca i messaggi di errore che potresti visualizzare e fornisce suggerimenti su come correggere ciascun errore.

Gli errori nei tipi di log dataflow.googleapis.com/worker-startup, dataflow.googleapis.com/harness-startup e dataflow.googleapis.com/kubelet indicano problemi di configurazione di un job. Possono inoltre indicare condizioni che impediscono il funzionamento del normale percorso di logging.

La pipeline potrebbe generare eccezioni durante l'elaborazione dei dati. Alcuni di questi errori sono temporanei, ad esempio quando si verificano problemi temporanei di accesso a un servizio esterno. Alcuni di questi errori sono permanenti, come errori causati da dati di input corrotti o non analizzabili oppure puntatori nulli durante il calcolo.

Dataflow elabora gli elementi in bundle arbitrari e riprova il bundle completo quando viene generato un errore per qualsiasi elemento del bundle. Durante l'esecuzione in modalità batch, i bundle che includono un elemento con errore vengono ripetuti quattro volte. La pipeline non funziona completamente quando un singolo bundle si arresta per quattro volte. Durante l'esecuzione in modalità flusso, un bundle che include un elemento che presenta errori viene ritentato a tempo indeterminato, il che potrebbe causare l'arresto permanente della pipeline.

Le eccezioni nel codice utente, ad esempio le istanze DoFn, sono segnalate nell'interfaccia di monitoraggio di Dataflow. Se esegui la pipeline con BlockingDataflowPipelineRunner, vedrai anche messaggi di errore stampati nella console o nella finestra del terminale.

Valuta la possibilità di evitare errori nel codice aggiungendo gestori delle eccezioni. Ad esempio, se vuoi rilasciare elementi che non superano la convalida di un input personalizzato in un ParDo, utilizza un blocco generate/catch all'interno di ParDo per gestire l'eccezione, quindi registra e rilascia l'elemento. Per i carichi di lavoro di produzione, implementa un pattern di messaggi non elaborato. Per monitorare il numero di errori, utilizza le trasformazioni di aggregazione.

File di log mancanti

Se non vedi log per i tuoi job, rimuovi eventuali filtri di esclusione contenenti resource.type="dataflow_step" da tutti i sink del router dei log di Cloud Logging.

Vai al router dei log

Per ulteriori dettagli sulla rimozione delle esclusioni dei log, consulta la guida Rimozione delle esclusioni.

Errori di pipeline

Le seguenti sezioni contengono errori comuni della pipeline che potresti riscontrare e i passaggi per risolverli o per risolverli.

Alcune API Cloud devono essere abilitate

Quando provi a eseguire un job Dataflow, si verifica il seguente errore:

Some Cloud APIs need to be enabled for your project in order for Cloud Dataflow to run this job.

Questo problema si verifica perché alcune API richieste non sono abilitate nel tuo progetto.

Per risolvere il problema ed eseguire un job Dataflow, abilita le seguenti API Google Cloud nel progetto:

  • API Compute Engine (Compute Engine)
  • API Cloud Logging
  • Cloud Storage
  • API Cloud Storage JSON
  • API BigQuery
  • Pub/Sub
  • API Datastore

Per istruzioni dettagliate, consulta la sezione Guida introduttiva sull'abilitazione delle API Google Cloud.

"@*" e "@N" sono specifiche di sharding riservate

Quando provi a eseguire un job, nei file di log viene visualizzato il seguente errore e il job non riesce:

Workflow failed. Causes: "@*" and "@N" are reserved sharding specs. Filepattern must not contain any of them.

Questo errore si verifica se il nome del file del percorso Cloud Storage dei file temporanei (tempLocation o temp_location) presenta il simbolo della chiocciola (@) seguito da un numero o da un asterisco (*).

Per risolvere il problema, modifica il nome del file in modo che il segno @ sia seguito da un carattere supportato.

Richiesta errata

Quando esegui un job Dataflow, i log di Cloud Monitoring visualizzano una serie di avvisi simili ai seguenti:

Unable to update setup work item STEP_ID error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id LEASE_ID
with expiration time: TIMESTAMP, now: TIMESTAMP. Full status: generic::invalid_argument: Http(400) Bad Request

Se le informazioni sullo stato dei worker sono obsolete o non sincronizzate a causa di ritardi nell'elaborazione, si verificano avvisi relativi a richieste errate. Spesso, il job Dataflow ha esito positivo nonostante gli avvisi di richieste errate. In questo caso, ignora gli avvisi.

Impossibile leggere e scrivere in località diverse

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei file di log:

message:Cannot read and write in different locations: source: SOURCE_REGION, destination: DESTINATION_REGION,reason:invalid

Questo errore si verifica quando l'origine e la destinazione si trovano in regioni diverse. Può verificarsi anche quando la località temporanea e la destinazione si trovano in regioni diverse. Ad esempio, se il job legge da Pub/Sub e poi scrive in un bucket temp di Cloud Storage prima di scrivere in una tabella BigQuery, il bucket temp di Cloud Storage e la tabella BigQuery devono trovarsi nella stessa regione.

Le località che comprendono più regioni sono considerate diverse da quelle di una singola regione, anche se la singola regione rientra nell'ambito di quella che comprende più regioni. Ad esempio, us (multiple regions in the United States) e us-central1 sono regioni diverse.

Per risolvere il problema, fai in modo che le posizioni di destinazione, di origine e di gestione temporanea si trovino nella stessa regione. Le località dei bucket Cloud Storage non possono essere modificate, pertanto potrebbe essere necessario creare un nuovo bucket Cloud Storage nella regione corretta.

Timeout della connessione

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei file di log:

org.springframework.web.client.ResourceAccessException: I/O error on GET request for CONNECTION_PATH: Connection timed out (Connection timed out); nested exception is java.net.ConnectException: Connection timed out (Connection timed out)

Questo problema si verifica quando i worker Dataflow non riescono a stabilire o mantenere una connessione con l'origine dati o la destinazione.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

  • Verifica che l'origine dati sia in esecuzione.
  • Verifica che la destinazione sia in esecuzione.
  • Esamina i parametri di connessione utilizzati nella configurazione della pipeline Dataflow.
  • Verifica che i problemi di prestazioni non influiscano sull'origine o sulla destinazione.
  • Assicurati che le regole firewall non blocchino la connessione.

Oggetto non trovato

Quando esegui i job Dataflow, potresti visualizzare il seguente errore nei file di log:

..., 'server': 'UploadServer', 'status': '404'}>, <content <No such object:...

In genere, questi errori si verificano quando alcuni job Dataflow in esecuzione utilizzano lo stesso temp_location per inserire i file temporanei dei job creati durante l'esecuzione della pipeline. Quando più job simultanei condividono lo stesso temp_location, questi job potrebbero bloccare i dati temporanei l'uno dell'altro e potrebbe verificarsi una race condition. Per evitare questo problema, ti consigliamo di utilizzare un valore temp_location univoco per ogni job.

Dataflow non è in grado di determinare il backlog

Quando si esegue una pipeline in modalità flusso da Pub/Sub, si verifica il seguente avviso:

Dataflow is unable to determine the backlog for Pub/Sub subscription

Quando una pipeline Dataflow estrae i dati da Pub/Sub, Dataflow deve richiedere ripetutamente informazioni a Pub/Sub. Queste informazioni includono la quantità di backlog della sottoscrizione e l'età del messaggio non confermato meno recente. A volte, Dataflow non è in grado di recuperare queste informazioni da Pub/Sub a causa di problemi interni del sistema, che potrebbero causare un accumulo temporaneo di backlog.

Per ulteriori informazioni, consulta Streaming con Cloud Pub/Sub.

DEADLINE_EXCEEDED o il server non risponde

Quando esegui i job, potresti riscontrare eccezioni di timeout RPC o uno dei seguenti errori:

DEADLINE_EXCEEDED

Oppure:

Server Unresponsive

In genere questi errori si verificano per uno dei seguenti motivi:

  • Nella rete Virtual Private Cloud (VPC) utilizzata per il job potrebbe mancare una regola firewall. La regola firewall deve abilitare tutto il traffico TCP tra le VM nella rete VPC specificata nelle opzioni della pipeline. Per maggiori informazioni, consulta Regole firewall per Dataflow.

    In alcuni casi, i worker non sono in grado di comunicare tra loro. Quando esegui un job Dataflow che non utilizza Dataflow Shuffle o Streaming Engine, i worker devono comunicare tra loro utilizzando le porte TCP 12345 e 12346 all'interno della rete VPC. In questo scenario, l'errore include il nome del cablaggio del worker e la porta TCP bloccata. L'errore è simile a uno dei seguenti esempi:

    DEADLINE_EXCEEDED: (g)RPC timed out when SOURCE_WORKER_HARNESS
    talking to DESTINATION_WORKER_HARNESS:12346.
    
    Rpc to WORKER_HARNESS:12345 completed with error UNAVAILABLE: failed to connect to all addresses
    Server unresponsive (ping error: Deadline Exceeded, UNKNOWN: Deadline Exceeded...)
    

    Per risolvere il problema, utilizza il flag gcloud compute firewall-rules create regole per consentire il traffico di rete alle porte 12345 e 12346. L'esempio seguente illustra il comando Google Cloud CLI:

    gcloud compute firewall-rules create FIREWALL_RULE_NAME \
      --network NETWORK \
      --action allow \
      --direction IN \
      --target-tags dataflow \
      --source-tags dataflow \
      --priority 0 \
      --rules tcp:12345-12346
    

    Sostituisci quanto segue:

    • FIREWALL_RULE_NAME: il nome della regola firewall
    • NETWORK: il nome della tua rete
  • Il job è limitato tramite shuffling.

    Per risolvere il problema, apporta una o più delle seguenti modifiche.

    Java

    • Se il job non utilizza lo shuffling basato sui servizi, passa all'utilizzo dello Dataflow Shuffle basato sui servizi impostando il valore --experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow shuffling.
    • Aggiungi altri worker. Prova a impostare --numWorkers con un valore più alto quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --diskSizeGb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --workerDiskType="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

    Python

    • Se il job non utilizza lo shuffling basato sui servizi, passa all'utilizzo dello Dataflow Shuffle basato sui servizi impostando il valore --experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow shuffling.
    • Aggiungi altri worker. Prova a impostare --num_workers con un valore più alto quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --disk_size_gb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --worker_disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

    Go

    • Se il job non utilizza lo shuffling basato sui servizi, passa all'utilizzo dello Dataflow Shuffle basato sui servizi impostando il valore --experiments=shuffle_mode=service. Per dettagli e disponibilità, consulta Dataflow shuffling.
    • Aggiungi altri worker. Prova a impostare --num_workers con un valore più alto quando esegui la pipeline.
    • Aumenta le dimensioni del disco collegato per i worker. Prova a impostare --disk_size_gb con un valore più alto quando esegui la pipeline.
    • Utilizza un disco permanente supportato da SSD. Prova a impostare --disk_type="compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/diskTypes/pd-ssd" quando esegui la pipeline.

Errori di codifica, IOEccezioni o comportamenti imprevisti nel codice utente

Gli SDK Apache Beam e i worker di Dataflow dipendono da componenti comuni di terze parti. Questi componenti importano dipendenze aggiuntive. Le collisioni di versione possono causare comportamenti imprevisti nel servizio. Inoltre, alcune librerie non sono compatibili con l'inoltro. Potresti dover bloccare le versioni elencate che rientrano nell'ambito durante l'esecuzione. SDK e dipendenze worker contengono un elenco di dipendenze e le versioni richieste.

Errore durante l'esecuzione di LookupEffectiveGuestPolicies

Quando esegui un job Dataflow, potresti visualizzare il seguente errore nei file di log:

OSConfigAgent Error policies.go:49: Error running LookupEffectiveGuestPolicies:
error calling LookupEffectiveGuestPolicies: code: "Unauthenticated",
message: "Request is missing required authentication credential.
Expected OAuth 2 access token, login cookie or other valid authentication credential.

Questo errore si verifica se OS Configuration Management è abilitato per l'intero progetto.

Per risolvere il problema, disabilita i criteri di VM Manager applicabili all'intero progetto. Se non è possibile disabilitare i criteri di VM Manager per l'intero progetto, puoi tranquillamente ignorare questo errore e filtrarlo dagli strumenti di monitoraggio dei log.

Pool di risorse esaurite

Quando crei una risorsa Google Cloud, potresti visualizzare il seguente errore per un pool di risorse esaurito:

ERROR: ZONE_RESOURCE_POOL_EXHAUSTED

Questo errore si verifica per condizioni temporanee di esaurimento scorte per una risorsa specifica in una zona specifica.

Per risolvere il problema, puoi attendere o creare la stessa risorsa in un'altra zona. Come best practice, ti consigliamo di distribuire le risorse in più zone e regioni per tollerare eventuali interruzioni.

Java Runtime Environment ha rilevato un errore irreversibile

Durante l'avvio del worker si è verificato il seguente errore:

A fatal error has been detected by the Java Runtime Environment

Questo errore si verifica se la pipeline utilizza Java Native Interface (JNI) per eseguire codice non Java e il codice o le associazioni JNI contengono un errore.

Errore chiave attributo googclient_deliveryattempt

Il job Dataflow ha esito negativo con uno dei seguenti errori:

The request contains an attribute key that is not valid (key=googclient_deliveryattempt). Attribute keys must be non-empty and must not begin with 'goog' (case-insensitive).

Oppure:

Invalid extensions name: googclient_deliveryattempt

Questo errore si verifica quando il job Dataflow ha le seguenti caratteristiche:

Questo errore si verifica perché quando utilizzi la libreria client Pub/Sub Java o C# e viene attivato un argomento messaggi non recapitabili per una sottoscrizione, i tentativi di consegna si trovano nell'attributo del messaggio googclient_deliveryattempt anziché nel campo delivery_attempt. Per maggiori informazioni, consulta Monitorare i tentativi di consegna nella pagina "Gestire gli errori relativi ai messaggi".

Per risolvere questo problema, apporta una o più delle seguenti modifiche.

È stato rilevato un tasto di scelta rapida ...

Si verifica il seguente errore:

A hot key HOT_KEY_NAME was detected in...

Questi errori si verificano se i dati contengono un tasto di scelta rapida. Un tasto di scelta rapida è una chiave con elementi sufficienti a influire negativamente sulle prestazioni della pipeline. Queste chiavi limitano la capacità di Dataflow di elaborare gli elementi in parallelo, il che aumenta il tempo di esecuzione.

Per stampare la chiave leggibile dai log quando viene rilevato un tasto di scelta rapida nella pipeline, utilizza l'opzione pipeline del tasto di scelta rapida.

Per risolvere questo problema, verifica che i dati siano distribuiti uniformemente. Se una chiave ha molti valori sproporzionatamente, prendi in considerazione le seguenti azioni:

Per visualizzare le chiavi di accesso nell'interfaccia di monitoraggio di Dataflow, consulta Risolvere i problemi relativi agli elementi in ritardo nei job batch.

Specifica della tabella non valida in Data Catalog

Quando utilizzi Dataflow SQL per creare job SQL di Dataflow, il job potrebbe non riuscire e generare il seguente errore nei file di log:

Invalid table specification in Data Catalog: Could not resolve table in Data Catalog

Questo errore si verifica se l'account di servizio Dataflow non ha accesso all'API Data Catalog.

Per risolvere il problema, abilita l'API Data Catalog nel progetto Google Cloud che stai utilizzando per scrivere ed eseguire query.

In alternativa, assegna il ruolo roles/datacatalog.viewer all'account di servizio Dataflow.

Il grafico del job è troppo grande

Il job potrebbe non riuscire con il seguente errore:

The job graph is too large. Please try again with a smaller job graph,
or split your job into two or more smaller jobs.

Questo errore si verifica se le dimensioni del grafico del job superano i 10 MB. Determinate condizioni nella pipeline possono causare il superamento del limite da parte del grafico del job. Le condizioni più comuni sono:

  • Una trasformazione Create che include una grande quantità di dati in memoria.
  • Un'istanza DoFn di grandi dimensioni, serializzata per la trasmissione ai lavoratori remoti.
  • Un DoFn come istanza anonima di classe interna che (possibilmente inavvertitamente) estrae una grande quantità di dati da serializzare.
  • Un grafo diretto aciclico (DAG) viene utilizzato come parte di un loop programmatico che enumera un elenco lungo.

Per evitare queste condizioni, valuta la possibilità di ristrutturare la pipeline.

Commit della chiave troppo grande

Quando si esegue un job di inserimento di flussi, nei file di log dei worker viene visualizzato il seguente errore:

KeyCommitTooLargeException

Questo errore si verifica negli scenari di inserimento di flussi se viene raggruppate una quantità molto elevata di dati senza utilizzare una trasformazione Combine o se viene prodotta una grande quantità di dati da un singolo elemento di input.

Per ridurre le probabilità che si verifichi questo errore, utilizza le seguenti strategie:

  • Assicurati che l'elaborazione di un singolo elemento non possa generare output o modifiche dello stato che superino il limite.
  • Se più elementi sono stati raggruppati in base a una chiave, ti consigliamo di aumentare lo spazio delle chiavi in modo da ridurre gli elementi raggruppati per chiave.
  • Se gli elementi di una chiave vengono emessi ad alta frequenza in un breve periodo di tempo, nelle finestre potrebbero essere generati molti GB di eventi per quella chiave. Riscrivi la pipeline per rilevare chiavi come questa ed emettere solo un output che indica che la chiave era spesso presente in quella finestra.
  • Utilizza le trasformazioni dello spazio sublineare Combine per le operazioni commutative e associate. Non utilizzare un combinatore se non riduce lo spazio. Ad esempio, il combinatore di stringhe che unisce le stringhe è peggio di non utilizzarlo.

Rifiuto messaggio superiore a 7168.000 messaggi

Quando esegui un job Dataflow creato da un modello, il job potrebbe non riuscire e generare il seguente errore:

Error: CommitWork failed: status: APPLICATION_ERROR(3): Pubsub publish requests are limited to 10MB, rejecting message over 7168K (size MESSAGE_SIZE) to avoid exceeding limit with byte64 request encoding.

Questo errore si verifica quando i messaggi scritti in una coda di messaggi non recapitabili superano il limite delle dimensioni di 7168 kB. Come soluzione alternativa, abilita Streaming Engine, che ha un limite di dimensioni superiore. Per abilitare Streaming Engine, utilizza la seguente opzione pipeline.

Java

--enableStreamingEngine=true

Python

--enable_streaming_engine=true

Request Entity Too Large (Dimensioni dell'entità richiesta eccessive)

Quando invii il job, nella console o nella finestra del terminale viene visualizzato uno dei seguenti errori:

413 Request Entity Too Large
The size of serialized JSON representation of the pipeline exceeds the allowable limit
Failed to create a workflow job: Invalid JSON payload received
Failed to create a workflow job: Request payload exceeds the allowable limit

Quando si verifica un errore relativo al payload JSON durante l'invio del job, la rappresentazione JSON della pipeline supera le dimensioni massime delle richieste di 20 MB.

Le dimensioni del job sono legate alla rappresentazione JSON della pipeline. Una pipeline più grande indica una richiesta più grande. Dataflow ha un limite che limita le richieste a 20 MB.

Per stimare le dimensioni della richiesta JSON della pipeline, eseguila con questa opzione:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Go

L'output del job come JSON non è supportato in Go.

Questo comando scrive una rappresentazione JSON del job in un file. Le dimensioni del file serializzato sono una buona stima delle dimensioni della richiesta. Le dimensioni effettive sono leggermente maggiori per via di alcune informazioni aggiuntive incluse nella richiesta.

Determinate condizioni della pipeline possono causare il superamento del limite da parte della rappresentazione JSON. Le condizioni più comuni includono:

  • Una trasformazione Create che include una grande quantità di dati in memoria.
  • Un'istanza DoFn di grandi dimensioni, serializzata per la trasmissione ai lavoratori remoti.
  • Un DoFn come istanza anonima di classe interna che (possibilmente inavvertitamente) estrae una grande quantità di dati da serializzare.

Per evitare queste condizioni, valuta la possibilità di ristrutturare la pipeline.

Le opzioni della pipeline dell'SDK o l'elenco dei file di gestione temporanea superano il limite di dimensioni

Durante l'esecuzione di una pipeline, si verifica uno dei seguenti errori:

SDK pipeline options or staging file list exceeds size limit.
Please keep their length under 256K Bytes each and 512K Bytes in total.

Oppure:

Value for field 'resource.properties.metadata' is too large: maximum size

Questi errori si verificano se non è stato possibile avviare la pipeline a causa del superamento dei limiti di metadati di Compute Engine. Questi limiti non possono essere modificati. Dataflow utilizza i metadati di Compute Engine per le opzioni delle pipeline. Il limite è documentato nelle limitazioni dei metadati personalizzati di Compute Engine.

I seguenti scenari possono causare il superamento del limite della rappresentazione JSON:

  • Troppi file JAR da gestire.
  • Il campo di richiesta sdkPipelineOptions è troppo grande.

Per stimare le dimensioni della richiesta JSON della pipeline, eseguila con questa opzione:

Java

--dataflowJobFile=PATH_TO_OUTPUT_FILE

Python

--dataflow_job_file=PATH_TO_OUTPUT_FILE

Go

L'output del job come JSON non è supportato in Go.

Le dimensioni del file di output da questo comando devono essere inferiori a 256 kB. I 512 kB nel messaggio di errore si riferiscono alla dimensione totale del file di output e alle opzioni di metadati personalizzati per l'istanza VM di Compute Engine.

Puoi ottenere una stima approssimativa dell'opzione dei metadati personalizzati per l'istanza VM dall'esecuzione dei job Dataflow nel progetto. Scegli un job Dataflow in esecuzione. Acquisisci un'istanza VM, quindi vai alla pagina dei dettagli dell'istanza VM di Compute Engine per quella VM per verificare la sezione dei metadati personalizzati. La lunghezza totale dei metadati personalizzati e del file deve essere inferiore a 512 kB. Non è possibile ottenere una stima accurata per i job non riusciti, perché le VM non vengono ruotate per i job non riusciti.

Se il tuo elenco JAR raggiunge il limite di 256 kB, controllalo e riduci eventuali file JAR non necessari. Se è ancora troppo grande, prova a eseguire il job Dataflow utilizzando un JAR Uber. Per un esempio che illustra come creare e utilizzare Uber JAR, consulta Creare ed eseguire il deployment di un JAR Uber.

Se il campo di richiesta sdkPipelineOptions è troppo grande, includi la seguente opzione quando esegui la pipeline. L'opzione della pipeline è la stessa per Java, Python e Go.

--experiments=no_display_data_on_gce_metadata

Tasto di riproduzione casuale troppo grande

Nei file di log dei worker viene visualizzato il seguente errore:

Shuffle key too large

Questo errore si verifica se la chiave serializzata emessa in un particolare (Co-)GroupByKey è troppo grande dopo l'applicazione del programmatore corrispondente. Dataflow ha un limite per le chiavi shuffle serializzate.

Per risolvere il problema, riduci le dimensioni delle chiavi o utilizza codificatori più efficienti in termini di spazio.

Il numero totale di oggetti BoundedSource ... è superiore al limite consentito

Durante l'esecuzione di job con Java potrebbe verificarsi uno dei seguenti errori:

Total number of BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

Oppure:

Total size of the BoundedSource objects generated by splitIntoBundles() operation is larger than the allowable limit

Java

Questo errore può verificarsi se leggi da un numero molto elevato di file utilizzando TextIO, AvroIO, BigQueryIO tramite EXPORT o qualche altra origine basata su file. Il limite specifico dipende dai dettagli dell'origine, ma è dell'ordine delle decine di migliaia di file in una pipeline. Ad esempio, lo schema di incorporamento in AvroIO.Read consente meno file.

Questo errore può verificarsi anche se hai creato un'origine dati personalizzata per la tua pipeline e il metodo splitIntoBundles dell'origine ha restituito un elenco di oggetti BoundedSource che occupa più di 20 MB quando è in serie.

Il limite consentito per la dimensione totale degli oggetti BoundedSource generati dall'operazione splitIntoBundles() dell'origine personalizzata è di 20 MB.

Per aggirare questa limitazione, apporta una delle seguenti modifiche:

  1. Attiva Runner V2. Runner v2 converte le origini in file DoFns divisi che non hanno questo limite di suddivisione.

  2. Modifica la tua sottoclasse BoundedSource personalizzata in modo che le dimensioni totali degli oggetti BoundedSource generati siano inferiori al limite di 20 MB. Ad esempio, l'origine potrebbe generare inizialmente meno suddivisioni e utilizzare il ribilanciamento dinamico del lavoro per suddividere ulteriormente gli input on demand.

NameError

Quando esegui la pipeline utilizzando il servizio Dataflow, si verifica il seguente errore:

NameError

Questo errore non si verifica quando esegui l'esecuzione localmente, ad esempio quando esegui utilizzando DirectRunner.

Questo errore si verifica se i DoFn utilizzano valori nello spazio dei nomi globale che non sono disponibili nel worker Dataflow.

Per impostazione predefinita, le importazioni globali, le funzioni e le variabili definite nella sessione principale non vengono salvate durante la serializzazione di un job Dataflow.

Per risolvere il problema, utilizza uno dei seguenti metodi. Se i valori DoFn sono definiti nel file principale e fanno riferimento a importazioni e funzioni nello spazio dei nomi globale, imposta l'opzione della pipeline --save_main_session su True. Questa modifica seleziona lo stato dello spazio dei nomi globale e lo carica sul worker Dataflow.

Se nello spazio dei nomi globale sono presenti oggetti che non possono essere conservati, si verifica un errore di decapaggio. Se l'errore riguarda un modulo che dovrebbe essere disponibile nella distribuzione Python, importa il modulo localmente, dove viene utilizzato.

Ad esempio, invece di:

import re
…
def myfunc():
  # use re module

utilizza:

def myfunc():
  import re
  # use re module

In alternativa, se i tuoi DoFn comprendono più file, utilizza un approccio diverso per pacchettizzare il flusso di lavoro e gestire le dipendenze.

Elaborazione bloccata o operazione in corso

Se Dataflow trascorre più tempo nell'esecuzione di un DoFn rispetto al tempo specificato in TIME_INTERVAL senza restituire, viene visualizzato il seguente messaggio.

Java

Uno dei due messaggi di log seguenti, a seconda della versione:

Processing stuck in step STEP_NAME for at least TIME_INTERVAL

Operation ongoing in bundle BUNDLE_ID for at least TIME_INTERVAL without outputting or completing: at STACK_TRACE

Python

Operation ongoing for over TIME_INTERVAL in state STATE in step STEP_ID without returning. Current Traceback: TRACEBACK

Go

Operation ongoing in transform TRANSFORM_ID for at least TIME_INTERVAL without outputting or completing in state STATE

Questo comportamento può avere due cause:

  • Il codice DoFn è lento o è in attesa del completamento di un'operazione esterna lenta.
  • Il codice DoFn potrebbe essere bloccato, in modalità deadlock o in modo anomalo per completare l'elaborazione.

Per determinare quale sia il caso, espandi la voce di log Cloud Monitoring per visualizzare un'analisi dello stack. Cerca messaggi che indicano che il codice DoFn è bloccato o che si sono verificati problemi. Se non sono presenti messaggi, il problema potrebbe essere la velocità di esecuzione del codice DoFn. Valuta la possibilità di utilizzare Cloud Profiler o un altro strumento per analizzare le prestazioni del tuo codice.

Se la tua pipeline è basata su Java VM (utilizzando Java o Scala), puoi investigare la causa del codice bloccato. Esegui un dump del thread completo dell'intera JVM (non solo del thread bloccato) seguendo questi passaggi:

  1. Prendi nota del nome del worker nella voce di log.
  2. Nella sezione Compute Engine della console Google Cloud, trova l'istanza Compute Engine con il nome del worker che hai annotato.
  3. Utilizza SSH per connetterti all'istanza con quel nome.
  4. Esegui questo comando:

    curl http://localhost:8081/threadz
    

Errori di quota Pub/Sub

Durante l'esecuzione di una pipeline in modalità flusso da Pub/Sub, si verificano i seguenti errori:

429 (rateLimitExceeded)

Oppure:

Request was throttled due to user QPS limit being reached

Questi errori si verificano se il progetto ha una quota Pub/Sub insufficiente.

Per scoprire se la quota del tuo progetto è insufficiente, segui questi passaggi per verificare la presenza di errori del client:

  1. Vai alla console Google Cloud.
  2. Nel menu a sinistra, seleziona API e servizi.
  3. Nella casella di ricerca, cerca Cloud Pub/Sub.
  4. Fai clic sulla scheda Utilizzo.
  5. Controlla Codici di risposta e cerca i codici di errore del client (4xx).

La richiesta è vietata dai criteri dell'organizzazione

Durante l'esecuzione di una pipeline, si verifica il seguente errore:

Error trying to get gs://BUCKET_NAME/FOLDER/FILE:
{"code":403,"errors":[{"domain":"global","message":"Request is prohibited by organization's policy","reason":"forbidden"}],
"message":"Request is prohibited by organization's policy"}

Questo errore si verifica se il bucket Cloud Storage si trova all'esterno del perimetro di servizio.

Per risolvere il problema, crea una regola in uscita che consenta l'accesso al bucket all'esterno del perimetro di servizio.

Il pacchetto temporaneo è inaccessibile

I job utilizzati per la riuscita potrebbero non riuscire con il seguente errore:

Staged package...is inaccessible

Per risolvere il problema:

  • Verifica che il bucket Cloud Storage utilizzato per la gestione temporanea non abbia impostazioni TTL che causano l'eliminazione dei pacchetti temporanei.
  • Verifica che l'account di servizio worker del tuo progetto Dataflow disponga dell'autorizzazione per accedere al bucket Cloud Storage utilizzato per la gestione temporanea. Le lacune nelle autorizzazioni possono essere dovute a uno dei seguenti motivi:

    • Il bucket Cloud Storage utilizzato per la gestione temporanea è presente in un altro progetto.
    • È stata eseguita la migrazione del bucket Cloud Storage utilizzato per la gestione temporanea, dall'accesso granulare ad accesso uniforme a livello di bucket. A causa dell'incoerenza tra i criteri IAM e ACL, la migrazione del bucket gestione temporanea all'accesso uniforme a livello di bucket non consente gli ACL per le risorse Cloud Storage. Gli ACL includono le autorizzazioni dell'account di servizio worker del progetto Dataflow sul bucket di gestione temporanea.

Per ulteriori informazioni, consulta Accesso ai bucket Cloud Storage tra progetti Google Cloud.

Un elemento di lavoro non è riuscito per 4 volte

Quando un job non va a buon fine, si verifica il seguente errore:

a work item failed 4 times

Questo errore si verifica se una singola operazione provoca un errore nel codice worker per quattro volte. Dataflow non riesce a eseguire il job e viene visualizzato questo messaggio.

Non puoi configurare questa soglia di errore. Per ulteriori dettagli, consulta Gestione degli errori e delle eccezioni della pipeline.

Per risolvere il problema, cerca i quattro errori individuali nei log di Cloud Monitoring del job. Cerca le voci di log A livello di errore o A livello di errore irreversibile nei log del worker che mostrano eccezioni o errori. L'eccezione o l'errore dovrebbe comparire almeno quattro volte. Se i log contengono solo errori di timeout generici relativi all'accesso alle risorse esterne, ad esempio MongoDB, verifica che l'account di servizio worker disponga dell'autorizzazione per accedere alla subnet della risorsa.

Timeout nel file dei risultati del sondaggio

Quando un job non va a buon fine, si verifica quanto segue:

Timeout in polling result file: PATH. Possible causes are:
1. Your launch takes too long time to finish. Please check the logs on stackdriver.
2. Service account SERVICE_ACCOUNT may not have enough permissions to pull
container image IMAGE_PATH or create new objects in PATH.
3. Transient errors occurred, please try again.

Il problema è spesso correlato all'installazione delle dipendenze Python tramite il file requirements.txt. Lo stager Apache Beam scarica da PyPi l'origine di tutte le dipendenze, incluse le origini delle dipendenze transitive. Quindi, la compilazione wheel avviene implicitamente durante il comando di download pip per alcuni pacchetti Python che sono dipendenze di apache-beam. Potrebbe verificarsi un problema di timeout a causa del file requirements.txt.

Per ulteriori informazioni, consulta il bug del team di Apache Arrow relativo al monitoraggio di questo problema. La soluzione suggerita è installare apache-beam direttamente nel Dockerfile. In questo modo, il timeout per il file requirements.txt non viene applicato.

Archivia errori del job

Le seguenti sezioni contengono errori comuni che potresti riscontrare quando provi ad archiviare un job Dataflow utilizzando l'API.

Nessun valore specificato

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente errore:

The field mask specifies an update for the field job_metadata.user_display_properties.archived in job JOB_ID, but no value is provided. To update a field, please provide a field for the respective value.

Questo errore si verifica per uno dei seguenti motivi:

  • Il percorso specificato per il campo updateMask non è nel formato corretto. Questo problema può verificarsi a causa di errori di battitura.

  • Il valore JobMetadata non è specificato correttamente. Nel campo JobMetadata, per userDisplayProperties, utilizza la coppia chiave-valore "archived":"true".

Per risolvere questo errore, verifica che il comando che passi all'API corrisponda al formato richiesto. Per maggiori dettagli, consulta Archiviare un job.

L'API non riconosce il valore

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente errore:

The API does not recognize the value VALUE for the field job_metadata.user_display_properties.archived for job JOB_ID. REASON: Archived display property can only be set to 'true' or 'false'

Questo errore si verifica quando il valore fornito nella coppia chiave-valore dei job di archiviazione non è supportato. I valori supportati per la coppia chiave-valore dei job di archiviazione sono "archived":"true" e "archived":"false".

Per risolvere questo errore, verifica che il comando che passi all'API corrisponda al formato richiesto. Per maggiori dettagli, consulta Archiviare un job.

Impossibile aggiornare sia stato che maschera

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente errore:

Cannot update both state and mask.

Questo errore si verifica quando provi ad aggiornare sia lo stato del job sia lo stato dell'archivio nella stessa chiamata API. Non puoi aggiornare sia lo stato del job sia il parametro di query updateMask nella stessa chiamata API.

Per risolvere questo errore, aggiorna lo stato del job in una chiamata API separata. Aggiorna lo stato dei job prima di aggiornare lo stato dell'archivio dei job.

Modifica del flusso di lavoro non riuscita

Quando provi ad archiviare un job Dataflow utilizzando l'API, potrebbe verificarsi il seguente errore:

Workflow modification failed.

Questo errore si verifica in genere quando provi ad archiviare un job in esecuzione.

Per risolvere questo errore, attendi il completamento del job prima di archiviarlo. I job completati hanno uno dei seguenti stati dei job:

  • JOB_STATE_CANCELLED
  • JOB_STATE_DRAINED
  • JOB_STATE_DONE
  • JOB_STATE_FAILED
  • JOB_STATE_UPDATED

Per ulteriori informazioni, consulta Rilevare il completamento dei job Dataflow.

Errori dell'immagine container

Le seguenti sezioni contengono errori comuni che potresti riscontrare durante l'utilizzo dei container personalizzati, nonché i passaggi per risolverli o per risolverli. In genere, gli errori sono preceduti dal seguente messaggio:

Unable to pull container image due to error: DETAILED_ERROR_MESSAGE

Autorizzazione "containeranalysis.ricevimenti.list" negata

Nei file di log viene visualizzato il seguente errore:

Error getting old patchz discovery occurrences: generic::permission_denied: permission "containeranalysis.occurrences.list" denied for project "PROJECT_ID", entity ID "" [region="REGION" projectNum=PROJECT_NUMBER projectID="PROJECT_ID"]

è necessaria l'API Container Analysis per l'analisi delle vulnerabilità.

Per maggiori informazioni, consulta Panoramica della scansione del sistema operativo e Configurazione del controllo dell'accesso nella documentazione di Artifact Analysis.

Errore durante la sincronizzazione del pod in "StartContainer" non riuscito

Durante l'avvio del worker si è verificato il seguente errore:

Error syncing pod POD_ID, skipping: [failed to "StartContainer" for CONTAINER_NAME with CrashLoopBackOff: "back-off 5m0s restarting failed container=CONTAINER_NAME pod=POD_NAME].

Un pod è un gruppo collocato di container Docker in esecuzione su un worker Dataflow. Questo errore si verifica quando uno dei container Docker nel pod non si avvia. Se l'errore non è recuperabile, il worker Dataflow non può essere avviato e i job batch di Dataflow non andranno a buon fine e alla fine verranno restituiti errori come il seguente:

The Dataflow job appears to be stuck because no worker activity has been seen in the last 1h.

Questo errore si verifica in genere quando uno dei container si arresta continuamente durante l'avvio.

Per comprendere la causa principale, cerca i log acquisiti immediatamente prima dell'errore. Per analizzare i log, utilizza Esplora log. In Esplora log, limita i file di log alle voci di log emesse dal worker con errori di avvio del container. Per limitare le voci di log, completa i seguenti passaggi:

  1. In Esplora log, individua la voce di log Error syncing pod.
  2. Per visualizzare le etichette associate alla voce di log, espandi la voce di log.
  3. Fai clic sull'etichetta associata a resource_name, quindi su Mostra voci corrispondenti.

La pagina Esplora log in cui sono evidenziati i passaggi per limitare i file di log.

In Esplora log, i log di Dataflow sono organizzati in diversi flussi di log. Il messaggio Error syncing pod viene emesso nel log denominato kubelet. Tuttavia, i log del container in errore potrebbero trovarsi in un flusso di log diverso. Ogni container ha un nome. Usa la seguente tabella per determinare quale flusso di log potrebbe contenere i log pertinenti per il container in errore.

Nome container Nomi dei log
sdk, sdk0, sdk1, sdk-0-0 e simili docker
imbracatura imbracatura, avviamento-imbracatura
python, java-batch, java-streaming avvio-lavoratore, worker
artefatto artefatto

Quando esegui una query su Esplora log, assicurati che la query includa i nomi dei log pertinenti nell'interfaccia di Query Builder o che non abbia limitazioni sul nome dei log.

Una query Esplora log che include i nomi dei log pertinenti.

Dopo aver selezionato i log pertinenti, il risultato della query potrebbe essere simile al seguente esempio:

resource.type="dataflow_step"
resource.labels.job_id="2022-06-29_08_02_54-JOB_ID"
labels."compute.googleapis.com/resource_name"="testpipeline-jenkins-0629-DATE-cyhg-harness-8crw"
logName=("projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fdocker"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker-startup"
OR
"projects/apache-beam-testing/logs/dataflow.googleapis.com%2Fworker")

Poiché i log che segnalano il sintomo dell'errore del container a volte vengono segnalati come INFO, includi i log INFO nell'analisi.

Le cause tipiche degli errori dei container sono le seguenti:

  1. La pipeline Python ha dipendenze aggiuntive installate in fase di runtime e l'installazione non riesce. Potresti visualizzare errori come pip install failed with error. Questo problema può verificarsi a causa di requisiti in conflitto o a causa di una configurazione di rete limitata che impedisce a un worker Dataflow di eseguire il pull di una dipendenza esterna da un repository pubblico su internet.
  2. Un worker non funziona durante l'esecuzione della pipeline a causa di un errore di esaurimento della memoria. Potresti visualizzare un errore simile a uno dei seguenti:

    • java.lang.OutOfMemoryError: Java heap space
    • Shutting down JVM after 8 consecutive periods of measured GC thrashing. Memory is used/total/max = 24453/42043/42043 MB, GC last/max = 58.97/99.89 %, #pushbacks=82, gc thrashing=true. Heap dump not written.

    Per eseguire il debug di un problema di esaurimento della memoria, consulta Risolvere i problemi di esaurimento della memoria di Dataflow.

  3. Dataflow non è in grado di eseguire il pull dell'immagine container. Per ulteriori informazioni, consulta la pagina Richiesta di pull dell'immagine non riuscita con errore.

  4. Il container utilizzato non è compatibile con l'architettura della CPU della VM worker. Nei log di avvio del cablaggio, potrebbe essere visualizzato un errore simile al seguente: exec /opt/apache/beam/boot: exec format error. Per verificare l'architettura dell'immagine container, esegui docker image inspect $IMAGE:$TAG e cerca la parola chiave Architecture. Se è indicato Error: No such image: $IMAGE:$TAG, potrebbe essere necessario eseguire prima il pull dell'immagine eseguendo docker pull $IMAGE:$TAG. Per informazioni sulla creazione di immagini con più architetture, consulta Creare un'immagine container con più architetture.

Dopo aver identificato l'errore che causa l'errore del container, prova a risolvere l'errore, quindi invia nuovamente la pipeline.

Richiesta di pull dell'immagine non riuscita con errore

Durante l'avvio dei worker, viene visualizzato uno dei seguenti errori nei log dei worker o del job:

Image pull request failed with error
pull access denied for IMAGE_NAME
manifest for IMAGE_NAME not found: manifest unknown: Failed to fetch
Get IMAGE_NAME: Service Unavailable

Questi errori si verificano se un worker non è in grado di avviarsi perché non può estrarre un'immagine container Docker. Questo problema si verifica nei seguenti scenari:

  • L'URL dell'immagine del contenitore dell'SDK personalizzato non è corretto
  • Il worker non dispone delle credenziali o dell'accesso di rete all'immagine remota

Per risolvere il problema:

  • Se utilizzi un'immagine container personalizzata con il job, verifica che l'URL dell'immagine sia corretto e che abbia un tag o un digest valido. Anche i worker Dataflow devono accedere all'immagine.
  • Verifica che le immagini pubbliche possano essere estratte localmente eseguendo docker pull $image da una macchina non autenticata.

Per immagini private o worker privati:

  • Se utilizzi Container Registry per ospitare l'immagine container, ti consigliamo di usare invece Artifact Registry. A partire dal 15 maggio 2023, Container Registry verrà deprecato. Se utilizzi Container Registry, puoi passare ad Artifact Registry. Se le immagini si trovano in un progetto diverso da quello utilizzato per eseguire il job Google Cloud, configura il controllo dell'accesso per l'account di servizio predefinito di Google Cloud.
  • Se utilizzi VPC (Virtual Private Cloud) condiviso, assicurati che i worker possano accedere all'host del repository del container personalizzato.
  • Usa ssh per connetterti con una VM worker job in esecuzione ed esegui docker pull $image per confermare direttamente che il worker sia configurato correttamente.

Se i worker si guastano diverse volte di seguito a causa di questo errore e il lavoro è stato avviato su un job, il job potrebbe non riuscire e generare un errore simile al seguente messaggio:

Job appears to be stuck.

Se rimuovi l'accesso all'immagine mentre il job è in esecuzione, rimuovendo l'immagine stessa o revocando le credenziali dell'account di servizio del worker Dataflow o l'accesso a internet per accedere alle immagini, Dataflow registra solo gli errori. Dataflow non può avere esito negativo. Inoltre, Dataflow evita di errori delle pipeline in modalità flusso a lunga esecuzione per evitare di perdere lo stato della pipeline.

Altri possibili errori possono verificarsi a causa di problemi o interruzioni delle quote del repository. Se riscontri problemi che superano la quota di Docker Hub per il pull di immagini pubbliche o interruzioni generali dei repository di terze parti, valuta l'utilizzo di Artifact Registry come repository di immagini.

Errore di sistema: codice operativo sconosciuto

La pipeline del container personalizzato Python potrebbe non riuscire con il seguente errore subito dopo l'invio del job:

SystemError: unknown opcode

Inoltre, l'analisi dello stack potrebbe includere

apache_beam/internal/pickler.py

Per risolvere il problema, verifica che la versione Python che stai utilizzando localmente corrisponda alla versione nell'immagine container fino alla versione principale e secondaria. La differenza nella versione della patch, ad esempio 3.6.7 rispetto alla 3.6.8, non crea problemi di compatibilità. La differenza nella versione secondaria, ad esempio 3.6.8 rispetto a 3.8.2, può causare errori della pipeline.

Errori del worker

Le seguenti sezioni contengono errori comuni dei worker che potresti riscontrare e i passaggi per risolverli o per risolverli.

La chiamata dal cablaggio dei worker Java al DoFn di Python ha esito negativo e restituisce un errore

Se una chiamata dal cablaggio worker Java a un DoFn Python ha esito negativo, viene visualizzato un messaggio di errore pertinente.

Per esaminare l'errore, espandi la voce del log degli errori di Cloud Monitoring ed esamina il messaggio di errore e il tracciamento. e indica quale codice non è riuscito, in modo da correggerlo, se necessario. Se ritieni che l'errore sia un bug in Apache Beam o Dataflow, segnala il bug.

EOFError: dati marshal troppo brevi

Nei log del worker viene visualizzato il seguente errore:

EOFError: marshal data too short

Questo errore a volte si verifica quando i worker della pipeline Python esauriscono lo spazio su disco.

Per risolvere il problema, vedi Spazio esaurito sul dispositivo.

Impossibile collegare il disco

Quando provi ad avviare un job Dataflow che utilizza VM C3 con Persistent Disk, il job non riesce e restituisce uno o entrambi i seguenti errori:

Failed to attach disk(s), status: generic::invalid_argument: One or more operations had an error
Can not allocate sha384 (reason: -2), Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on...

Questi errori si verificano quando utilizzi VM C3 con un tipo di Persistent Disk non supportato. Per ulteriori informazioni, consulta Tipi di disco supportati per C3.

Per utilizzare le VM C3 con il job Dataflow, scegli il tipo di disco worker pd-ssd. Per maggiori informazioni, consulta Opzioni a livello di worker.

Java

--workerDiskType=pd-ssd

Python

--worker_disk_type=pd-ssd

Go

disk_type=pd-ssd

Spazio sul dispositivo esaurito

Quando lo spazio su disco di un job si esaurisce, nei log del worker potrebbe essere visualizzato il seguente errore:

No space left on device

Questo errore può verificarsi per uno dei seguenti motivi:

  • L'archiviazione permanente del worker esaurisce lo spazio libero, il che può verificarsi per uno dei seguenti motivi:
    • Un job scarica dipendenze di grandi dimensioni in fase di runtime
    • Un job utilizza container personalizzati di grandi dimensioni
    • Un job scrive molti dati temporanei sul disco locale
  • Quando utilizzi Dataflow shuffling, Dataflow imposta una dimensione predefinita inferiore del disco. Di conseguenza, questo errore potrebbe verificarsi con i job che passano dallo shuffling basato sui worker.
  • Il disco di avvio del worker si riempie perché registra più di 50 voci al secondo.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

Per visualizzare le risorse del disco associate a un singolo worker, cerca i dettagli dell'istanza VM per le VM worker associate al tuo job. Parte dello spazio su disco viene consumata dal sistema operativo, dai programmi binari, dai log e dai container.

Per aumentare lo spazio sul disco permanente o sul disco di avvio, modifica l'opzione della pipeline delle dimensioni del disco.

Tieni traccia dell'utilizzo dello spazio su disco nelle istanze VM worker con Cloud Monitoring. Per istruzioni sulla configurazione, consulta Ricevere le metriche delle VM worker dall'agente Monitoring.

Cerca eventuali problemi di spazio sul disco di avvio visualizzando l'output della porta seriale sulle istanze VM worker e cercando messaggi come:

Failed to open system journal: No space left on device

Se disponi di molte istanze VM worker, puoi creare uno script per eseguire gcloud compute instances get-serial-port-output su tutte contemporaneamente. Puoi invece esaminare l'output.

La pipeline Python si arresta dopo un'ora di inattività del worker

Se utilizzi l'SDK Apache Beam per Python con Dataflow Runner V2 su macchine worker con molti core di CPU, utilizza l'SDK Apache Beam 2.35.0 o versioni successive. Se il job utilizza un container personalizzato, utilizza l'SDK Apache Beam 2.46.0 o versioni successive.

Valuta la possibilità di creare preventivamente il tuo container Python. Questo passaggio può migliorare i tempi di avvio delle VM e le prestazioni della scalabilità automatica orizzontale. Per utilizzare questa funzionalità, abilita l'API Cloud Build nel tuo progetto e invia la pipeline con il seguente parametro:

‑‑prebuild_sdk_container_engine=cloud_build.

Per ulteriori informazioni, consulta Dataflow Runner V2.

Puoi anche utilizzare un'immagine container personalizzata con tutte le dipendenze preinstallate.

L'avvio del pool di worker nella zona non è riuscito a recuperare nessuno dei worker desiderati

Si verifica il seguente errore:

Startup of the worker pool in zone ZONE_NAME failed to bring up any of the desired NUMBER workers.
The project quota may have been exceeded or access control policies may be preventing the operation;
review the Cloud Logging 'VM Instance' log for diagnostics.

Questo errore si verifica per uno dei seguenti motivi:

  • Hai superato una delle quote di Compute Engine utilizzate per la creazione dei worker Dataflow.
  • La tua organizzazione dispone di vincoli che vietano alcuni aspetti del processo di creazione delle istanze VM, come l'account in uso o la zona scelta come target.

Per risolvere il problema, segui questi passaggi per la risoluzione dei problemi:

Esamina il log delle istanze VM

  1. Vai al visualizzatore Cloud Logging
  2. Nell'elenco a discesa Risorsa controllata, seleziona Istanza VM.
  3. Nell'elenco a discesa Tutti i log, seleziona compute.googleapis.com/activity_log.
  4. Analizza il log per individuare eventuali voci relative all'errore di creazione dell'istanza VM.

Controlla l'utilizzo delle quote di Compute Engine

  1. Per visualizzare l'utilizzo delle risorse di Compute Engine rispetto alle quote di Dataflow per la zona scelta come target, esegui questo comando:

    gcloud compute regions describe [REGION]

  2. Esamina i risultati per le seguenti risorse per vedere se qualcuna supera la quota:

    • CPU
    • DISKS_TOTAL_GB
    • IN_USE_ADDRESSES
    • INSTANCE_GROUPS
    • ISTANZE
    • REGIONAL_INSTANCE_GROUP_MANAGERS
  3. Se necessario, richiedi una modifica della quota.

Rivedi i vincoli dei criteri dell'organizzazione

  1. Vai alla pagina Criteri dell'organizzazione
  2. Rivedi i vincoli per qualsiasi elemento che potrebbe limitare la creazione di istanze VM per l'account in uso (per impostazione predefinita l'account di servizio Dataflow) o per la zona che hai scelto come target.
  3. Se hai un criterio che limita l'uso degli indirizzi IP esterni, disattiva gli indirizzi IP esterni per questo job. Per saperne di più sulla disattivazione degli indirizzi IP esterni, consulta Configurare l'accesso a internet e le regole firewall.

Timeout durante l'attesa di un aggiornamento da parte del worker

Quando un job Dataflow non va a buon fine, si verifica il seguente errore:

Root cause: Timed out waiting for an update from the worker. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors#worker-lost-contact.

A volte, questo errore si verifica quando il worker esaurisce la memoria o lo spazio di scambio. Per risolvere il problema, come primo passaggio prova a eseguire nuovamente il job. Se il job continua a non riuscire e si verifica lo stesso errore, prova a utilizzare un worker con più memoria e spazio su disco. Ad esempio, aggiungi la seguente opzione di avvio della pipeline:

--worker_machine_type=m1-ultramem-40 --disk_size_gb=500

La modifica del tipo di worker potrebbe influire sul costo fatturato. Per ulteriori informazioni, consulta Risolvere i problemi di esaurimento della memoria di Dataflow.

Questo errore può verificarsi anche quando i dati contengono un tasto di scelta rapida. In questo scenario, l'utilizzo della CPU è elevato su alcuni worker per la maggior parte della durata del job. Tuttavia, il numero di worker non raggiunge il massimo consentito. Per ulteriori informazioni sulle chiavi di accesso rapido e sulle possibili soluzioni, consulta Scrittura di pipeline Dataflow tenendo a mente la scalabilità.

Per ulteriori soluzioni al problema, consulta È stato rilevato un tasto di scelta rapida.

Se il codice Python chiama codice C/C++ utilizzando il meccanismo di estensione Python, verifica se il codice dell'estensione rilascia il blocco GIL (Global Interpreter Lock) Python in parti di codice ad alta intensità di calcolo che non accedono allo stato Python. Le librerie che facilitano le interazioni con estensioni come Cython e PyBind hanno primitive per controllare lo stato GIL. Puoi anche rilasciare manualmente GIL e riacquisirlo prima di restituire il controllo all'interprete Python utilizzando le macro Py_BEGIN_ALLOW_THREADS e Py_END_ALLOW_THREADS. Per ulteriori informazioni, consulta Stato del thread e blocco dell'interprete globale nella documentazione di Python.

Nelle pipeline Python, nella configurazione predefinita Dataflow presuppone che ogni processo Python in esecuzione sui worker utilizzi in modo efficiente un core vCPU. Se il codice della pipeline ignora le limitazioni GIL, ad esempio utilizzando librerie implementate in C++, gli elementi di elaborazione potrebbero utilizzare risorse di più core vCPU e i worker potrebbero non ottenere un numero sufficiente di risorse della CPU. Per risolvere questo problema, riduci il numero di thread sui worker.

Problemi di dipendenza Java

Classi e librerie incompatibili possono causare problemi di dipendenza Java. Quando la tua pipeline presenta problemi di dipendenza Java, potrebbe verificarsi uno dei seguenti errori:

  • NoClassDefFoundError: questo errore si verifica quando un'intera classe non è disponibile durante il runtime.
  • NoSuchMethodError: questo errore si verifica quando la classe in classpath utilizza una versione che non contiene il metodo corretto o quando la firma del metodo è stata modificata.
  • NoSuchFieldError: questo errore si verifica quando la classe in classpath utilizza una versione che non ha un campo obbligatorio durante il runtime.
  • FATAL ERROR in native method: questo errore si verifica quando una dipendenza integrata non può essere caricata correttamente. Quando utilizzi Uber JAR (ombreggiato), non includere librerie che usano firme (come Conscrypt) nello stesso JAR.

Se la pipeline contiene codice e impostazioni specifici dell'utente, il codice non può contenere versioni miste delle librerie. Se utilizzi una libreria di gestione delle dipendenze, ti consigliamo di utilizzare il BOM delle librerie Google Cloud.

Se utilizzi l'SDK Apache Beam, per importare la distinta base delle librerie corrette, utilizza beam-sdks-java-io-google-cloud-platform-bom:

Maven

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.beam</groupId>
      <artifactId>beam-sdks-java-google-cloud-platform-bom</artifactId>
      <version>BEAM_VERSION</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradle

dependencies {
    implementation(platform("org.apache.beam:beam-sdks-java-google-cloud-platform-bom:BEAM_VERSION"))
}

Per maggiori informazioni, consulta Gestire le dipendenze della pipeline in Dataflow.

InAccessObjectException in JDK 17 e versioni successive

Quando esegui pipeline con Java Platform, JDK (Standard Edition Development Kit) 17 e versioni successive, nei file di log dei worker potrebbe essere visualizzato il seguente errore:

Unable to make protected METHOD accessible:
    module java.MODULE does not "opens java.MODULE" to ...

Questo problema si verifica perché, a partire da Java versione 9, sono necessarie le opzioni JVM (Java Virtual Machine) del modulo aperto per accedere agli elementi interni JDK. In Java 16 e versioni successive, le opzioni JVM per moduli aperti sono sempre necessarie per accedere agli interni JDK.

Per risolvere il problema, quando passi i moduli alla pipeline Dataflow per aprirli, utilizza il formato MODULE/PACKAGE=TARGET_MODULE(,TARGET_MODULE)* con l'opzione pipeline jdkAddOpenModules. Questo formato consente di accedere alla libreria necessaria.

Ad esempio, se l'errore è module java.base does not "opens java.lang" to unnamed module @..., includi la seguente opzione di pipeline quando esegui la pipeline:

--jdkAddOpenModules=java.base/java.lang=ALL-UNNAMED

Per ulteriori informazioni, consulta la documentazione della classe DataflowPipelineOptions.

Errori del connettore BigQuery

Le seguenti sezioni contengono errori comuni del connettore BigQuery che potresti riscontrare e i passaggi per risolverli o per risolverli.

quotaExceeded

Quando utilizzi il connettore BigQuery per scrivere in BigQuery mediante l'inserimento di flussi di dati, la velocità effettiva di scrittura è inferiore al previsto e potrebbe verificarsi il seguente errore:

quotaExceeded

Una velocità effettiva lenta potrebbe essere dovuta al superamento della quota di inserimento di flussi di dati BigQuery disponibile da parte della pipeline. In questo caso, i messaggi di errore relativi alla quota di BigQuery vengono visualizzati nei log dei worker di Dataflow (cerca gli errori quotaExceeded).

Se vedi quotaExceeded errori, per risolvere il problema:

  • Quando utilizzi l'SDK Apache Beam per Java, imposta l'opzione del sink BigQuery ignoreInsertIds().
  • Quando utilizzi l'SDK Apache Beam per Python, ricorri all'opzione ignore_insert_ids.

Queste impostazioni ti consentono di avere una velocità effettiva di inserimento di flussi di dati di dati BigQuery per progetto di 1 GB al secondo. Per ulteriori informazioni sulle avvertenze relative alla deduplicazione automatica dei messaggi, consulta la documentazione di BigQuery. Per aumentare la quota di inserimento di flussi di dati BigQuery superiore a 1 GB/s, invia una richiesta tramite la console Google Cloud.

Se non visualizzi errori relativi alla quota nei log dei worker, il problema potrebbe essere che i parametri relativi al raggruppamento o al batch predefinito non forniscono un parallelismo adeguato per la scalabilità della pipeline. Puoi modificare diverse configurazioni relative al connettore BigQuery di Dataflow per ottenere le prestazioni previste durante la scrittura in BigQuery utilizzando l'inserimento di flussi di dati. Ad esempio, per l'SDK Apache Beam per Java, modifica numStreamingKeys in modo che corrisponda al numero massimo di worker e valuta la possibilità di aumentare il valore di insertBundleParallelism per configurare il connettore BigQuery per scrivere in BigQuery utilizzando più thread paralleli.

Per le configurazioni disponibili nell'SDK Apache Beam per Java, consulta BigQueryPipelineOptions, mentre per le configurazioni disponibili nell'SDK Apache Beam per Python, consulta la trasformazione WriteToBigQuery.

rateLimitExceeded

Quando utilizzi il connettore BigQuery, si verifica il seguente errore:

rateLimitExceeded

Questo errore si verifica se a BigQuery vengono inviate troppe richieste API nell'arco di un breve periodo di tempo. BigQuery ha limiti di quota a breve termine. È possibile che la tua pipeline Dataflow superi temporaneamente questa quota. In questo scenario, le richieste API dalla pipeline Dataflow a BigQuery potrebbero non riuscire, causando errori rateLimitExceeded nei log dei worker.

Dataflow prova a ripetere questi errori, quindi puoi ignorarli in tutta sicurezza. Se ritieni che la tua pipeline sia interessata da errori rateLimitExceeded, contatta l'assistenza clienti Google Cloud.

Errori vari

Le seguenti sezioni contengono vari errori che potresti riscontrare e i passaggi per risolverli o per risolverli.

Oggetto non trovato: pipeline.pb

Quando elenchi i job utilizzando l'opzione JOB_VIEW_ALL, si verifica il seguente errore:

No such object: BUCKET_NAME/PATH/pipeline.pb

Questo errore può verificarsi se elimini il file pipeline.pb dai file di gestione temporanea del job.

Suggerimenti

Per indicazioni sui suggerimenti generati dagli insight di Dataflow, consulta Approfondimenti.