Best Practices für Pub/Sub zu BigQuery

Auf dieser Seite finden Sie Best Practices für die Optimierung einer Dataflow Pipeline, die Daten aus Pub/Sub liest und in BigQuery schreibt. Je nach Anwendungsfall können die folgenden Vorschläge zu einer besseren Leistung führen.

Erste Lösungen für Pipeline-Backlogs

Wenn bei einer Pub/Sub-zu-BigQuery-Pipeline ein wachsender Backlog auftritt und sie mit eingehenden Nachrichten nicht Schritt halten kann, können Sie die folgenden sofortigen Maßnahmen ergreifen:

  • Anerkennungsfrist für Pub/Sub verlängern: Verlängern Sie für das zugehörige Pub/Sub-Abo dieAnerkennungsfrist auf einen Wert, der etwas länger als die maximal erwartete Nachrichtenverarbeitungszeit ist. So wird verhindert, dass Nachrichten vorzeitig noch einmal gesendet werden, während sie noch verarbeitet werden.
  • Worker skalieren:Wenn die Anzahl der nicht bestätigten Nachrichten und der Abo-Backlog schnell wachsen, ist die Verarbeitungskapazität der Pipeline wahrscheinlich nicht ausreichend. Erhöhen Sie die Anzahl der Dataflow Worker, um das Nachrichten volumen zu bewältigen.
  • Exponentiellen Backoff aktivieren: Aktivieren Sie den exponentiellen Backoff, um die Verarbeitung von Wiederholungen bei vorübergehenden Problemen zu verbessern und die Pipeline so widerstandsfähiger zu machen.

Langfristige Code- und Pipelineoptimierungen

Für eine nachhaltige Leistung und Stabilität werden die folgenden Architektur- und Codeänderungen empfohlen:

  • Anzahl der getTableAufrufe an BigQuery reduzieren: Zu viele getTable Methodenaufrufe können zu Ratenbegrenzungen und Leistungsengpässen führen. So können Sie das Problem beheben:
    • Speichern Sie Informationen zur Tabellenexistenz im Arbeitsspeicher des Workers, um wiederholte Aufrufe für dieselbe Tabelle zu vermeiden.
    • Führen Sie getTable-Aufrufe pro Bundle statt für jedes einzelne Element aus.
    • Überarbeiten Sie den Pipelinecode, damit die Tabellenexistenz nicht für jede Nachricht geprüft werden muss.
  • BigQuery Storage Write API verwenden: Migrieren Sie für Streamingpipelines, die in BigQuery schreiben, von Standard-Streaming-Einfügungen zur Storage Write API. Die Storage Write API bietet eine bessere Leistung und deutlich höhere Kontingente.
  • Standard-Streaming-Java-Runner (früher Runner v1) für Jobs mit hoher Kardinalität verwenden:Bei Jobs, bei denen eine sehr große Anzahl eindeutiger Schlüssel verarbeitet wird (hohe Kardinalität), bietet der Streaming-Java-Runner möglicherweise eine bessere Leistung als der Portable Runner, es sei denn, sprachübergreifende Transformationen sind erforderlich.
  • Schlüsselbereich optimieren:Die Leistung kann sinken, wenn Pipelines mit Millionen aktiver Schlüssel arbeiten. Passen Sie die Logik der Pipeline an, um die Arbeit in einem kleineren, besser verwaltbaren Schlüsselbereich auszuführen.

Ressourcen-, Kontingent- und Konfigurationsverwaltung

Eine korrekte Ressourcenzuweisung und -konfiguration sind entscheidend für die Pipelineleistung:

  • Kontingente proaktiv verwalten:Überwachen Sie Kontingente und fordern Sie Erhöhungen für alle Kontingente an, die bei Skalierungsereignissen erreicht werden könnten. Beispiele für Skalierungsereignisse:
    • Eine hohe Anzahl von Aufrufen der Methoden TableService.getTable oder tabledata.insertAll kann die maximale Anzahl von Abfragen pro Sekunde (Queries per Second, QPS) überschreiten. Weitere Informationen zu Limits und zum Anfordern von mehr Kontingent finden Sie unter BigQuery-Kontingente und Limits.
    • Compute Engine-Kontingente für verwendete IP-Adressen und CPUs können die maximalen Limits überschreiten. Weitere Informationen zu Limits und zum Anfordern von mehr Kontingent finden Sie unter der Übersicht über Kontingente und Limits für Compute Engine.
  • Worker-Konfiguration optimieren:So vermeiden Sie Fehler aufgrund von unzureichendem Arbeitsspeicher (Out of Memory, OOM) und verbessern die Stabilität:
    • Verwenden Sie Worker Maschinen typen mit mehr Arbeitsspeicher.
    • Reduzieren Sie die Anzahl der Threads pro Worker.
    • Legen Sie eine höhere Anzahl von Workern fest, um die Arbeitslast gleichmäßiger zu verteilen und die Auswirkungen häufiger Autoscaling-Ereignisse auf die Leistung zu reduzieren.

Nächste Schritte