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 den 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. Dadurch wird verhindert, dass Nachrichten vorzeitig noch einmal gesendet werden, während sie noch verarbeitet werden.
  • Worker horizontal 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 verarbeiten.
  • Exponentiellen Backoff aktivieren: Aktivieren Sie den exponentiellen Backoff , um die Art und Weise zu verbessern, wie die Pipeline Wiederholungen bei vorübergehenden Problemen verarbeitet, und sie so robuster 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 Aufrufe der Methode können zu Ratenbegrenzungen und Leistungsengpässen führen. So können Sie das Problem beheben:
    • Speichern Sie Informationen zur Existenz von Tabellen 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.
    • Refaktorieren Sie den Pipelinecode, damit die Existenz von Tabellen nicht für jede Nachricht geprüft werden muss.
  • BigQuery Storage Write API (gRPC) verwenden: Migrieren Sie für Streamingpipelines, die in BigQuery schreiben, von Standard-Streaming-Einfügungen zur Storage Write API (gRPC). Die Storage Write API (gRPC) 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

Die richtige 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 Rate 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 Kontingenten 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 Kontingenten 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