Comment gérez-vous les événements qui arrivent en retard dans un pipeline en streaming ?

Utilisez le temps d'événement plutôt que le temps de traitement, et définissez un watermark, c'est-à-dire l'estimation heuristique du moteur selon laquelle plus aucun événement antérieur à un horodatage donné n'arrivera. Les fenêtres se ferment quand le watermark dépasse leur fin. Réglez une tolérance de retard pour que les événements légèrement en retard mettent encore à jour les résultats, et routez tout ce qui arrive plus tard vers une sortie annexe ou une table de réconciliation, plutôt que de le jeter en silence.

D'abord, tout est indexé sur le temps d'événement, parce que les résultats en temps de traitement changent à chaque rejeu, ce qui les rend inutilisables pour la réconciliation. Ensuite, le watermark est l'affirmation du moteur selon laquelle il n'attend plus d'événements antérieurs à cet horodatage, et les fenêtres se finalisent quand il les dépasse. Choisir ce décalage est la vraie décision de conception : un watermark court donne des résultats rapides parfois incomplets, un long donne des résultats corrects mais tardifs. Je le fixe à partir des données, pas de l'intuition. Sur un pipeline d'application mobile, nous avons mesuré l'écart entre temps d'événement et temps d'ingestion et trouvé un quatre-vingt-dix-neuvième centile autour de quatre minutes, à cause des téléphones hors ligne : nous avons donc réglé la tolérance de retard à dix minutes. Tout ce qui arrivait plus tard partait vers une sortie annexe qui alimentait un job de réconciliation quotidien, lequel corrigeait les fenêtres concernées dans l'entrepôt. La règle à laquelle je me tiens, c'est qu'une donnée en retard n'est jamais jetée en silence. Si on l'écarte, on la compte d'abord.