Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie Best Practices zum Optimieren 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-Rückstände
Wenn bei einer Pub/Sub-zu-BigQuery-Pipeline ein wachsender Rückstand auftritt und sie mit eingehenden Nachrichten nicht Schritt halten kann, können Sie die folgenden sofortigen Maßnahmen ergreifen:
Pub/Sub-Bestätigungsfrist verlängern:Verlängern Sie die Bestätigungsfrist für das zugehörige Pub/Sub-Abo auf einen Wert, der etwas länger ist als die maximal erwartete Nachrichtenverarbeitungszeit. So wird verhindert, dass Nachrichten vorzeitig noch einmal zugestellt werden, während sie noch verarbeitet werden.
Worker skalieren:Wenn die Anzahl der nicht bestätigten Nachrichten und der Abo-Rückstand schnell wachsen, ist die Verarbeitungskapazität der Pipeline wahrscheinlich nicht ausreichend. Erhöhen Sie die Anzahl der Dataflow-Worker, um das Nachrichtenvolumen zu bewältigen.
Exponentiellen Backoff aktivieren:Aktivieren Sie den exponentiellen Backoff, um die Verarbeitung von Wiederholungsversuchen bei vorübergehenden Problemen in der Pipeline zu verbessern und die Pipeline robuster zu machen.
Langfristige Code- und Pipeline-Optimierungen
Für eine nachhaltige Leistung und Stabilität werden die folgenden Architektur- und Codeänderungen empfohlen:
getTable-Aufrufe an BigQuery reduzieren:Zu viele getTable-Methodenaufrufe können zu Ratenbegrenzungen und Leistungsengpässen führen. So können Sie das Problem beheben:
Informationen zur Existenz von Tabellen im Arbeitsspeichercache speichern, um wiederholte Aufrufe für dieselbe Tabelle zu vermeiden.
Batch-Aufrufe getTable erfolgen auf Set-Basis anstatt für jedes einzelne Element.
Refaktorieren Sie den Pipelinecode, damit nicht für jede Nachricht geprüft werden muss, ob die Tabelle vorhanden ist.
BigQuery Storage Write API verwenden:Migrieren Sie für Streamingpipelines, die in BigQuery schreiben, von Standard-Streaming-Insert-Anweisungen zur
Storage Write API. Die Storage Write API bietet eine bessere Leistung und deutlich höhere Kontingente.
Legacy-Dataflow-Runner für Jobs mit hoher Kardinalität verwenden:Bei Jobs, bei denen eine sehr große Anzahl eindeutiger Schlüssel (hohe Kardinalität) verarbeitet wird, bietet der Legacy-Dataflow-Runner möglicherweise eine bessere Leistung als Runner v2, sofern keine sprachübergreifenden Transformationen erforderlich sind.
Schlüsselbereich optimieren:Die Leistung kann nachlassen, wenn Pipelines mit Millionen aktiver Schlüssel arbeiten. Passen Sie die Logik der Pipeline an, um die Arbeit an einem kleineren, besser verwaltbaren Schlüsselbereich auszuführen.
Ressourcen-, Kontingent- und Konfigurationsverwaltung
Eine korrekte Ressourcenzuweisung und ‑konfiguration sind entscheidend für den Zustand der Pipeline:
Kontingente proaktiv verwalten:Kontingente im Blick behalten und Erhöhungen für alle Kontingente anfordern, die während Skalierungsereignissen erreicht werden könnten. Betrachten Sie beispielsweise die folgenden Skalierungsereignisse:
Eine hohe Anzahl von Aufrufen der Methoden TableService.getTable oder tabledata.insertAll kann die maximale Anzahl von Abfragen pro Sekunde (QPS) überschreiten. Weitere Informationen zu Limits und dazu, wie Sie mehr Kontingent anfordern können, 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 in der Übersicht zu Compute Engine-Kontingenten und ‑Limits.
Worker-Konfiguration optimieren:So vermeiden Sie Fehler aufgrund von unzureichendem Arbeitsspeicher (Out-of-memory, OOM) und verbessern die Stabilität:
Verwenden Sie Worker-Maschinentypen mit mehr Arbeitsspeicher.
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 verringern.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Pub/Sub to BigQuery best practices\n\nThis page outlines best practices for optimizing a Dataflow\npipeline that [reads from\nPub/Sub](/dataflow/docs/concepts/streaming-with-cloud-pubsub) and\n[writes to BigQuery](/dataflow/docs/guides/write-to-bigquery).\nDepending on your use case, the following suggestions might lead to better\nperformance.\n\nInitial solutions for pipeline backlogs\n---------------------------------------\n\nWhen a Pub/Sub to BigQuery pipeline experiences a\ngrowing backlog and can't keep up with incoming messages, you can take the\nfollowing immediate steps:\n\n- **Increase Pub/Sub acknowledgment deadline:** For the associated Pub/Sub subscription, [increase the acknowledgment\n deadline](/pubsub/docs/lease-management) to a value slightly longer than the maximum expected message processing time. This prevents messages from being redelivered prematurely while they are still being processed.\n- **Scale out workers:** If the unacknowledged message count and subscription backlog are growing rapidly, the pipeline's processing capacity is likely insufficient. Increase the [number of Dataflow\n workers](/dataflow/docs/reference/pipeline-options) to handle the message volume.\n- **Enable exponential backoff:** Enable [exponential backoff](/pubsub/docs/handling-failures#exponential_backoff) to improve how the pipeline handles retries for transient issues, making it more resilient.\n\nLong-term code and pipeline optimizations\n-----------------------------------------\n\nFor sustained performance and stability, the following architectural and code\nchanges are recommended:\n\n- **Reduce `getTable` calls to BigQuery:** Excessive `getTable` method calls can lead to rate-limiting and performance bottlenecks. To mitigate this:\n - Cache table existence information in worker memory to avoid repeated calls for the same table.\n - Batch `getTable` calls on a per-bundle basis instead of for each individual element.\n - Refactor the pipeline code to eliminate the need to check for table existence for every message.\n- **Use the BigQuery Storage Write API:** For streaming pipelines writing to BigQuery, migrate from standard streaming inserts to the [Storage Write API](/bigquery/docs/write-api). The Storage Write API offers better performance and significantly higher quotas.\n- **Use the legacy Dataflow runner for high-cardinality jobs:** For jobs that process a very large number of unique keys (*high-cardinality*), the legacy Dataflow runner might offer better performance than Runner v2, unless cross-language transforms are required.\n- **Optimize the key space:** Performance can degrade when pipelines operate on millions of active keys. Adjust the pipeline's logic to perform work on a smaller, more manageable key space.\n\nResource, quota, and configuration management\n---------------------------------------------\n\nProper resource allocation and configuration are critical for pipeline health:\n\n- **Proactively manage quotas:** Monitor quotas and request increases for any quotas that might be reached during scaling events. For example, consider the following scaling events:\n - A high rate of calls to the `TableService.getTable` or `tabledata.insertAll` methods might exceed the maximum queries per second (QPS). For more information on limits and how to request more quota, see [BigQuery quotas and\n limits](/bigquery/quotas).\n - Compute Engine quotas for in-use IP addresses and CPUs might exceed maximum limits. For more information on limits and how to request more quota, see the [Compute Engine quota and limits\n overview](/compute/quotas-limits).\n- **Optimize worker configuration:** To prevent out-of-memory (OOM) errors and improve stability:\n - Use worker [machine\n types](/dataflow/docs/guides/configure-worker-vm#machine-type) with more memory.\n - Reduce the [number of\n threads](/dataflow/docs/reference/pipeline-options#resource_utilization) per worker.\n - Set a higher [number of\n workers](/dataflow/docs/reference/pipeline-options#resource_utilization) to distribute the workload more evenly and reduce the performance impact of frequent autoscaling events.\n\nWhat's next\n-----------\n\n- [Develop and test Dataflow pipelines](/dataflow/docs/guides/develop-and-test-pipelines)\n- [Dataflow pipeline best practices](/dataflow/docs/guides/pipeline-best-practices)\n- [Dataflow job metrics](/dataflow/docs/guides/using-monitoring-intf)"]]
