// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

Anomaly detection in tempo reale con Spark Real-Time Mode

Databricks mostra un pattern di guardrail operativo su Spark Structured Streaming: con Real-Time Mode la latenza scende sotto il millisecondo, senza un motore di streaming separato.

Databricks descrive un pattern riutilizzabile per l’anomaly detection su stream operativi usando Real-Time Mode (RTM), un nuovo tipo di trigger per Apache Spark Structured Streaming. L’idea di fondo: quando un evento appare sospetto o non valido, va segnalato subito e instradato verso l’azione downstream appropriata. Casi tipici sono fraud detection, monitoraggio IoT, personalizzazione in tempo reale e security signal processing.

Cosa cambia con Real-Time Mode

La modalità microbatch tradizionale di Structured Streaming attende di riempire il batch prima di elaborare, con latenze nell’ordine di 1-2 secondi. RTM invece processa ogni evento appena arriva, grazie a tre scelte architetturali: continuous data flow, pipeline scheduling (tutti gli stage della query girano insieme, senza blocchi) e streaming shuffle (i dati passano tra i task in memoria, saltando il disco). Il risultato sono latenze end-to-end dichiarate tra ~5ms e ~300ms a seconda della complessità del workload.

Il punto pratico è che non serve un motore separato come Flink: lo stesso stack Spark copre sia i workload analitici (nell’ordine dei secondi) sia quelli operativi (millisecondi). Per abilitare RTM basta cambiare la configurazione del trigger, mantenendo la stessa API di Structured Streaming, la stessa gestione dei checkpoint e le stesse semantiche at-least-once. Con sink Kafka la consegna è at-least-once, quindi i consumer downstream devono gestire eventuali duplicati con scritture idempotenti o deduplica.

Il caso dimostrativo e i risultati

La demo applica due regole di validazione su transazioni della blockchain Ethereum: una di data quality (blocchi con gas_used > gas_limit, fisicamente impossibili) e una di payload hygiene (il campo extra_data che contiene pattern di PII o credenziali come email, JWT token o AWS access key). Ogni evento riceve una decisione ALLOW o QUARANTINE con le relative motivazioni.

Il test ha caricato l’intera chain Ethereum, circa 95 GB su 4 partizioni Kafka, pari a circa 23 milioni di messaggi. La configurazione: Databricks Runtime 16.4 LTS, 4 worker i3.xlarge, cluster dedicato single-user, Photon disabilitato, output mode update (richiesto da RTM). I risultati riportati: input rate di 65.592 righe/secondo, processing rate sostenuto di 69.713 righe/secondo, con P95 sotto 0,5ms e P99 a 1ms su una pipeline di validazione stateless. Databricks precisa che operazioni stateful (aggregazioni, windowing) possono attestarsi più in alto, entro il range ~5ms-~300ms.

  • RTM porta latenze sub-secondo alle API Spark senza introdurre un secondo motore di streaming.
  • L’abilitazione richiede solo una modifica del trigger: nessuna riscrittura del codice esistente.
  • Per workload che tollerano 1-2 secondi di latenza, il microbatch resta l’opzione più conveniente in termini di costi.

Fonte: Ultra-Fast Anomaly Detection using Apache Spark Real-Time Mode — https://www.databricks.com/blog/ultra-fast-anomaly-detection-using-apache-spark-real-time-mode

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma