Fast data significa streaming in tempo reale di informazioni generate da miriadi di fonti. E lo streaming è il vero cuore dei big data.
Se non pensi in termini di fast data, allora non hai capito niente dei big data. Possiamo sintetizzare così il senso di una trasformazione – quella dei big data, appunto – tanto chiacchierata ma raramente compresa nella sua essenza. Il problema forse sta in quel «big», un aggettivo che rischia di portarci fuori strada.
Quando si parla di big data, infatti, si pone generalmente l’enfasi sull’aspetto dimensionale, ovvero sulla quantità di dati da processare. Intendiamoci, non che questa prospettiva sia sbagliata. È sufficiente pensare alla crescita enorme di dati in circolazione a tutti i livelli per capire che quella dimensionale costituisce una sfida. Secondo alcune stime ogni giorno nel mondo si creano 2,5 trilioni di byte di nuovi dati (un trilione corrisponde a un miliardo di miliardi, cioè 10 alla diciottesima).
Tuttavia il vero cambio di paradigma non è legato alla quantità dei dati. Questo, anzi, lo diamo ormai per scontato. «Big is the new normal», potremmo dire. Ciò che più conta è la capacità di agire sui di essi in tempo reale. La vera sfida, insomma, è nel «fast».
Perché infatti ci occupiamo di big data? In termini analitici, l’obiettivo non è sapere ciò che è accaduto e neppure ciò che accadrà. Si tratta di sapere che cosa sta accadendo. Quello che vogliamo dai dati è un feedback in tempo reale.
Un paio di esempi applicativi aiutano a capire di che cosa stiamo parlando. Pensiamo alle auto a guida autonoma (primo esempio): è chiaro che esse possono funzionare solo se le informazioni sulle condizioni del traffico e sull’ambiente circostante vengono processate in tempo reale. Oppure riflettiamo sui sistemi anti-frode in uso presso le società bancarie (secondo esempio): è altrettanto chiaro che i comportamenti anomali nell’utilizzo delle carte di credito, per essere bloccati, devono essere identificati e notificati mentre si determinano, e non a posteriori.
Telemetria, anti-frode, manutenzione predittiva: sono tutti ambiti in cui Spindox è fortemente impegnata e in cui il paradigma dei big data si declina nel modo appena detto.
Meno batch, più streaming
Parlare di fast data significa spostare il focus dai processi di tipo batch allo streaming dei dati in tempo reale. Si passa cioè dai big data di prima generazione, nei quali una grande quantità di informazioni veniva raccolta e depositata in un database in tempo reale, a un approccio in cui le informazioni sono subito analizzate. La velocità, insomma, non riguarda più solo la fase di raccolta dei dati, ma anche quella della loro elaborazione.
Dal punto di vista tecnologico la componente di storage diventa solo una parte della risposta. Essa si deve integrare con un potente modulo di processing. Ed è proprio questo che ha portato a mettere in discussione Apache Hadoop, il framework in apparenza più solido per la gestione dei big data. Com’è noto Hadoop si compone di due moduli principali: da un lato c’è Hadoop Distributed File System (HDFS), che gestisce lo storage, applicando logiche di calcolo distribuito e parallelo su cluster; dall’altro c’è Hadoop MapReduce, che implementa il modello di programmazione di MapReduce per la gestione di grandi dataset. Il punto è che MapReduce si è rivelato più lento di altre soluzioni, principalmente perché non adotta una tecnologia in-memory. Da questo punto di vista sono molto più performanti altri framework, come Apache Spark.
Spark elabora i dati in modalità in-memory, mentre MapReduce li deposita in modo persistente sul disco, dopo avere eseguito il lavoro di mappatura e riduzione.
Il problema della memoria
Questo non significa che Spark non abbia bisogno di molta memoria. Esso infatti carica un processo e lo mantiene in memoria fino a nuovo ordine. Ciò può comportare un degrado importante delle prestazioni, specie quando si tratta di gestire una grande quantità di dati. Questo significa che non esiste una soluzione ottimale per tutte le situazioni. Se si tratta di svolgere calcoli iterativi, che si ripetono più volte sullo stesso insieme di dati, allora Spark dà il meglio di sé. Nei casi in cui, invece, vi è necessità di compiere processi di ETL (integrazioni e/o trasformazioni di dati), la tecnologia giusta è MapReduce.
Ci sono poi altri aspetti da considerare, non ultimo quello relativo alla semplicità di utilizzo. MapReduce, scritto in Java, è un framework di difficile programmazione. Spark è molto più amichevole, grazie alla sua architettura a blocchi.
D’altronde non ha neppure molto senso considerare Hadoop e Spark come alternative. Si tratta di tecnologie che possono lavorare anche in modo integrato, così come altre nate in questi anni per gestire lo streaming di big data in tempo reale. C’è chi parla addirittura di SMACK, con riferimento a uno stack che include Spark, Mesos, Akka e Kafka. In questa architettura DC/OS di Mesosphere funge da sistema operativo distribuito, Spark è la componente di processing dei dati (sia nel caso di streaming in tempo reale, sia batch), Cassandra e Kafka coprono la funzione di storage, mentre Akka il modulo di fast data ingestion/extraction.
Spindox ha messo a punto anche un modello architetturale proprietario, denominato Argus. Architetture simili sono pensate per affrontare la vera sfida dei big data, che è la velocità. Tanto che forse faremmo meglio a chiamarli fast data.
