Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page décrit les bonnes pratiques pour optimiser un pipeline Dataflow qui lit des données depuis Pub/Sub et écrit des données dans BigQuery.
Selon votre cas d'utilisation, les suggestions suivantes peuvent vous aider à améliorer vos performances.
Solutions initiales pour les tâches en attente du pipeline
Lorsqu'un pipeline Pub/Sub vers BigQuery rencontre un backlog croissant et ne peut pas suivre le rythme des messages entrants, vous pouvez prendre les mesures immédiates suivantes :
Augmentez le délai de confirmation Pub/Sub : pour l'abonnement Pub/Sub associé, augmentez le délai de confirmation à une valeur légèrement supérieure au temps de traitement maximal prévu pour les messages. Cela empêche les messages d'être renvoyés prématurément alors qu'ils sont encore en cours de traitement.
Faites évoluer les nœuds de calcul : si le nombre de messages non confirmés et le backlog d'abonnement augmentent rapidement, la capacité de traitement du pipeline est probablement insuffisante. Augmentez le nombre de nœuds de calcul Dataflow pour gérer le volume de messages.
Activer l'intervalle exponentiel entre les tentatives : activez l'intervalle exponentiel entre les tentatives pour améliorer la façon dont le pipeline gère les nouvelles tentatives en cas de problèmes temporaires, ce qui le rend plus résilient.
Optimisations à long terme du code et des pipelines
Pour des performances et une stabilité durables, nous vous recommandons d'apporter les modifications d'architecture et de code suivantes :
Réduisez les appels getTable à BigQuery : un nombre excessif d'appels de méthode getTable peut entraîner une limitation du débit et des problèmes de performances. Pour atténuer ce problème :
Mettre en cache les informations sur l'existence des tables dans la mémoire du nœud de calcul pour éviter les appels répétés pour la même table.
Appels getTable par lot pour chaque bundle au lieu de chaque élément individuel.
Refactorisez le code du pipeline pour éliminer la nécessité de vérifier l'existence de la table pour chaque message.
Utilisez l'API BigQuery Storage Write : pour les pipelines de streaming qui écrivent dans BigQuery, migrez des insertions en flux continu standards vers l'
API Storage Write. L'API Storage Write offre de meilleures performances et des quotas nettement plus élevés.
Utilisez l'ancien exécuteur Dataflow pour les jobs à cardinalité élevée : pour les jobs qui traitent un très grand nombre de clés uniques (cardinalité élevée), l'ancien exécuteur Dataflow peut offrir de meilleures performances que Runner v2, sauf si des transformations multilingues sont requises.
Optimisez l'espace de clés : les performances peuvent se dégrader lorsque les pipelines fonctionnent sur des millions de clés actives. Ajustez la logique du pipeline pour effectuer le travail sur un espace de clés plus petit et plus facile à gérer.
Gestion des ressources, des quotas et de la configuration
Une allocation et une configuration appropriées des ressources sont essentielles à la bonne santé du pipeline :
Gérez les quotas de manière proactive : surveillez les quotas et demandez des augmentations pour tous les quotas qui pourraient être atteints lors des événements de scaling. Par exemple, prenons les événements de scaling suivants :
Un taux d'appels élevé aux méthodes TableService.getTable ou tabledata.insertAll peut dépasser le nombre maximal de requêtes par seconde (RPS). Pour en savoir plus sur les limites et sur la façon de demander un quota plus élevé, consultez Quotas et limites de BigQuery.
Les quotas Compute Engine pour les adresses IP et les processeurs en cours d'utilisation peuvent dépasser les limites maximales. Pour en savoir plus sur les limites et sur la façon de demander un quota plus élevé, consultez la présentation des quotas et des limites de Compute Engine.
Optimisez la configuration des nœuds de calcul : pour éviter les erreurs de mémoire insuffisante (OOM) et améliorer la stabilité :
Utilisez des types de machines de nœud de calcul avec plus de mémoire.
Définissez un nombre de nœuds de calcul plus élevé pour répartir la charge de travail de manière plus uniforme et réduire l'impact sur les performances des événements d'autoscaling fréquents.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
