Bonnes pratiques pour Pub/Sub vers BigQuery

Cette page décrit les bonnes pratiques pour optimiser un pipeline Dataflow qui lit des données depuis Pub/Sub et les écrit dans BigQuery. Selon votre cas d'utilisation, les suggestions suivantes peuvent améliorer les performances.

Solutions initiales pour les files d'attente de pipelines

Lorsqu'un pipeline Pub/Sub vers BigQuery connaît une file d'attente croissante et ne peut pas suivre le rythme des messages entrants, vous pouvez prendre les mesures immédiates suivantes :

  • Augmenter le délai d'accusé de réception Pub/Sub : pour l' abonnement Pub/Sub associé, augmentez le délai d'accusé de réception à une valeur légèrement supérieure au temps de traitement maximal prévu pour les messages. Cela empêche les messages d'être rediffusés prématurément pendant leur traitement.
  • Effectuer un scaling horizontal des nœuds de calcul : si le nombre de messages non reconnus et la file d'attente d'abonnements 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 du pipeline

Pour des performances et une stabilité durables, les modifications architecturales et de code suivantes sont recommandées :

  • Réduire les appels getTable à BigQuery : un nombre excessif d'appels de méthode getTable peut entraîner une limitation du débit et des goulots d'étranglement au niveau des performances. Pour atténuer ce problème :
    • Mettez en cache les informations d'existence de la table dans la mémoire du nœud de calcul pour éviter les appels répétés pour la même table.
    • Regroupez les appels getTable par lot au lieu de les effectuer pour 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.
  • Utiliser l'API BigQuery Storage Write : pour les pipelines de streaming qui écrivent dans BigQuery, migrez des insertions de streaming standards vers l' API Storage Write. L'API Storage Write offre de meilleures performances et des quotas nettement plus élevés.
  • Utiliser le gestionnaire Java de streaming standard (auparavant appelé gestionnaire v1) pour les jobs à cardinalité élevée : pour les jobs qui traitent un très grand nombre de clés uniques (cardinalité élevée), le gestionnaire Java de streaming peut offrir de meilleures performances que le gestionnaire portable, sauf si des transformations inter-langues sont requises.
  • Optimiser 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érer les quotas de manière proactive : surveillez les quotas et demandez des augmentations pour tous les quotas qui pourraient être atteints lors d'événements de scaling. Par exemple, examinez 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 la page 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 page Présentation des quotas et des limites de Compute Engine overview.
  • Optimiser la configuration des nœuds de calcul : pour éviter les erreurs de mémoire insuffisante et améliorer la stabilité :

Étape suivante