Hinweise zu gängigen Fehlern

Auf dieser Seite werden einige gängige Fehler beschrieben, die beim Ausführen eines Dataflow-Jobs auftreten können. Außerdem finden Sie verschiedene Vorschläge zum Umgang mit diesen Fehlern.

Meldungen zu Jobs:

Fehler beim Senden von Jobs:

Worker-Logs (Stackdriver):

Meldungen zu Jobs

"Der Job ist fehlgeschlagen, weil eine Arbeitsaufgabe viermal fehlgeschlagen ist."

Wenn ein einzelner Vorgang dazu führt, dass der Worker-Code viermal fehlschlägt, weil er eine Ausnahme auslöst oder abstürzt, schlägt der Job in Dataflow mit der Meldung a work item failed 4 times fehl.

Suchen Sie in den Stackdriver-Logs des Jobs nach den vier einzelnen Fehlern. Suchen Sie in den Worker-Logs, in denen Ausnahmen oder Fehler aufgeführt sind, nach Logeinträgen der Stufe Fehler oder Schwerwiegend. Sie sollten mindestens vier dieser Ausnahmen oder Fehler finden.

Codierungsfehler, IOExceptions oder unerwartetes Verhalten im Nutzercode

Die Apache Beam SDKs und die Dataflow-Worker sind von gängigen Drittanbieterkomponenten abhängig. Diese importieren zusätzliche Abhängigkeiten. Versionskollisionen können zu unerwarteten Verhaltensweisen im Dienst führen. Wenn Sie eines dieser Pakete in Ihrem Code verwenden, beachten Sie, dass einige Bibliotheken nicht aufwärtskompatibel sind. Möglicherweise müssen Sie die aufgelisteten Versionen verwenden, die bei der Ausführung aktuell sind. Unter SDK- und Worker-Abhängigkeiten finden Sie eine Liste der Abhängigkeiten und ihrer erforderlichen Versionen.

Jobs, die früher ausgeführt wurden, erzeugen jetzt den Fehler "Abgestuftes Paket... Kein Zugriff möglich"

Achten Sie darauf, dass der für das Staging verwendete Cloud Storage-Bucket keine TTL-Einstellungen enthält, die zum Löschen bereitgestellter Pakete führen.

Fehler beim Senden von Jobs

"413 Anfrageentität zu groß"/"Die Größe der serialisierten JSON-Darstellung der Pipeline überschreitet das zulässige Limit"

Wenn beim Einreichen eines Jobs ein Fehler bezüglich der JSON-Nutzlast auftritt, bedeutet dies, dass die JSON-Darstellung der Pipeline die maximale Anfragegröße von 10 MB überschreitet. Diese Fehler können als eine der folgenden Meldungen im Console- bzw. Terminalfenster dargestellt werden:

  • 413 Request Entity Too Large
  • "Die Größe der serialisierten JSON-Darstellung der Pipeline überschreitet die zulässige Grenze"
  • "Es konnte kein Workflowjob erstellt werden: ungültige JSON-Nutzlast erhalten"
  • "Es konnte kein Workflowjob erstellt werden: Anfragenutzlast überschreitet die zulässige Grenze"

Die Größe Ihres Jobs ist mit der JSON-Repräsentation der Pipeline verbunden. Eine größere Pipeline führt zu einem größeren Request. Dataflow hat derzeit eine Begrenzung von 10 MB für Requests.

Führen Sie die Pipeline zum Schätzen der Größe der JSON-Anfrage mit der folgenden Option aus:

Java: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Java: SDK 1.x

Mit diesem Befehl wird eine JSON-Darstellung des Jobs in eine Datei geschrieben. Die Größe der serialisierten Datei kann gut anhand der Größe der Anfrage geschätzt werden. Aufgrund von zusätzlichen Informationen in der Anfrage ist die tatsächliche Datei geringfügig größer.

Bestimmte Bedingungen in Ihrer Pipeline können bewirken, dass die JSON-Darstellung die Grenze überschreitet. Zu den häufigsten Bedingungen zählen:

  • Eine Create-Transformation, die eine große Menge an im Speicher befindlichen Daten enthält
  • Eine große DoFn-Instanz, die für die Übertragung an Remote-Worker serialisiert ist
  • Ein DoFn als anonyme innere Klasseninstanz, die (möglicherweise unbeabsichtigt) große Datenmengen zur Serialisierung abruft

Damit diese Bedingungen vermieden werden, sollten Sie Ihre Pipeline neu strukturieren.

"Die Jobgrafik ist zu groß. Versuchen Sie es mit einer kleineren Jobgrafik noch einmal oder teilen Sie den Job in zwei oder mehr kleinere Jobs auf."

Die Grafikgröße Ihres Jobs darf 10 MB nicht überschreiten. Bestimmte Bedingungen in der Pipeline können dazu führen, dass die Jobgrafik das Limit überschreitet. Zu den häufigsten Bedingungen zählen:

  • Eine Create-Transformation, die eine große Menge an im Speicher befindlichen Daten enthält
  • Eine große DoFn-Instanz, die für die Übertragung an Remote-Worker serialisiert ist
  • Ein DoFn als anonyme innere Klasseninstanz, die (möglicherweise unbeabsichtigt) große Datenmengen zur Serialisierung abruft

Damit diese Bedingungen vermieden werden, sollten Sie Ihre Pipeline neu strukturieren.

"Gesamtzahl der BoundedSource-Objekte, die vom splitIntoBundles()-Vorgang erzeugt wurden, ist größer als die zulässige Grenze" oder "Gesamtgröße der BoundedSource-Objekte, die vom splitIntoBundles()-Vorgang erzeugt wurden, ist größer als die zulässige Grenze"

Java: SDK 2.x

Dieser Fehler kann auftreten, wenn Sie Daten aus einer sehr großen Anzahl von Dateien über TextIO, AvroIO oder eine andere dateibasierte Quelle auslesen. Das jeweilige Limit hängt von den Details der Quelle ab (ein eingebettetes Schema in AvroIO.Read erlaubt z. B. weniger Dateien), liegt allerdings bei einer Größenordnung von Zehntausenden Dateien in einer Pipeline.

Dieser Fehler kann auch auftreten, wenn Sie eine splitIntoBundlesbenutzerdefinierte DatenquelleBoundedSource für Ihre Pipeline erstellt haben und die Methode Ihrer Quelle eine Liste von Objekten des Typs geliefert hat, die in serialisierter Form mehr als 20 MB beansprucht.

Das zulässige Limit für die Gesamtgröße der BoundedSource-Objekte, die vom splitIntoBundles()-Vorgang Ihrer benutzerdefinierten Quelle erzeugt wurden, ist 20 MB. Diese Einschränkung können Sie umgehen. Ändern Sie die benutzerdefinierte abgeleitete BoundedSource-Klasse so, dass die Gesamtgröße der generierten BoundedSource-Objekte unter dem Limit von 20 MB liegt. Ihre Quelle könnte beispielsweise anfänglich weniger Aufteilungen erzeugen und auf den dynamischen Work-Ausgleich zurückgreifen, um weitere Eingaben nach Bedarf aufzuteilen.

Java: SDK 1.x

Worker-Logs (Stackdriver)

"Die Verarbeitung ist in Schritt <Schritt-ID> mindestens <Zeitraum> lang ohne Ausgabe oder Abschluss im Status "Fertig" im <Stacktrace> hängen geblieben"

Wenn Dataflow mehr Zeit für die Ausführung einer DoFn benötigt als in <time_interval> (Zeitraum) angegeben, ohne ein Ergebnis zu liefern, wird diese Meldung angezeigt.

Dieser Fehler hat zwei mögliche Ursachen:

  • Ihr DoFn-Code ist einfach nur langsam oder wartet auf den Abschluss eines langsamen externen Vorgangs. In diesem Fall können Sie die Warnung ignorieren.
  • Ihr DoFn-Code ist möglicherweise hängen geblieben, blockiert oder ungewöhnlich lange mit der Verarbeitung beschäftigt. Wenn Sie glauben, dass dies der Fall ist, maximieren Sie den Stackdriver-Logeintrag, um sich den Stacktrace des hängen gebliebenen Codes anzusehen.

Sie können die Ursache Ihres hängen gebliebenen Codes weiter untersuchen, wenn Ihre Pipeline auf der Java-VM erstellt wurde (entweder mit Java oder Scala). Führen Sie dazu folgende Schritte aus, um einen vollständigen Thread-Dump der gesamten JVM (nicht nur des hängen gebliebenen Threads) zu erstellen:

  1. Notieren Sie sich den Worker-Namen aus dem Logeintrag.
  2. Suchen Sie im Compute Engine-Abschnitt der Cloud Console die Compute Engine-Instanz mit dem von Ihnen notierten Worker-Namen.
  3. Stellen Sie eine SSH-Verbindung zu der Instanz mit diesem Namen her.
  4. Führen Sie diesen Befehl aus:

    curl http://localhost:8081/threadz
        

RPC-Zeitüberschreitungsausnahmen, DEADLINE_EXCEEDED-Ausnahmen oder Fehler vom Typ "Server reagiert nicht"

Wenn bei der Ausführung Ihres Jobs RPC-Zeitüberschreitungen, DEADLINE_EXCEEDED-Ausnahmen oder Fehler vom Typ Server Unresponsive auftreten, deutet dies meist auf eines der beiden folgenden Probleme hin:

  • Im VPC-Netzwerk, das für den Job genutzt wird, fehlt möglicherweise eine Firewallregel. Die Firewallregel muss den gesamten TCP-Traffic zwischen VMs in dem VPC-Netzwerk ermöglichen, das Sie in den Pipelineoptionen angegeben haben. Weitere Einzelheiten finden Sie unter Netzwerk und Subnetzwerk angeben.

  • Ihr Job ist an das Zufallsprinzip gebunden. Hier können Sie sich für eine der folgenden Vorgehensweisen oder eine Kombination daraus entscheiden:

    Java: SDK 2.x

    • Fügen Sie weitere Worker hinzu. Legen Sie einen höheren Wert für --numWorkers fest, wenn Sie die Pipeline ausführen.
    • Erhöhen Sie die Größe des angehängten Laufwerks für Worker. Legen Sie einen höheren Wert für --diskSizeGb fest, wenn Sie die Pipeline ausführen.
    • Nutzen Sie einen SSD-gestützten nichtflüchtigen Speicher. Legen Sie --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" fest, wenn Sie die Pipeline ausführen.

    Python

    • Fügen Sie weitere Worker hinzu. Legen Sie einen höheren Wert für --num_workers fest, wenn Sie die Pipeline ausführen.
    • Erhöhen Sie die Größe des angehängten Laufwerks für Worker. Legen Sie einen höheren Wert für --disk_size_gb fest, wenn Sie die Pipeline ausführen.
    • Nutzen Sie einen SSD-gestützten nichtflüchtigen Speicher. Legen Sie --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd" fest, wenn Sie die Pipeline ausführen.

    Java: SDK 1.x


Ein Aufruf vom Java-Worker-Harness an eine Python-DoFn schlug mit dem Fehler <Fehlermeldung> fehl

Wenn eine in Python implementierte DoFn fehlschlägt und eine Ausnahme auslöst, wird eine entsprechende Fehlermeldung angezeigt.

Maximieren Sie den Eintrag im Stackdriver-Fehlerlogeintrag und sehen Sie sich die Fehlermeldung und das Traceback an. Dort erfahren Sie, welcher Code fehlgeschlagen ist, sodass Sie ihn gegebenenfalls korrigieren können. Wenn Sie einen Programmfehler in Apache Beam oder Dataflow vermuten, melden Sie diesen Programmfehler.

Kein Speicherplatz mehr auf dem Gerät

Wenn ein Job eine große Datenmenge mit der Shuffle-Funktion umverteilt oder temporäre Daten auf lokale Laufwerke schreibt, kann der freie Speicherplatz im nichtflüchtigen Speicher des Workers erschöpft sein.

Wenn Sie in einer Meldung darauf hingewiesen werden, dass auf dem Gerät kein Speicherplatz mehr verfügbar ist, erhöhen Sie die Größe der nichtflüchtigen Speicher Ihrer Worker mithilfe der entsprechenden Pipelineoption. Verwenden Sie für Java-Jobs das Flag --diskSizeGb. Verwenden Sie für Python-Jobs --disk_size_gb.

Speicherplatzfehler wie RESOURCE_EXHAUSTED: E-/A-Fehler: Kein Speicherplatz mehr auf dem Laufwerk"

Diese Fehler deuten in der Regel darauf hin, dass nicht genügend lokaler Speicherplatz zugewiesen wurde, um einen Job zu verarbeiten. Wenn Sie Ihren Job mit Standardeinstellungen ausführen, wird er auf drei Workern mit jeweils 25 GB lokalem Speicherplatz ohne Autoscaling ausgeführt. Ändern Sie gegebenenfalls die Standardeinstellungen, um die Anzahl der für den Job verfügbaren Worker oder die standardmäßige Laufwerkgröße pro Worker zu erhöhen bzw. Autoscaling zu aktivieren.

Warnungen vom Typ "Fehlerhafte Anfrage" in Shuffler-Logs

Während der Ausführung eines Dataflow-Jobs werden in Stackdriver-Logs möglicherweise verschiedene Warnungen ähnlich den folgenden angezeigt:

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
    

Warnungen vom Typ "Fehlerhafte Anfrage" werden angezeigt, wenn die Informationen zum Worker-Status aufgrund von Verarbeitungsverzögerungen veraltet oder nicht synchron sind. Oft wird der Dataflow-Job trotz dieser Warnungen vom Typ "Fehlerhafte Anfrage" erfolgreich ausgeführt. Ignorieren Sie in diesem Fall einfach die Warnungen.

In Schritt <step_id> wurde ein "heißer" Schlüssel mit einem Alter von <time_interval> s erkannt.

Diese Fehler weisen darauf hin, dass Sie einen "heißen" Schlüssel haben. Ein "heißer" Schlüssel ist ein Schlüssel mit so vielen Elementen, dass es sich negativ auf die Pipeline-Leistung auswirkt. Diese Schlüssel begrenzen die Möglichkeit von Dataflow, Elemente parallel zu verarbeiten, was die Ausführungszeit erhöht.

Prüfen Sie, ob Ihre Daten gleichmäßig verteilt sind. Wenn ein Schlüssel unverhältnismäßig viele Werte enthält, sollten Sie die folgenden Vorgehensweisen berücksichtigen: