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, Python et Go). Cette mise en œuvre source d'E/S est utilisée par les exécuteurs autres que Dataflow, tels que l'exécuteur Apache Spark, l'exécuteur Apache Flink et l'exécuteur direct.

L'exécuteur Dataflow utilise une autre mise en œuvre privée de PubsubIO (pour Java, Python et Go). 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 (traitement des messages de type "exactement une fois").

Les connecteurs d'E/S Apache Beam vous permettent d'interagir avec Dataflow à l'aide de sources et de récepteurs contrôlés. La mise en œuvre de l'exécuteur Dataflow de PubsubIO accuse automatiquement réception des messages après leur traitement avec succès par la première étape fusionnée et les effets secondaires de ce traitement sont écrits sur un espace de stockage persistant. Pour en savoir plus, consultez la documentation sur la fusion. Les messages ne sont donc confirmés que lorsque Dataflow peut garantir qu'il n'y a 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 à l'horodatage défini par l'application de l'é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. 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". Vous pouvez également utiliser le modèle de programmation Apache Beam pour traiter les flux de messages Pub/Sub une seule 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

Les fonctionnalités Pub/Sub suivantes ne sont pas compatibles avec la mise en œuvre du connecteur d'E/S Pub/Sub de l'exécuteur Dataflow.

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

Les files d'attente de lettres mortes Pub/Sub et les stratégies d'intervalle exponentiel entre les tentatives ne sont pas intégralement prises en charge par Dataflow. À la place, implémentez 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 la réception des messages avant que le pipeline ne traite complètement les données. Plus précisément, Dataflow accuse 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). Si le pipeline comporte plusieurs étapes fusionnées et que les échecs surviennent à tout moment après la première étape, les messages sont déjà confirmés.

Distribution de type "exactement une fois" dans Pub/Sub

Comme Dataflow possède son propre Traitement de type "exactement une fois", il n'est pas recommandé d'utiliser la Distribution Pub/Sub de type "exactement une fois" avec Dataflow. L'activation de la distribution Pub/Sub de type "exactement une fois" réduit les performances du pipeline, car elle limite les messages disponibles pour le traitement en parallèle.

Trier des messages Pub/Sub

Lorsque le tri des messages Pub/Sub est activé, Dataflow peut réorganiser les messages. Le pipeline s'exécute, mais il n'est pas certain que les messages arrivent dans l'ordre dans lequel Dataflow les reçoit. Toutefois, lorsque vous utilisez Pub/Sub avec Dataflow, l'activation du tri des messages peut augmenter la latence et diminuer les performances.

Étapes suivantes