Cisco descrive un buffer che riordina gli eventi di ciascuna sessione in base al momento in cui si sono verificati; i watermark di Apache Flink segnalano invece l’avanzamento del tempo degli eventi. La differenza conta quando i record arrivano fuori sequenza: un watermark indica il progresso temporale, mentre il buffer di Cisco ordina esplicitamente i record prima di interpretarli.
Quando l’ordine di arrivo inganna
La pipeline di Cisco riceve da Kafka eventi relativi a tentativi di connessione, composti da passaggi come auth, assoc, dhcp e dns. L’ordine in cui i record arrivano può differire da quello in cui i passaggi si sono verificati. Cisco riferisce che, nel sistema originale, questi arrivi fuori sequenza potevano produrre falsi positivi: connessioni segnalate come riuscite anche quando la sequenza degli eventi non lo giustificava.
Event time, processing time e watermark
L’event time è il momento in cui un evento si verifica; il processing time è l’ora del sistema che lo elabora. Un watermark, nella semantica di Flink, segnala che il calcolo può avanzare fino a un certo punto dell’event time, aspettandosi che non arrivino altri eventi con timestamp precedente. La documentazione ufficiale di Apache Flink spiega anche che gestire eventi fuori ordine in base all’event time comporta un’attesa finita.
Il watermark descrive dunque il progresso temporale dell’elaborazione. Il progetto Cisco descritto, invece, conserva i record di ogni sessione e li ordina per event time prima di analizzare la sequenza. Sono concetti legati al tempo degli eventi, ma il watermark non descrive da solo quel riordino esplicito per sessione.
Come Cisco ordina e recupera gli eventi
Cisco descrive una KeyedProcessFunction che mantiene gli eventi di ogni sessione in una HashMap, quindi li ordina con un comparatore basato sull’event time prima di interpretarli. Nel percorso originale, secondo Cisco, ogni evento comportava accessi allo stato in RocksDB e la registrazione di timer; la società ha usato il flame graph dell’interfaccia web di Flink per individuare il lavoro più costoso.
Il buffer risiede nell’heap della JVM, fuori dallo stato gestito da Flink. Per conservarne una copia recuperabile, Cisco dichiara di copiarne il contenuto in ListState a ogni checkpoint e di ripristinarlo dopo un riavvio. Il checkpoint salva lo stato dell’applicazione, ma il risultato end-to-end “exactly-once” dipende anche da come il sink gestisce gli output riprodotti dopo un ripristino.
Limiti di memoria e risultati riferiti
Per contenere l’uso della memoria, Cisco indica un timeout personalizzato di inattività di tre minuti, il raggruppamento delle registrazioni dei timer e l’uso di POJO compatti, con i campi analizzati una sola volta all’ingresso. La società riferisce di aver fatto funzionare la nuova variante in parallelo con quella originale su dati di produzione per cinque mesi prima di cambiare i topic predefiniti e rimuovere la logica condizionale dall’interfaccia, dal server della dashboard e dal livello di query di ClickHouse.
Cisco riferisce inoltre un throughput di 200.000 messaggi al secondo per la propria pipeline di connessioni. È un dato riferito a quel caso d’uso: descrive il risultato comunicato da Cisco, non una capacità universale di Apache Flink.
