Engpässe in Dataflow beheben

Ein Engpass tritt auf, wenn ein Schritt, eine Phase oder ein Worker den gesamten Job verlangsamt. Engpässe können zu inaktiven Workern und erhöhter Latenz führen.

Wenn Dataflow einen Engpass erkennt, wird in der Jobgrafik eine Warnung angezeigt. Im Bereich Schrittinformationen werden die Art des Engpasses und die Ursache aufgeführt, sofern bekannt. Dataflow exportiert auch Informationen zur Engpasserkennung in einen Monitoring-Messwert, der die Daten als Zeitachse darstellt. So können Sie Engpässe im Zeitverlauf oder in der Vergangenheit sehen.

Engpässe verstehen

Wenn Dataflow eine Streamingpipeline ausführt, besteht der Job aus einer Reihe von Komponenten, z. B. Streaming-Shuffles, Verarbeitungsthreads für benutzerdefinierte Funktionen (DoFn) und Prüfpunkten für den nichtflüchtigen Zustand. Um den Datenfluss zu erleichtern, verwendet Dataflow Warteschlangen, um diese Komponenten zu verbinden. Daten werden von Upstream zu Downstream übertragen.

In vielen Pipelines wird die Gesamtdurchsatzkapazität durch eine einzelne Komponente eingeschränkt, was zu einem Engpass in der Pipeline führt. Die Rate, mit der Daten einen Engpass passieren können, begrenzt, wie schnell die Pipeline Eingabedaten annehmen und verarbeiten kann.

Betrachten Sie beispielsweise eine Pipeline, in der die DoFn-Verarbeitung nach einem Streaming-Shuffle erfolgt. Eine Warteschlange zwischen ihnen puffert die gemischten, aber unverarbeiteten Daten. Wenn die DoFn-Verarbeitung Daten nicht so schnell verarbeiten kann, wie sie von der Streaming-Zufallsmischung erzeugt werden, wächst die Warteschlange. Ein anhaltender Engpass kann dazu führen, dass die Warteschlange ihre Kapazität erreicht. An diesem Punkt wird das weitere Shuffling pausiert und der Rückstand wird vorgelagert weitergegeben. Auch in vorgelagerten Warteschlangen kommt es zu Rückständen, was schließlich zu einer Verlangsamung führt, die sich bis zur Datenquelle erstreckt. Das bedeutet, dass die gesamte Pipeline nicht mit der Eingabe Schritt halten kann.

Wenn ein Engpass auftritt, kann ein erheblicher Teil der Pipeline fehlerhaft erscheinen, obwohl der Rückstand nur durch einen einzigen Punkt in der Pipeline verursacht wird. Dieses Verhalten kann das Debuggen von Engpässen erschweren. Das Ziel der Engpasserkennung ist es, den genauen Standort und die Ursache zu ermitteln, um Vermutungen zu vermeiden und die Ursache zu beheben.

Dataflow erkennt einen Engpass, wenn eine Verzögerung den Schwellenwert von fünf Minuten überschreitet. Wenn die Verzögerung diesen Schwellenwert nicht überschreitet, erkennt Dataflow keinen Engpass.

Die Engpasserkennung erfordert nicht immer Maßnahmen und hängt von Ihrem Anwendungsfall ab. Eine Pipeline kann mit vorübergehenden Verzögerungen von mehr als fünf Minuten normal funktionieren. Wenn dies für Ihren Anwendungsfall akzeptabel ist, müssen Sie die angegebenen Engpässe möglicherweise nicht beheben.

Arten von Engpässen

Wenn Dataflow einen Engpass erkennt, wird der Schweregrad des Problems auf der Monitoring-Oberfläche angezeigt. Engpässe fallen in die folgenden Kategorien:

Verarbeitung hängt und macht keinen Fortschritt
Der Fortschritt der Pipeline wird bei diesem Schritt vollständig angehalten.
Verarbeitung läuft, gerät aber in Verzug.
Die Pipeline kann eingehende Daten nicht so schnell verarbeiten, wie sie ankommen. Der Rückstand wächst dadurch.
Verarbeitung läuft, aber Rückstand bleibt unverändert
Die Pipeline macht Fortschritte und die Verarbeitungsrate ist mit der Eingaberate vergleichbar. Die Verarbeitung ist schnell genug, sodass der Rückstand nicht wächst, aber der akkumulierte Rückstand nimmt auch nicht wesentlich ab.
Verarbeitung läuft und holt Rückstand auf
Der Rückstand nimmt ab, aber der aktuelle Engpass verhindert, dass die Pipeline schneller aufholt. Wenn Sie eine Pipeline mit einem Rückstand starten, ist dieser Zustand möglicherweise normal und erfordert kein Eingreifen. Beobachten Sie den Fortschritt, um zu sehen, ob der Rückstand weiter abnimmt.

Ursachen von Engpässen

In diesem Abschnitt werden die Ursachen für Engpässe aufgeführt, die erkannt werden können. Verwenden Sie diese Informationen, um das Problem zu beheben. In einigen Fällen können mehrere Ursachen vorliegen, die möglicherweise zusammenhängen. Wenn Worker beispielsweise unterdimensioniert sind, kann die vCPU-Auslastung hoch sein. Eine hohe vCPU-Auslastung kann dazu führen, dass Vorgänge langsamer ausgeführt werden, was wiederum zu einer erhöhten Warteschlangenverzögerung führen kann. In der Analyse der wahrscheinlichen Ursachen werden möglicherweise alle diese Ursachen als Ursachen des Engpasses angezeigt.

Vorgänge mit langer Verarbeitungszeit

Einige Vorgänge in dieser Berechnung haben eine lange Verarbeitungszeit. Dies geschieht immer dann, wenn ein Eingabe-Bundle an den Worker gesendet wird, der die DoFn ausführt, und eine erhebliche Zeit verstrichen ist, ohne dass Ergebnisse verfügbar sind.

Dies ist meist das Ergebnis eines einzelnen Vorgangs mit langer Ausführungszeit im Nutzercode. Andere Probleme können sich als Vorgänge mit langer Verarbeitungszeit äußern. Diese langen Verarbeitungszeiten können beispielsweise durch Fehler verursacht werden, die innerhalb des DoFn ausgelöst und wiederholt werden, durch Wiederholungen über lange Zeiträume oder durch Abstürze des Worker-Harnesses aufgrund von Faktoren wie OOMs.

Wenn sich die betroffene Berechnung im Nutzercode befindet, suchen Sie nach Möglichkeiten, den Code zu optimieren oder die Ausführungszeit zu begrenzen. Zur Unterstützung bei der Fehlerbehebung werden in den Worker-Logs Stacktraces für alle Vorgänge angezeigt, die länger als 5 Minuten hängen.

Schlüssel-Commit zu groß

Weitere Informationen finden Sie unter Ausnahme „Schlüssel-Commit zu groß“.

BigQuery-Senkenberechtigung verweigert

Dieser Fehler weist darauf hin, dass das Dienstkonto, mit dem die Pipeline ausgeführt wird, nicht die erforderlichen Berechtigungen zum Schreiben in die BigQuery-Ressource hat.

So prüfen Sie dieses Problem anhand von Worker-Logs:

  1. Öffnen Sie in der Google Cloud Console die Seite Dataflow-Jobdetails.
  2. Klicken Sie im unteren Bereich auf den Tab Logs und wählen Sie Worker-Logs aus.
  3. Suchen Sie nach Fehlermeldungen, die darauf hindeuten, dass Berechtigungen oder der Zugriff verweigert wurden (z. B. PERMISSION_DENIED, 403 Forbidden, Access Denied oder actuallyForbidden).
  4. Prüfen Sie den Logeintrag, um das Ziel-Dataset oder die Zieltabelle und die spezifische fehlende Berechtigung (z. B. bigquery.tables.updateData) zu ermitteln.

So lösen Sie dieses Problem:

  • Prüfen Sie, ob dem Dienstkonto die Rolle BigQuery-Datenbearbeiter (roles/bigquery.dataEditor) für das Ziel-Dataset und die Zieltabelle zugewiesen wurde.
  • Wenn Sie projektübergreifend schreiben, müssen Sie dem Dienstkonto die Berechtigungen direkt im Zielprojekt erteilen, in dem das BigQuery-Dataset gehostet wird. Außerdem muss VPC Service Controls (falls aktiviert) die Kommunikation zwischen beiden Projekten zulassen.

Wenn das Problem durch diese Schritte nicht behoben wird, finden Sie unter Vordefinierte Rollen und Berechtigungen für BigQuery Informationen dazu, wie Sie fehlende detaillierte Berechtigungen für Ihre spezifische Konfiguration identifizieren und gewähren können.

BigQuery-Senkenressource erschöpft

Dieser Fehler weist darauf hin, dass die Pipeline ein BigQuery-Kontingentlimit überschritten hat. Die wahrscheinlichste Ursache ist ein unzureichendes Kontingent im BigQuery-Zielprojekt, um die Menge der geschriebenen Daten zu verarbeiten.

So prüfen Sie dieses Problem anhand von Worker-Logs:

  1. Öffnen Sie in der Google Cloud Console die Seite Dataflow-Jobdetails.
  2. Klicken Sie im unteren Bereich auf den Tab Logs und wählen Sie Worker-Logs aus.
  3. Suchen Sie nach Fehlermeldungen, die darauf hinweisen, dass Ressourcen oder Kontingente erschöpft sind oder Ratenbegrenzungen überschritten wurden (z. B. RESOURCE_EXHAUSTED, 429 Too Many Requests, quotaExceeded oder rateLimitExceeded).
  4. Prüfen Sie den Logeintrag, um festzustellen, welcher Vorgang und welches Kontingentlimit überschritten wurde (z. B. Durchsatz- oder Verbindungslimits der Storage Write API AppendRows oder Ratenbegrenzungen für Streaming-Insert-Anweisungen).

So lösen Sie dieses Problem:

  • Ermitteln Sie, welche BigQuery-Senkenimplementierung Ihre Pipeline verwendet (z. B. die Storage Write API oder Streaming-Insert-Anweisungen).
  • Prüfen Sie Ihre BigQuery-Kontingentnutzung in der Google Cloud Console. Suchen Sie insbesondere nach Kontingenten, die sich auf Ihren Senkentyp beziehen, z. B. gleichzeitige Verbindungen, Durchsatz oder Streaming-Insert-Zeilen pro Sekunde.
  • Wenn Sie diese Limits regelmäßig erreichen oder überschreiten, sollten Sie eine Kontingenterhöhung beantragen.

Wenn sich mit diesen Schritten nicht feststellen lässt, welches Limit überschritten wurde, finden Sie unter Kontingent- und Limitfehler beheben weitere Informationen.

RPC-Fehler bei BigQuery-Senke

Dieser Fehler weist darauf hin, dass RPC-Anfragen von der Pipeline an BigQuery fehlschlagen. Mögliche Ursachen sind vorübergehende Netzwerk- oder Dienstprobleme, ungültige Anfrage-Nutzlasten, Schemaabweichungen oder Fehler aufgrund von Zeitüberschreitungen und Fristüberschreitungen.

So prüfen Sie dieses Problem anhand von Worker-Logs:

  1. Öffnen Sie in der Google Cloud Console die Seite Dataflow-Jobdetails.
  2. Klicken Sie im unteren Bereich auf den Tab Logs und wählen Sie Worker-Logs aus.
  3. Suchen Sie nach Fehlermeldungen oder Ausnahmen im Zusammenhang mit BigQuery-Schreibvorgängen (z. B. DEADLINE_EXCEEDED, UNAVAILABLE, INVALID_ARGUMENT oder Schemavalidierungsfehler).
  4. Prüfen Sie den Stacktrace und die Fehlermeldung, um den spezifischen Fehlermodus zu ermitteln, der von der BigQuery API zurückgegeben wird.

So lösen Sie dieses Problem:

  • Sobald Sie die spezifische Fehlermeldung oder den Statuscode in den Worker-Logs identifiziert haben, finden Sie in der Referenz zu BigQuery-Fehlermeldungen eine Anleitung zur Fehlerbehebung für diesen Fehler.
  • Wenn Ihre Pipeline die Storage Write API verwendet, finden Sie in der BigQuery Storage Write API-Dokumentation unter Fehlerbehandlung Informationen zur Behandlung bestimmter Schreib- und Streamfehler.
BigQuery-Senke gedrosselt

Diese Ursache weist darauf hin, dass Schreibanfragen von der Pipeline an BigQuery erfolgreich sind, aber eine hohe Latenz oder Drosselung aufweisen. Dieses Problem tritt auf, wenn die Pipeline die BigQuery-Durchsatz- oder In-Flight-Byte-Kontingente erreicht und BigQuery Schreibanfragen verlangsamt, um den Traffic zu regulieren, oder wenn BigQuery eine erhöhte Backend-Latenz aufweist.

So prüfen Sie das Problem:

  1. Öffnen Sie in der Google Cloud Console die Seite Dataflow-Jobdetails.
  2. Klicken Sie auf den Tab Jobmesswerte oder Schrittinformationen, um zu prüfen, ob die Verarbeitungszeit für den BigQuery-Senkenschritt erhöht ist.
  3. Öffnen Sie in der Google Cloud Console die Seite Kontingente und Systemlimits für das BigQuery-Zielprojekt und prüfen Sie, ob Ihre Nutzung sich den BigQuery-Schreibkontingenten nähert.

So lösen Sie dieses Problem:

  • Ermitteln Sie, welche BigQuery-Senkenimplementierung Ihre Pipeline verwendet, z. B. die Storage Write API oder Streaming-Insert-Anweisungen.
  • Prüfen Sie Ihre BigQuery-Kontingentnutzung in der Google Cloud Console. Suchen Sie insbesondere nach Kontingenten, die sich auf Ihren Senkentyp beziehen, z. B. Durchsatz für das Anhängen von Daten über die Storage Write API, gleichzeitige Verbindungen oder Zeilen pro Sekunde für Streaming-Insert-Anweisungen. Auch wenn Anfragen nicht mit expliziten Kontingentfehlern fehlschlagen, kann BigQuery Anfragen drosseln, wenn die Nutzung sich den Kontingentlimits nähert.
  • Wenn Sie diese Limits regelmäßig erreichen, sollten Sie eine Kontingenterhöhung beantragen.

Wenn Sie mit diesen Schritten nicht das spezifische Limit ermitteln können, das erreicht wird, finden Sie weitere Informationen unter Kontingent- und Limitfehler beheben.

Lange Verarbeitungszeit für alle Vorgänge

Vorgänge in dieser Berechnung dauern durchgehend lange, was auf ein Problem mit dem vom Nutzer bereitgestellten DoFn hindeutet.

Diese Ursache unterscheidet sich von Vorgängen mit langer Verarbeitungszeit. Während diese Ursache einige Vorgänge betrifft, weist diese Ursache darauf hin, dass alle Vorgänge in dieser Berechnung betroffen sind.

Prüfen Sie die Worker-Logs auf Fehler, Ausnahmen oder Stacktraces, die auf langsame oder hängende Threads hinweisen. Wenn Sie das Apache Beam SDK für Python verwenden und die Vorgänge von Natur aus langwierig sind (z. B. langsame externe API-Aufrufe oder E/A mit hoher Latenz), sollten Sie eine asynchrone DoFn verwenden. Diese Funktion kann den Durchsatz verbessern, da die Verarbeitung bei diesen lang andauernden Aufgaben nicht blockiert wird.

Langsamer Lesevorgang des nichtflüchtigen Zustands

Die Berechnung verbringt viel Zeit damit, den nichtflüchtigen Zustand im Rahmen der Ausführung von DoFn zu lesen. Dies kann das Ergebnis eines übermäßig großen nichtflüchtigen Status oder zu vieler Lesevorgänge sein. Sie können die Größe des persistenten Status oder die Häufigkeit der Lesevorgänge reduzieren. Optimieren Sie die Zugriffsmuster für den Status, indem Sie mehrere Lesevorgänge für den Status kombinieren oder gegebenenfalls den Map-Status anstelle des Wertstatus verwenden. Dies kann auch ein vorübergehendes Problem sein, das auf die Langsamkeit des zugrunde liegenden nichtflüchtigen Zustands zurückzuführen ist.

Langsamer Schreibvorgang des nichtflüchtigen Zustands

Die Berechnung verbringt viel Zeit damit, den persistenten Status während des Commits der Verarbeitungsergebnisse zu schreiben. Dies kann die Folge eines übermäßig großen nichtflüchtigen Zustands sein. Sie können die Größe des persistenten Status reduzieren. Optimieren Sie die Zugriffsmuster für den Status, indem Sie gegebenenfalls mehrere Schreibvorgänge für den Status kombinieren. Dies kann auch ein vorübergehendes Problem sein, das auf die Langsamkeit des zugrunde liegenden nichtflüchtigen Zustands zurückzuführen ist.

Abgelehnter Commit

Die Datenverarbeitung kann aufgrund eines ungültigen Status nicht in den persistenten Status übernommen werden. Dies liegt in der Regel daran, dass eines der Betriebslimits überschritten wurde. Weitere Informationen finden Sie in den Logs. Sie können sich auch an den Support wenden.

Unzureichende Apache Kafka-Quellpartitionen

Die Apache Kafka-Quellberechnung hat nicht genügend Partitionen. Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Erhöhen Sie die Anzahl der Kafka-Partitionen.
  • Verwenden Sie beim Konfigurieren des Kafka-IO-Lesevorgangs .withRedistribute(), um die Daten effizienter zu parallelisieren. Geben Sie .withRedistributeNumKeys(N) an, wobei N > partitions eine Obergrenze für die Gesamtzahl der Schlüssel angibt. Eine begrenzte Anzahl von Schlüsseln sorgt für Effizienz durch die Bündelung von Datensätzen.
  • Verwenden Sie .withOffsetDeduplication(), um die Kosten für die Umverteilung zu minimieren. In diesem Modus wird die Datenmenge minimiert, die im Rahmen der Umverteilung beibehalten werden muss, während gleichzeitig eine Exactly-Once-Verarbeitung gewährleistet wird.

Weitere Informationen finden Sie unter Parallelität auf der Seite Aus Apache Kafka in Dataflow lesen.

Apache Kafka-Quelle mit großem Volumen an persistiertem Status

Die Apache Kafka-Quellberechnung verteilt ein hohes Datenvolumen neu, was zu hoher Latenz und hohen Kosten führen kann. Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Wenn für die Pipeline eine genau einmalige Verarbeitung erforderlich ist, können Sie die Kosten für die Neuverteilung minimieren, indem Sie den Offset-Deduplizierungsmodus verwenden. In diesem Modus wird die Datenmenge minimiert, die im Rahmen der Umverteilung beibehalten werden muss, während gleichzeitig eine Exactly-Once-Verarbeitung gewährleistet wird.
  • Wenn die „Mindestens einmal“-Verarbeitung für die Pipeline ausreicht, kann die Konfiguration Duplikate zulassen aktiviert werden.

Weitere Informationen finden Sie unter Aus Apache Kafka in Dataflow lesen.

Unzureichende Quellparallelität

Eine Quellberechnung hat unzureichende Parallelität. Erhöhen Sie nach Möglichkeit die Parallelisierung innerhalb der Quelle. Wenn Sie die Parallelisierung nicht erhöhen können und der Job den Modus „Mindestens einmal“ verwendet, fügen Sie der Pipeline eine Redistribute-Transformation hinzu.

Übergroße Schlüssel oder unzureichende Schlüsselparallelität

Der Job hat übergroße Schlüssel oder unzureichende Schlüsselparallelität.

Dataflow verarbeitet Nachrichten für jeden Sharding-Schlüssel nacheinander. Während Dataflow einen Batch von Nachrichten für einen bestimmten Schlüssel verarbeitet, werden andere eingehende Nachrichten für diesen Schlüssel in die Warteschlange gestellt, bis der aktuelle Batch abgeschlossen ist.

Wenn Dataflow nicht genügend unterschiedliche Schlüssel parallel verarbeiten kann, kann dies zu einem Engpass führen. Beispielsweise können die Daten zu wenige unterschiedliche Schlüssel enthalten oder bestimmte Schlüssel sind in den Daten überrepräsentiert („übergroße Schlüssel“). Ändern Sie die Pipelinelogik, um die Daten neu zu verteilen. Fügen Sie beispielsweise den Gruppierungsschlüsseln ein zufälliges Suffix hinzu, um übergroße Schlüssel aufzuteilen, und aggregieren Sie die Ergebnisse in einem nachfolgenden Schritt. Weitere Informationen finden Sie unter Fehlerbehebung bei übergroßen Schlüsseln.

Unterdimensionierte vCPUs

Der Job hat nicht genügend Worker-vCPUs. Diese Situation tritt auf, wenn der Job bereits auf das Maximum skaliert ist, die vCPU-Auslastung hoch ist und noch ein Rückstand besteht. Möglicherweise müssen Sie die maximale Anzahl der für diesen Job bereitgestellten Worker erhöhen. Sie können diese Anzahl beispielsweise durch ein Update des Autoscaling-Bereichs erhöhen. Alternativ können Sie nach Möglichkeiten suchen, die vCPU-Nutzung durch Änderungen am Pipelinecode oder an der Arbeitslast zu verringern. Mit Cloud Profiler können Sie nach Optimierungsmöglichkeiten suchen.

Hohe vCPU-Auslastung. Warten auf Hochskalierung

Der Job hat eine hohe vCPU-Auslastung, aber es gibt Raum für eine Hochskalierung. Dieser Zustand ist wahrscheinlich vorübergehend, bis eine Hochskalierung erfolgen kann. Sie können das Autoscaling überwachen, um die Autoscaling-Entscheidungen zu sehen. Wenn dieser Zustand lange anhält oder häufig auftritt, müssen Sie möglicherweise die Konfiguration für das Autoscaling ändern. Legen Sie dazu einen anderen Hinweis zur Worker-Auslastung fest, damit der Job proaktiver hochskaliert werden kann.

Unausgewogene vCPU-Auslastung verursacht Engpässe bei einigen Ausreißer-Workern

Der Job hat genügend Worker-vCPUs, aber einige Worker weisen eine sehr hohe vCPU-Auslastung auf. Dies wird häufig durch eine ungleichmäßige Arbeitsverteilung verursacht. Mögliche Ursachen sind ungleichmäßig geladene Quellpartitionen oder übergroße Schlüssel.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Ermitteln Sie die Ursache für die ungleichmäßige Belastung und versuchen Sie, sie zu beheben. Achten Sie beispielsweise darauf, dass die Quellpartitionen gleichmäßig verteilt sind.
  • Wenn es nicht möglich ist, die ungleichmäßige Auslastung zu korrigieren, sollten Sie die Worker-VM-Form ändern, um die Anzahl der vCPUs pro Worker zu erhöhen und die Spitzenauslastung zu senken. Weitere Informationen zum Konfigurieren von vCPUs pro Worker finden Sie unter Dataflow-Worker-VMs konfigurieren.
Problem bei der Kommunikation mit Workern

Dataflow kann nicht mit allen Worker-VMs kommunizieren. Prüfen Sie den Status der Worker-VMs des Jobs. Hier einige Gründe dafür:

  • Beim Bereitstellen der Worker-VMs ist ein Problem aufgetreten.
  • Der Worker-VM-Pool wird gelöscht, während der Job ausgeführt wird.
  • Netzwerkprobleme.
Pub/Sub-Quelle hat Pull-Fehler.

Beim Abrufen aus der Pub/Sub-Quelle sind Fehler aufgetreten. Prüfen Sie, ob das erforderliche Thema und die erforderlichen Abos vorhanden sind, und prüfen Sie das Kontingent und die Konfiguration. Sie können die Logs auch auf Fehler prüfen.

Pub/Sub-Quelle hat unzureichende Parallelität

Die Pub/Sub-Quellberechnung hat eine unzureichende Anzahl von Pub/Sub-Schlüsseln. Wenn Sie die Anzahl der Schlüssel erhöhen möchten, legen Sie die Dienstoption num_pubsub_keys fest. Weitere Informationen finden Sie unter Pub/Sub-Quellparallelität.

Pub/Sub-Quelle aus unbekanntem Grund gedrosselt

Die Pub/Sub-Quellberechnung wird aus einem unbekannten Grund beim Lesen aus Pub/Sub gedrosselt. Möglicherweise ist das ein vorübergehendes Problem. Prüfen Sie, ob Pub/Sub-Konfigurationsprobleme, fehlende IAM-Berechtigungen oder Kontingentlimits vorliegen. Wenn jedoch keiner der vorherigen Bereiche die Ursache ist und das Problem weiterhin besteht, wenden Sie sich an den Support.

Veröffentlichung von Pub/Sub-Senken langsam oder hängt

Die Berechnung der Pub/Sub-Senke ist langsam oder hängt. Dieses Problem kann durch ein Konfigurationsproblem oder ein Kontingentlimit verursacht werden.

Lange Wartezeit in der Arbeitswarteschlange

Das älteste infrage kommende Arbeitsalter ist hoch, da es eine große Anzahl von Schlüsseln gibt und die Schlüssel schnell verarbeitet werden. In dieser Situation ist die Dauer der einzelnen Vorgänge möglicherweise nicht ungewöhnlich lang, aber die Gesamtverzögerung in der Warteschlange ist hoch.

Dataflow verwendet einen einzelnen Verarbeitungsthread pro Sharding-Schlüssel und die Anzahl der Verarbeitungsthreads ist begrenzt. Die Warteschlangenverzögerung entspricht ungefähr dem Verhältnis von Schlüsseln zu Threads, multipliziert mit der Thread-Latenz für jedes Verarbeitungs-Bundle für einen Schlüssel:

(key count / total harness threads) * latency per bundle

Versuchen Sie Folgendes:

  • Erhöhen Sie die Anzahl der Worker. Weitere Informationen finden Sie unter Streaming-Autoscaling.
  • Erhöhen Sie die Anzahl der Worker-Harness-Threads. Legen Sie die Pipeline-Option numberOfWorkerHarnessThreads / number_of_worker_harness_threads fest.
  • Verringern Sie die Anzahl der Schlüssel.
  • Verringern Sie die Vorgangslatenz.
Vorübergehendes Problem mit dem Streaming Engine-Backend

Es gibt ein Konfigurations- oder Betriebsproblem mit dem Streaming Engine-Backend. Möglicherweise ist das ein vorübergehendes Problem. Sollte das Problem weiterhin auftreten, wenden Sie sich bitte an den Support.

Unbestimmbare Ursache

Die Ursache des Rückstands kann nicht mit Sicherheit ermittelt werden. Dieses Problem ist möglicherweise nur vorübergehend. Sollte das Problem weiterhin auftreten, wenden Sie sich bitte an den Support.

Engpassmesswerte

Die folgenden Jobmesswerte liefern Informationen zu Engpässen:

Nächste Schritte