0

Simple pipeline de flux de données gcloud:DataFlow pas Acking messages PubSub

PubsubIO.readStrings() FromSubscription -> Fenêtre -> PARDO -> DatastoreIO.v1() (écrire)

Lorsque la charge est appliquée à.. le sujet de PubSub, les messages sont lus mais pas Acked:

25 juillet 2017 16:20:38 org.apache.beam.sdk.io.gcp.pubsub.PubsubUnboundedSource $ PubsubReader statistiques INFO: Pubsub projets/mon-projet/abonnements/mon-abonnement a 1000 messages reçus, 950 mess non-lu 843346 octets non lus, 970 msg en vol, 28367ms en vol, 1 point de contrôle en vol, 2 points de contrôle en vol, 770B/s lus récemment, 1000 récents, 0 récents étendus, 0 récents fin prolongée, 50 Acked récente, 990 récente nacked, 0 récente a expiré, 898ms biais d'horodatage de message récent, 9224873061464212ms récent biais de filigrane, 0 messages récents en retard, 2017-07-25T23: 16: 49.437Z dernier rapport filigrane

Quelle étape du pipeline doit prendre en compte les messages?

  • Le tableau de bord de stackdriver indique qu'il existe des accusés de réception, mais le nombre de messages non résolus reste stable.
  • aucun message d'erreur dans la trace indiquant que le traitement du message a échoué.
  • entrées apparaissent dans le magasin de données
+0

Quel coureur utilisez-vous? Avez-vous un ID de travail provenant du pipeline que vous avez géré? –

+0

J'utilise le service de gestion de flux de données qui me donne un ID de travail ainsi que mon coureur local pour le développement. J'utilise le java sdk 2 en passant. – jean

+0

J'ai vu occasionnellement des messages RPC timeout DEADLINE_EXCEEDED et essayé avec une plus grande machine et plus de travailleurs comme indiqué ici: https://cloud.google.com/dataflow/pipelines/troubleshooting-your-pipeline#rpc-timed-out- exceptions-DEADLINE_EXCEEDED-exceptions-ou qui ne répondent pas-serveur erreurs le numer d'emploi: 2017-07-27_11_40_13-16176649068898383100 @BenChambers – jean

Répondre

0

Dataflow ne fera que reconnaître les messages PubSub après avoir commis ailleurs durablement. Dans un pipeline composé de PubSub -> ParDo -> 1 puits ou plus, cela peut être retardé par l'un des puits ayant des problèmes (même s'ils sont réessayés, cela ralentira les choses). Cela fait partie de s'assurer que les résultats semblent être traités effectively-once. Voir a previous question about when Dataflow acknowledges a message pour plus de détails.

Une option (facile) pour modifier ce comportement consiste à ajouter un GroupByKey (à l'aide d'une clé générée aléatoirement) après la source PubSub et avant les puits. Cela entraînera l'acquittement des messages plus tôt, mais peut être pire car PubSub est généralement mieux équipé des entrées non traitées que GroupByKey.