Streaming avec Pub/Sub

Cette page présente les concepts liés à l'intégration de Dataflow à Pub/Sub. La présentation décrit certaines optimisations disponibles dans la mise en œuvre du connecteur d'E/S Pub/Sub de l'exécuteur Dataflow. Pub/Sub est un système évolutif et durable d'ingestion et de diffusion d'événements. Dataflow complète le modèle de diffusion évolutif de type "au moins une fois" de Pub/Sub avec la déduplication des messages, le traitement de type "exactement une fois" et la génération d'un filigrane de données à partir d'événements horodatés. Pour utiliser Dataflow, écrivez des données dans votre pipeline à l'aide du SDK Apache Beam, puis exécutez le code du pipeline sur le service Dataflow.

Avant de commencer, découvrez les concepts fondamentaux d'Apache Beam et des pipelines de streaming. Pour en savoir plus, consultez les ressources suivantes :

Créer des pipelines de streaming avec Pub/Sub

Pour profiter des avantages de l'intégration de Dataflow avec Pub/Sub, vous pouvez créer vos pipelines de traitement par flux de l'une des manières suivantes :

Fonctionnalités d'intégration Pub/Sub et Dataflow

Apache Beam fournit une mise en œuvre source d'E/S de référence (PubsubIO) pour Pub/Sub (Java et Python) pouvant être utilisée par les exécuteurs autres que Dataflow (par exemple, l'exécuteur Apache Spark, l'exécuteur Apache Flink et l'outil Direct Runner).

L'exécuteur Dataflow utilise néanmoins une autre mise en œuvre privée de PubsubIO. Celle-ci exploite les API et services internes de Google Cloud pour offrir trois avantages principaux : des filigranes à faible latence et de haute précision (et par conséquent des données exhaustives), ainsi qu'une déduplication efficace.

La mise en œuvre de l'exécuteur Dataflow de PubsubIO accuse automatiquement la réception des messages une fois qu'ils ont été correctement traités par la première étape fusionnée (et les effets secondaires de ce traitement ont été écrits dans l'espace de stockage persistant). Pour en savoir plus, consultez la documentation sur la fusion. Par conséquent, les messages ne sont confirmés que lorsque Dataflow peut garantir qu'il n'y aura aucune perte de données en cas de plantage d'un composant ou de perte de connexion.

Filigranes à faible latence

Dataflow dispose d'un accès à l'API privée de Pub/Sub qui indique l'ancienneté du plus ancien message non confirmé dans un abonnement, avec une latence inférieure à celle disponible dans Cloud Monitoring. À titre de comparaison, les métriques de messages en attente Pub/Sub disponibles dans Cloud Monitoring sont généralement retardées de deux à trois minutes, contre seulement dix secondes environ pour Dataflow. Dataflow peut ainsi développer les filigranes du pipeline et afficher plus rapidement les résultats des calculs ciblés sur une fenêtre.

Haute précision du filigrane

L'intégration de Dataflow à Pub/Sub permet de résoudre un autre problème important de manière native, à savoir la nécessité de disposer d'un filigrane fiable pour les fenêtres définies au moment de l'événement. L'heure de l'événement correspond à un horodatage spécifié par l'application d'éditeur en tant qu'attribut d'un message Pub/Sub, au lieu du champ publish_time défini sur un message par le service Pub/Sub lui-même. Pub/Sub ne calcule les métriques de messages en attente qu'en fonction des horodatages attribués par le service (ou le temps de traitement). L'estimation du filigrane de l'heure de l'événement nécessite un mécanisme différent.

Si l'utilisateur choisit de définir des horodatages d'événement personnalisés, le service Dataflow crée un deuxième abonnement de suivi pour résoudre ce problème. Cet abonnement de suivi permet d'examiner l'heure des événements des messages en attente dans l'abonnement de base et d'estimer leur retard. Pour en savoir plus, consultez la page Stack Overflow décrivant la façon dont Dataflow calcule les filigranes Pub/Sub.

Déduplication efficace

La déduplication des messages est requise pour le traitement des messages de type "exactement une fois". Dataflow déduplique les messages en fonction de l'ID du message Pub/Sub. Par conséquent, toute la logique de traitement peut supposer que les messages sont déjà uniques par rapport à l'ID du message Pub/Sub. Le mécanisme d'agrégation incrémentielle qui permet d'y parvenir est extrait dans l'API PubsubIO.

Si PubsubIO est configuré pour utiliser l'attribut de message Pub/Sub pour la déduplication au lieu de l'ID de message, Dataflow déduplique les messages publiés dans Pub/Sub dans un délai de 10 minutes entre eux.

Fonctionnalités Pub/Sub non compatibles

Files d'attente de lettres mortes et stratégies d'intervalle exponentiel entre les tentatives

Les files d'attente de lettres mortes et stratégies d'intervalle exponentiel entre les tentatives de Pub/Sub ne sont pas entièrement compatibles avec Dataflow. À la place, mettez en œuvre ces modèles explicitement dans le pipeline. Deux exemples de modèles de lettres mortes sont fournis dans l'application de vente au détail et le modèle Pub/Sub vers BigQuery.

Les files d'attente de lettres mortes et les stratégies d'intervalle exponentiel entre les tentatives ne fonctionnent pas avec Dataflow pour deux raisons.

Tout d'abord, Dataflow n'envoie de messages NACK (c'est-à-dire, n'envoie pas d'accusé de réception négatif) à Pub/Sub en cas d'échec du code de pipeline. À la place, Dataflow relance indéfiniment le traitement du message, tout en prolongeant le délai de confirmation du message. Toutefois, le backend Dataflow peut envoyer des messages NACK pour diverses raisons internes. Il est donc possible que des messages soient distribués à la file d'attente de lettres mortes même si le code du pipeline n'a pas échoué.

Ensuite, Dataflow peut accuser réception des messages avant que le pipeline ne traite complètement les données. Plus précisément, Dataflow accuse réception des messages une fois qu'ils ont été traités avec succès par la première étape fusionnée (et les effets secondaires de ce traitement ont été écrits sur un espace de stockage persistant). Si le pipeline comporte plusieurs étapes fusionnées et qu'il y a des échecs à un moment donné après la première étape, les messages ont déjà été confirmés.