Lire des données depuis Pub/Sub vers Dataflow

Cette page décrit les bonnes pratiques à suivre pour lire des données depuis Pub/Sub dans Dataflow.

Apache Beam fournit une implémentation de référence du connecteur d'E/S Pub/Sub pour une utilisation par des exécuteurs autres que Dataflow. Toutefois, l'exécuteur Dataflow utilise sa propre implémentation personnalisée du connecteur. Celle-ci exploite les API et services internes de Google Cloud pour offrir des filigranes à faible latence et de haute précision, ainsi qu'une déduplication efficace pour le traitement des messages de type "exactement une fois". Le connecteur est disponible pour Java, Python et Go.

Traitement de type "exactement une fois"

Pub/Sub dissocie les éditeurs d'événements des consommateurs. L'application publie des messages dans un sujet et Pub/Sub les distribue aux abonnés de manière asynchrone.

Pub/Sub attribue un ID de message unique à chaque message qui a bien été publié dans un sujet. Par défaut, Pub/Sub distribue les messages au moins une fois. Pour obtenir la sémantique de type "au moins une fois", Pub/Sub tente à nouveau la distribution s'il ne reçoit pas d'accusé de réception de l'abonné dans le délai de confirmation. Les nouvelles tentatives peuvent entraîner la distribution d'un message plusieurs fois. Par exemple, une redistribution peut se produire si l'abonné accuse réception de la demande après le délai imparti ou si l'accusé de réception est perdu en raison de problèmes réseau temporaires.

Si vous exécutez votre pipeline Dataflow à l'aide du mode de traitement par flux de type "exactement une fois", Dataflow déduplique les messages pour obtenir une sémantique de type "exactement une fois". Si votre pipeline peut tolérer des enregistrements en double, envisagez plutôt d'utiliser le mode de traitement par flux de type "au moins une fois". Ce mode peut considérablement réduire la latence et le coût total de votre pipeline. Le compromis est que certains messages peuvent être traités deux fois. Pour en savoir plus, consultez la page Choisir le mode de streaming à utiliser.

Dédupliquer par attribut de message

Par défaut, Dataflow déduplique en fonction de l'ID du message. Toutefois, une application peut envoyer le même enregistrement deux fois sous forme de deux messages Pub/Sub distincts. Par exemple, les données sources d'origine peuvent contenir des enregistrements en double ou l'application peut publier de manière incorrecte le même message deux fois. Le dernier cas peut être dû à de nouvelles tentatives, si la confirmation a été abandonnée en raison de problèmes réseau ou d'autres interruptions. Dans de telles situations, les messages en double ont des ID différents.

En fonction de votre scénario, vos données peuvent contenir un champ unique qui peut être utilisé pour la déduplication. Par exemple, les enregistrements peuvent contenir un ID de transaction unique. Vous pouvez configurer le connecteur d'E/S Pub/Sub pour qu'il déduplique les messages en fonction de la valeur d'un attribut de message, plutôt que d'utiliser l'ID de message Pub/Sub. Tant que l'éditeur définit cet attribut de manière cohérente lors des nouvelles tentatives, Dataflow peut détecter les doublons. Les messages doivent être publiés sur Pub/Sub dans un intervalle inférieur 10 minutes pour la déduplication.

Pour plus d'informations sur l'utilisation des attributs d'ID, consultez les rubriques de référence suivantes sur le SDK :

Abonnements

Lorsque vous configurez le pipeline, vous spécifiez un sujet Pub/Sub ou un abonnement Pub/Sub à lire. Si vous spécifiez un abonnement, n'utilisez pas le même abonnement Pub/Sub pour plusieurs pipelines. Si deux pipelines lisent à partir d'un même abonnement, chaque pipeline reçoit une partie des données de manière non déterministe, ce qui peut entraîner des messages en double, un retard du filigrane et un autoscaling inefficace. Évitez cette situation en créant un abonnement distinct pour chaque pipeline.

Si vous spécifiez un sujet, le connecteur crée un abonnement temporaire. Cet abonnement est unique pour chaque pipeline.

Horodatages et filigranes

Tous les messages Pub/Sub disposent d'un horodatage, qui représente l'heure à laquelle Pub/Sub reçoit le message. Vos données peuvent également comporter un horodatage d'événement, qui correspond à l'heure à laquelle l'enregistrement a été généré par la source.

Vous pouvez configurer le connecteur pour qu'il lise l'horodatage d'événement à partir d'un attribut du message Pub/Sub. Dans ce cas, le connecteur utilise l'horodatage d'événement pour les filigranes. Sinon, il utilise par défaut l'horodatage des messages Pub/Sub.

Pour en savoir plus sur l'utilisation des horodatages d'événement, consultez les rubriques de référence suivantes sur le SDK :

Le connecteur Pub/Sub a accès à l'API privée de Pub/Sub qui indique l'âge du plus ancien message non confirmé dans un abonnement. Cette API fournit une latence inférieure à celle disponible dans Cloud Monitoring. Cela permet à Dataflow de faire progresser les filigranes du pipeline et d'émettre des résultats de calculs ciblés sur une fenêtre avec de faibles latences.

Si vous configurez le connecteur pour utiliser des horodatages d'événement, Dataflow crée un deuxième abonnement Pub/Sub. Il utilise cet abonnement pour inspecter l'heure des événements des messages en attente. Cette approche permet à Dataflow d'estimer avec précision les horodatages d'événement en attente. Pour en savoir plus, consultez la page Stack Overflow décrivant la façon dont Dataflow calcule les filigranes Pub/Sub.

Fonctionnalité Seek de Pub/Sub

La fonctionnalité Seek de Pub/Sub permet aux utilisateurs de relire des messages précédemment confirmés. Vous pouvez utiliser la fonctionnalité de recherche de Pub/Sub avec Dataflow pour relancer le traitement des messages dans un pipeline.

Toutefois, il n'est pas recommandé d'utiliser la fonctionnalité de recherche de Pub/Sub dans un pipeline en cours d'exécution. La recherche en arrière-plan dans un pipeline en cours d'exécution peut entraîner la suppression de messages en double ou de messages en double. Elle invalide également la logique du filigrane de Dataflow et entre en conflit avec l'état d'un pipeline intégrant les données traitées.

Pour relancer le traitement des messages à l'aide de la fonctionnalité Seek de Pub/Sub, nous vous recommandons d'appliquer le workflow suivant :

  1. Créer un instantané de l'abonnement.
  2. Créer un abonnement au sujet Pub/Sub. Le nouvel abonnement hérite de l'instantané.
  3. Drainez ou annulez le job Dataflow en cours.
  4. Renvoyez le pipeline à l'aide du nouvel abonnement.

Pour en savoir plus, consultez la section Relancer le traitement des messages avec des fonctionnalités d'instantanés et de recherche Pub/Sub.

Fonctionnalités Pub/Sub non compatibles

Les fonctionnalités Pub/Sub suivantes ne sont pas compatibles avec l'implémentation du connecteur d'E/S Pub/Sub de l'exécuteur Dataflow.

Intervalle exponentiel entre les tentatives

Lorsque vous créez un abonnement Pub/Sub, vous pouvez le configurer pour utiliser une stratégie d'intervalle exponentiel entre les tentatives. Cependant, l'intervalle exponentiel entre les tentatives ne fonctionne pas avec Dataflow.

L'intervalle exponentiel entre les tentatives est déclenché par un accusé de réception négatif ou par l'expiration du délai d'accusé de réception. Cependant, Dataflow n'envoie pas d'accusés de réception négatifs 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.

Sujets des lettres mortes

Il n'est pas recommandé d'utiliser des sujets de lettres mortes Pub/Sub avec Dataflow, pour les raisons suivantes :

  • Dataflow envoie des accusés de réception négatifs pour diverses raisons internes (par exemple, si un nœud de calcul est en cours d'arrêt). Par conséquent, les messages peuvent être distribués à la file d'attente de lettres mortes, même si aucun échec ne se produit dans le code du pipeline.

  • Dataflow peut accuser 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 après la première étape, les messages sont déjà confirmés et ne sont pas dirigés vers la file d'attente de lettres mortes.

Mettez plutôt en œuvre le modèle de lettres mortes explicitement dans le pipeline. Certains récepteurs d'E/S sont nativement compatibles avec les files d'attente de lettres mortes. Les exemples suivants mettent en œuvre des modèles de lettres mortes :

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

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

Pub/Sub : ordre des messages

L'ordre des messages est une fonctionnalité de Pub/Sub qui permet à un abonné de recevoir les messages dans l'ordre dans lequel ils ont été publiés.

Il n'est pas recommandé d'utiliser l'ordre des messages avec Dataflow pour les raisons suivantes :

  • Il est possible que le connecteur d'E/S Pub/Sub ne conserve pas l'ordre des messages.
  • Apache Beam ne définit pas de consignes strictes concernant l'ordre de traitement des éléments. Par conséquent, l'ordre peut ne pas être conservé dans les transformations en aval.
  • L'utilisation de l'ordre des messages Pub/Sub avec Dataflow peut augmenter la latence et réduire les performances.

Étapes suivantes