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 im Job-Diagramm eine Benachrichtigung angezeigt und im Bereich „Schrittinformationen“ werden die Art des Engpasses und die Ursache (falls bekannt) aufgeführt. Dataflow exportiert auch Informationen zur Engpasserkennung in einen Stackdriver-Messwert, der die Daten als Zeitreihe darstellt. So können Sie Engpässe im Zeitverlauf oder in der Vergangenheit ansehen.

Engpässe erkennen

Wenn Dataflow eine Streamingpipeline ausführt, besteht der Job aus einer Reihe von Komponenten, z. B. Streaming-Shuffles, Verarbeitungs-Threads für benutzerdefinierte Funktionen (DoFn) und Checkpointing für persistenten Status. Um den Datenfluss zu ermöglichen, verwendet Dataflow Warteschlangen, um diese Komponenten zu verbinden. Daten werden von vorgelagerten zu nachgelagerten Komponenten übertragen.

In vielen Pipelines wird die Gesamtdurchsatzkapazität durch eine einzelne Komponente begrenzt, wodurch ein Engpass in der Pipeline entsteht. Die Geschwindigkeit, mit der Daten einen Engpass durchlaufen können, begrenzt, wie schnell die Pipeline Eingabedaten annehmen und verarbeiten kann.

Stellen Sie sich beispielsweise eine Pipeline vor, in der die Verarbeitung von DoFn nach einem Streaming-Shuffle erfolgt. Ein Puffer zwischen ihnen speichert die gemischten, aber noch nicht verarbeiteten Daten. Wenn die DoFn-Verarbeitung Daten nicht so schnell verarbeiten kann, wie sie durch das Streaming-Shuffle erzeugt werden, wächst die Warteschlange. Ein längerer Engpass kann dazu führen, dass die Warteschlange ihre Kapazität erreicht. An diesem Punkt wird das weitere Shuffling pausiert und der Backlog wird nach oben weitergegeben. Auch in Queues weiter oben in der Pipeline sammeln sich Rückstände an, was schließlich zu einer Verlangsamung führt, die sich bis zur Datenquelle auswirkt. Die gesamte Pipeline kann dann nicht mehr mit der Eingabe Schritt halten.

Wenn ein Engpass auftritt, kann ein erheblicher Teil der Pipeline als fehlerhaft angezeigt werden, obwohl nur ein einzelner Punkt in der Pipeline den Rückstand verursacht. Dieses Verhalten kann die Fehlersuche bei Engpässen erschweren. Ziel der Engpasserkennung ist es, die genaue Position und Ursache zu ermitteln, damit Sie die Grundursache beheben können.

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

Die Engpasserkennung erfordert nicht immer, dass Sie Maßnahmen ergreifen. Das hängt von Ihrem Anwendungsfall ab. Eine Pipeline kann auch bei 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 in der Monitoring-Oberfläche der Schweregrad des Problems angegeben. Engpässe lassen sich in die folgenden Kategorien einteilen:

Verarbeitung hängt und macht keinen Fortschritt
Der Fortschritt der Pipeline wird in diesem Schritt vollständig angehalten.
Verarbeitung läuft, gerät aber in Verzug.
Die Pipeline kann eingehende Daten nicht so schnell verarbeiten, wie sie eingehen. Dadurch wächst der Rückstand.
Verarbeitung läuft, aber Rückstand bleibt unverändert
Die Pipeline wird ausgeführt und die Verarbeitungsrate ist mit der Eingaberate vergleichbar. Die Verarbeitung ist schnell genug, damit der Rückstand nicht wächst, aber der angesammelte Rückstand nimmt auch nicht deutlich ab.
Die Verarbeitung läuft und holt Rückstand auf.
Der Rückstand wird geringer, aber der aktuelle Engpass verhindert, dass die Pipeline schneller aufholt. Wenn Sie eine Pipeline mit einem Rückstand starten, ist dieser Status möglicherweise normal und es ist kein Eingreifen erforderlich. Behalten Sie den Fortschritt im Blick, um zu sehen, ob das Backlog weiter abnimmt.

Ursachen von Engpässen

Auf der Monitoring-Oberfläche wird die Ursache des Engpasses angezeigt, sofern bekannt. Anhand dieser Informationen können Sie das Problem beheben.

Vorgänge mit langer Verarbeitungszeit

Die Berechnung dauert lange. Dieser Fehler tritt auf, wenn ein Eingabebündel an den Worker gesendet wird, der den DoFn ausführt, und viel Zeit vergeht, ohne dass Ergebnisse verfügbar sind.

Das ist meistens das Ergebnis eines einzelnen lang andauernden Vorgangs im Nutzercode. Andere Probleme können sich in Form von Vorgängen mit langer Verarbeitungszeit äußern. Beispiele hierfür sind Fehler, die innerhalb von DoFn ausgegeben und wiederholt werden, Wiederholungsversuche über einen langen Zeitraum oder Abstürze des Worker-Harness aufgrund von Faktoren wie OOMs.

Wenn die betroffene Berechnung im Nutzercode erfolgt, suchen Sie nach Möglichkeiten, den Code zu optimieren oder die Ausführungszeit zu begrenzen. Zur Unterstützung beim Debugging enthalten die Worker-Logs Stacktraces für alle Vorgänge, die länger als 5 Minuten hängen bleiben.

Langsamer Lesevorgang des nichtflüchtigen Zustands

Bei der Berechnung wird ein erheblicher Teil der Zeit mit dem Lesen des persistenten Status im Rahmen der Ausführung von DoFn verbracht. Dies kann die Folge eines zu großen nichtflüchtigen Status oder zu vieler Lesevorgänge sein. Reduzieren Sie gegebenenfalls die Größe des persistenten Status oder die Häufigkeit der Lesevorgänge. Dies kann auch ein vorübergehendes Problem sein, das durch die Langsamkeit des zugrunde liegenden persistenten Status verursacht wird.

Langsamer Schreibvorgang des nichtflüchtigen Zustands

Bei der Berechnung wird viel Zeit damit verbracht, den persistenten Status während des Commits der Verarbeitungsergebnisse zu schreiben. Dies kann die Folge eines zu großen persistenten Status sein. Reduzieren Sie die Größe des persistenten Status. Möglicherweise handelt es sich auch um ein vorübergehendes Problem aufgrund der Langsamkeit des zugrunde liegenden persistenten Status.

Abgelehnter Commit

Die Datenverarbeitung kann aufgrund ungültiger Daten nicht in den persistenten Status übernommen werden. Das liegt in der Regel daran, dass eines der betrieblichen Limits überschritten wurde. Weitere Informationen finden Sie in den Logs. Alternativ können Sie sich an den Support wenden.

Unzureichende Apache Kafka-Quellpartitionen

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

  • Erhöhen Sie die Anzahl der Kafka-Partitionen.
  • Verwenden Sie eine Redistribute-Transformation, um die Daten effizienter neu zu verteilen und zu parallelisieren.

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

Unzureichende Quellparallelität

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

„Heiße“ Schlüssel oder unzureichende Schlüsselparallelität

Für den Job sind „heiße“ Schlüssel oder eine unzureichende Schlüsselparallelität vorhanden.

Für jeden Sharding-Schlüssel verarbeitet Dataflow Nachrichten seriell. 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 sind möglicherweise zu wenige eindeutige Schlüssel vorhanden oder bestimmte Schlüssel sind in den Daten überrepräsentiert („Hotkeys“). Weitere Informationen finden Sie unter Fehlerbehebung bei langsamen oder hängenden Streamingjobs.

Unterdimensionierte vCPUs

Der Job hat nicht genügend Worker-vCPUs. Diese Situation tritt ein, wenn der Job bereits auf das Maximum skaliert wurde, die vCPU-Auslastung hoch ist und es immer noch einen Rückstand gibt. Möglicherweise müssen Sie die maximale Anzahl der für diesen Job bereitgestellten Worker erhöhen. Sie können diese Zahl beispielsweise durch eine Aktualisierung des Autoscaling-Bereichs erhöhen. Alternativ können Sie nach Möglichkeiten suchen, die vCPU-Auslastung durch Änderungen am Pipelinecode oder an der Arbeitslast zu verringern. Mit dem 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 noch Spielraum für eine Hochskalierung. Dieser Zustand ist wahrscheinlich vorübergehend, bis die Aufskalierung erfolgen kann. Sie können das Autoscaling überwachen, um die Autoscaling-Entscheidungen zu sehen. Wenn dieser Zustand über einen längeren Zeitraum anhält oder häufig auftritt, müssen Sie möglicherweise die Autoscaling-Konfiguration ändern, indem Sie einen anderen Hinweis zur Worker-Auslastung festlegen, damit der Job proaktiver skaliert wird.

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 während der Ausführung des Jobs gelöscht.
  • Netzwerkprobleme.
Die Pub/Sub-Quelle hat Pull-Fehler.

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

Pub/Sub-Quelle hat unzureichende Parallelität

Für die Berechnung der Pub/Sub-Quelle ist eine unzureichende Anzahl von Pub/Sub-Schlüsseln vorhanden. Wenn Sie diese Warnung sehen, wenden Sie sich an den Support.

Pub/Sub-Quelle aus unbekanntem Grund gedrosselt

Die Berechnung der Pub/Sub-Quelle wird beim Lesen aus Pub/Sub aus unbekanntem Grund gedrosselt. Möglicherweise ist das ein vorübergehendes Problem. Prüfen Sie, ob es Probleme mit der Pub/Sub-Konfiguration, fehlende IAM-Berechtigungen oder Kontingentlimits gibt. Wenn keiner der oben genannten 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 Arbeitswarteschlangenzeit

Das älteste zulässige Arbeitsalter ist hoch, da eine große Anzahl von Schlüsseln vorhanden ist und die Schlüssel langsam verarbeitet werden. In diesem Fall dauert jeder Vorgang möglicherweise nicht ungewöhnlich lange, aber die gesamte Wartezeit ist hoch.

Dataflow verwendet einen einzelnen Verarbeitungsthread pro Sharding-Schlüssel und die Anzahl der Verarbeitungsthreads ist begrenzt. Die Warteschlangendelay entspricht ungefähr dem Verhältnis von Schlüsseln zu Threads multipliziert mit der On-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 numberOfWorkerHarnessThreads- / number_of_worker_harness_threads-Pipelineoption fest.
  • Verringern Sie die Anzahl der Schlüssel.
  • Die Latenz des Vorgangs verringern.
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. Wenn das Problem weiterhin besteht, wenden Sie sich an den Support.

Nächste Schritte