Les watermarks de Flink signalent l’avancement du temps événementiel ; le buffer décrit par Cisco trie explicitement les événements par session avant de traiter leur séquence. Les deux mécanismes sont liés au temps événementiel, mais ils remplissent des rôles différents.

Pourquoi l’ordre des événements compte

Dans le pipeline de Cisco, les événements de connexion proviennent de Kafka et forment des séquences comprenant, par exemple, des étapes auth, assoc, dhcp et dns. L’ordre d’arrivée des messages peut différer de l’ordre dans lequel les événements se sont produits. Cisco explique que des arrivées désordonnées pouvaient conduire son application initiale à signaler à tort une connexion réussie. L’entreprise décrit son architecture et les changements apportés à ce pipeline dans son compte rendu technique.

Temps événementiel et watermarks dans Flink

Le temps événementiel correspond au moment où un événement s’est produit. Le temps de traitement est l’heure de l’ordinateur qui traite cet événement. Un watermark est un signal de progression du temps événementiel : il indique à un opérateur qu’il peut avancer ses calculs jusqu’à un certain instant. Flink précise que traiter des événements désordonnés selon leur temps événementiel implique une attente limitée dans le temps. La documentation officielle de Flink détaille ces notions.

Un watermark renseigne donc sur la progression du temps événementiel. Le dispositif décrit par Cisco effectue, lui, un tri explicite des événements conservés pour chaque session. Ces mécanismes portent sur des aspects liés du traitement temporel, mais le watermark ne décrit pas à lui seul le tri par session de Cisco.

Comment Cisco trie les événements et reprend après un redémarrage

Cisco décrit un KeyedProcessFunction qui conserve les événements de chaque session dans une HashMap, puis les trie selon leur temps événementiel avant d’analyser la séquence. Le classement s’appuie ainsi sur l’horodatage de l’événement plutôt que sur son ordre d’arrivée.

Pour la reprise, Cisco indique que le buffer est copié dans ListState à chaque checkpoint, puis restauré après un redémarrage. Ce snapshot protège l’état de l’application ; pour obtenir un traitement exactement une fois de bout en bout, Cisco souligne aussi le rôle du sink, qui doit gérer correctement les sorties rejouées.

Les garde-fous mémoire et les résultats rapportés

Le buffer de Cisco réside sur le tas de la JVM, hors de l’état géré par Flink. Cisco rapporte plusieurs garde-fous : une éviction après trois minutes d’inactivité, le regroupement des déclenchements de timer, des POJO compacts et l’analyse des champs dès l’ingestion. L’entreprise a fait fonctionner la nouvelle variante en parallèle de l’ancienne sur des données de production pendant cinq mois avant de changer les sujets par défaut et de retirer des branchements dans l’interface, le serveur du tableau de bord et la couche de requêtes ClickHouse.

Cisco a également rapporté un débit de 200 000 messages par seconde pour son pipeline de connexions réseau. Ce chiffre concerne le cas d’usage de Cisco.