Questo post è una pubblicazione ospite scritta da Yaroslav Tkachenko, un architetto software presso Activision.

Apache Spark è uno dei più popolari e potenti framework di elaborazione dati su larga scala. È stato creato come alternativa al framework MapReduce di Hadoop per i carichi di lavoro batch, ma ora supporta anche l’SQL, l’apprendimento automatico e l’elaborazione dei flussi. Oggi voglio concentrarmi su Spark Streaming e mostrare alcune opzioni disponibili per l’elaborazione dei flussi.

L’elaborazione dei dati in streaming viene utilizzata quando i dati dinamici vengono generati continuamente, e si trova spesso nei casi di utilizzo dei big data. Nella maggior parte dei casi i dati vengono elaborati in tempo quasi reale, un record alla volta, e le intuizioni derivate dai dati vengono utilizzate anche per fornire avvisi, rendere le dashboard e alimentare modelli di apprendimento automatico che possono reagire rapidamente alle nuove tendenze nei dati.

DStreams vs. DataFrames

Spark Streaming è diventato alpha con Spark 0.7.0. Si basa sull’idea di flussi discretizzati o DStreams. Ogni DStream è rappresentato come una sequenza di RDD, quindi è facile da usare se si proviene da carichi di lavoro batch di basso livello basati su RDD. DStreams ha subito molti miglioramenti in quel periodo di tempo, ma c’erano ancora varie sfide, principalmente perché è un’API di livello molto basso.

Come soluzione a queste sfide, Spark Structured Streaming è stato introdotto in Spark 2.0 (ed è diventato stabile in 2.2) come estensione costruita sopra Spark SQL. Per questo motivo, sfrutta il codice Spark SQL e le ottimizzazioni della memoria. Structured Streaming dà anche astrazioni molto potenti come le API Dataset/DataFrame così come SQL. Non c’è più bisogno di avere a che fare direttamente con RDD!

Sia lo Structured Streaming che lo Streaming con DStreams usano il micro-batching. La più grande differenza è la latenza e le garanzie di consegna dei messaggi: Lo Structured Streaming offre la consegna esattamente una volta con una latenza di oltre 100 millisecondi, mentre l’approccio Streaming with DStreams garantisce solo la consegna at-least-once, ma può fornire latenze di millisecondi.

Personalmente preferisco Spark Structured Streaming per casi d’uso semplici, ma Spark Streaming with DStreams è davvero buono per topologie più complicate grazie alla sua flessibilità. Ecco perché di seguito voglio mostrare come utilizzare Streaming with DStreams e Streaming with DataFrames (che è tipicamente usato con Spark Structured Streaming) per consumare ed elaborare i dati da Apache Kafka. Userò Scala, Apache Spark 2.3, e Apache Kafka 2.0.

Inoltre, per il bene dell’esempio eseguirò i miei lavori usando i notebook Apache Zeppelin forniti da Qubole. Qubole è una piattaforma di dati che uso quotidianamente. Gestisce cluster Hadoop e Spark, rende facile eseguire query Hive e Presto ad hoc, e fornisce anche notebook Zeppelin gestiti che uso volentieri. Con Qubole non ho bisogno di pensare molto alla configurazione e alla messa a punto di Spark e Zeppelin, viene semplicemente gestito per me.

Il caso d’uso attuale che ho è molto semplice:

• Una sorta di telemetria viene scritta su Kafka: piccoli messaggi JSON con metadati e coppie chiave/valore arbitrarie
• Voglio connettermi a Kafka, consumare e deserializzare quei messaggi
• Poi applicare trasformazioni se necessario
• Raccogliere alcune aggregazioni
• Finalmente, Sono interessato alle anomalie e in generale ai dati cattivi – dato che non controllo il produttore, voglio catturare cose come NULL, stringhe vuote, forse date errate e altri valori con formati specifici, ecc.
• Il lavoro dovrebbe essere eseguito per un po’ di tempo, poi terminare automaticamente. In genere, i lavori di Spark Streaming vengono eseguiti continuamente, ma a volte potrebbe essere utile eseguirlo ad hoc per l’analisi/debug (o come esempio nel mio caso, dato che è così facile eseguire un lavoro Spark in un notebook).

Streaming con DStreams

In questo approccio usiamo DStreams, che è semplicemente una collezione di RDD.

Streaming con DataFrames

Ora possiamo provare a combinare lo Streaming con le API DataFrames per ottenere il meglio dei due mondi!

Conclusione

Quale approccio è migliore? Poiché DStream è solo una collezione di RDD, è tipicamente usato per trasformazioni ed elaborazioni di basso livello. Aggiungere un’API DataFrames su questo fornisce astrazioni molto potenti come SQL, ma richiede un po’ più di configurazione. E se avete un caso d’uso semplice, Spark Structured Streaming potrebbe essere una soluzione migliore in generale!