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 den beiden 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. Bei einem längeren Engpass kann die Warteschlange ihre Kapazität erreichen. An diesem Punkt wird das weitere Shuffling pausiert und der Rückstand wird nach oben weitergegeben. Auch in Queues weiter oben in der Pipeline können sich Rückstände ansammeln, was schließlich zu einer Verlangsamung führt, die sich bis zur Datenquelle auswirkt. Das bedeutet, dass die gesamte Pipeline nicht mit der Eingabe mithalten kann.

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. Das 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 folgende Kategorien einteilen:

Verarbeitung hängt und macht keinen Fortschritt
Der Fortschritt der Pipeline wird an 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 macht Fortschritte und die Verarbeitungsrate ist mit der Eingaberate vergleichbar. Die Verarbeitung ist schnell genug, dass 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

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

Vorgänge mit langer Verarbeitungszeit

Die Berechnung dauert lange. Dieser Fehler tritt auf, wenn ein Eingabebündel an den Worker gesendet wird, der DoFn ausführt, und seitdem viel Zeit vergangen ist, 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. Möglicherweise handelt es sich auch um ein vorübergehendes Problem aufgrund der Langsamkeit des zugrunde liegenden persistenten Status.

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.
  • Fügen Sie .withRedistribute() in die Konfiguration von Kafka IO-Lesevorgängen ein, um die Daten effizienter zu parallelisieren. Fügen Sie .withRedistributeNumKeys(N) ein, wobei N > partitions eine Obergrenze für die Gesamtzahl der Schlüssel darstellt. 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 den Shuffle für die Neuverteilung zu minimieren. In diesem Modus wird die Datenmenge minimiert, die im Rahmen des Shuffles beibehalten werden muss, während die Verarbeitung genau einmal erfolgt.

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

Apache Kafka-Quelle mit großem Umfang an persistentem Status

Bei der Berechnung der Apache Kafka-Quelle wird ein hohes Datenvolumen neu verteilt, 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, minimieren Sie die Kosten für den Shuffle zur Neuverteilung, indem Sie den Offset-Deduplizierungsmodus verwenden. In diesem Modus wird die Datenmenge minimiert, die im Rahmen des Shuffles beibehalten werden muss, während die Verarbeitung genau einmal erfolgt.
  • Wenn die Verarbeitung mindestens einmal für die Pipeline ausreicht, kann die Konfiguration allow duplicates aktiviert werden.

Weitere Informationen finden Sie unter Daten aus Apache Kafka in Dataflow lesen.

Unzureichende Quellparallelität

Eine Quellberechnung hat eine 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 unterschiedliche Schlüssel vorhanden oder bestimmte Schlüssel sind in den Daten überrepräsentiert („Hot Keys“). Weitere Informationen finden Sie unter Fehlerbehebung bei langsamen oder hängenden Streamingjobs.

Unterdimensionierte vCPUs

Dem Job sind nicht genügend Worker-vCPUs zugewiesen. 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 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. Das liegt oft an einer ungleichmäßigen Arbeitsverteilung. Mögliche Ursachen sind ungleichmäßig geladene Quellpartitionen oder Hotkeys.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Ermitteln Sie die Ursache für die ungleichmäßige Beladung und versuchen Sie, das Problem zu beheben. Achten Sie beispielsweise darauf, dass die Quellpartitionen gleichmäßig verteilt sind.
  • Wenn es nicht möglich ist, die ungleichmäßige Last zu korrigieren, sollten Sie die Worker-VM-Form ändern, um die vCPUs pro Worker zu erhöhen und die Spitzenlast 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 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 die Anzahl der Schlüssel erhöhen möchten, legen Sie die Dienstoption num_pubsub_keys fest. Weitere Informationen finden Sie unter Pub/Sub-Quellenparallelität.

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 Wartezeit in der Arbeitswarteschlange

Das älteste infrage kommende Arbeitsalter ist hoch, da eine große Anzahl von Schlüsseln und die Geschwindigkeit, mit der Schlüssel verarbeitet werden, berücksichtigt 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.

Unbestimmbare Ursache

Die Ursache des Rückstands kann nicht mit Sicherheit ermittelt werden. Möglicherweise ist das ein vorübergehendes Problem. Wenn das Problem weiterhin besteht, wenden Sie sich an den Support.

Messwerte für Engpässe

Die folgenden Jobmesswerte liefern Informationen zu Engpässen:

  • job/is_bottleneck: Gibt an, ob eine bestimmte Dataflow-Pipelinestufe ein Engpass ist, zusammen mit der Art des Engpasses und der wahrscheinlichen Ursache.

  • job/backlogged_keys: Die Anzahl der Schlüssel im Rückstand für eine Engpassphase.

  • job/recommended_parallelism: Die empfohlene Parallelität für eine Phase, um Engpässe zu reduzieren.

Nächste Schritte