Apache Storm 1.0 – Novità dell’ultima release

L’ultima major release di Apache Storm 1.0 introduce diverse nuove features e miglioramenti. Vediamone qualcuna insieme in attesa del rilascio ufficiale di Storm nella prossima HDP 2.5 prevista per la fine di questo mese.

Apache Storm 1.0

Migliorate le performance

Rispetto alle precedenti release, Storm 1.0 è più veloce di 16 volte con una latenza ridotta fino al 60%. Ovviamente dipende da come viene sviluppata la topologia!

Distributed Cache API

Se uno sviluppatore deve interagire con dati esterni da Storm, ad esempio dati di lookup, in genere va ad “impacchettare” nel jar della topologia file xml, csv o di altro tipo per poi accedere ai dati all’occorrenza. Quando i dati di lookup cambiano è necessario ricompilare e rifare il deploy della topologia. Storm 1.0 introduce una cache distribuita e un set di API che permettono di condividere i file (detti BLOBs) tra le topologie. I file possono così essere aggiornati ogni volta nella cache via command line, senza aver bisogno di ricompilare e ridistribuire una topologia.

Esistono due implementazioni della cache distribuita: una per il file system locale sui nodi del Supervisor e una che punta al file system distribuito hadoop (HDFS).

HA Nimbus

La nuova versione supporta il servizio di alta affidabilità (HA) verso Nimbus: in caso di architettura con più istanze di Nimbus, nel caso in cui un nodo fallisce, il servizio eleggerà il nuovo “leader” in modo automatico garantendo una funzionalità continua della topologia.

Native Streaming Window API

E’ una pratica comune analizzare un set di dati durante lo streaming in real-time per poter definire ad esempio il topic trend dell’ultima ora (es. Twitter). In questa versione Storm ha introdotto nativamente le windowing che permettono di fare questo tipo di elaborazioni a runtime. E’ quindi possibile analizzare un set definito – su base temporale o su una lunghezza – di tuple e applicare aggregazioni, join, pattern matching e tanto altro. Analizzeremo in dettaglio questa feature in un prossimo post vedendo insieme alcuni esempi.

Stateful Bolts

Come sappiamo, Storm normalmente lavora in modalità “stateless” e questo gli permette di lavorare con una grande mole di dati, in streaming garantendo prestazioni molto elevate. Se vogliamo salvare lo stato di un bolt in caso di failure dobbiamo necessariamente implementare un sistema ad hoc (attraverso cache ad esempio oppure utilizzando Trident) per capire in che stato si trovava il nostro bolt in quel momento. La versione 1.0 introduce una gestione degli stati con una nuova classe – BaseStatefulBolt – che permette di implementare, semplicemente estendendo la classe, un bolt di tipo stateful. Storm automaticamente gestirà lo stato del bolt e lo memorizzerà in caso di failure. Per il momento, lo stato viene gestito in memory da Redis, le future implementazioni includeranno anche altri tipi di supporti di memorizzazione.

Dynamic Log Levels

Adesso è possibile cambiare dinamicamente, sia attraverso Storm UI che via command line, il log level da applicare alla topologia specificando eventualmente il timeout dopo il quale il sistema ritorna al livello della situazione iniziale. Inoltre è possibile cercare facilmente i log attraverso la UI e il logviewer service.

Distributed log search

Già Storm 0.9.1 ha introdotto una metodologia più semplice per analizzare i file logs attraverso un log file viewer. La difficoltà per l’utente è stata quella di individuare il giusto file log da leggere ed analizzare, capire dove è stato salvato e quindi da dove leggerlo. Storm 1.0 introduce una feature per la ricerca distribuita che permette quindi di cercare uno specifico log file in tutti i nodi di tutti i supervisor. Il risultato di questa topology-wide search includerà il link al file e le informazioni sull’host dove è possibile trovare il file log specificato.

Tuple Sampling and Debugging

Finora in fase di debug di una topologia era necessario creare dei bolts ad hoc per analizzare i dati in ingresso e la loro trasformazione in Storm per poi visualizzarli, salvarli o inviarli ad altri sistemi per lo studio del problema in corso. La versione 1.0 introduce una nuova feature di topology debug: attraverso Storm UI sarà possibile analizzare un sample di tuple gestite dalla topologia, visualizzarle direttamente o salvarle su disco. Un bel risparmio di tempo!

Dynamic worker profiling

Sempre attraverso Storm UI sarà possibile interagire con la JVM per conoscere velocemente le informazioni relative a:

  • Heap dumps, snapshot di tutti gli oggetti allocati nella JVM heap
  • JStack output, stack traces di tutti i threads nel processo JVM
  • JProfile recordings, tool per la collection, il profiling e la diagnostica dell’applicazione JVM

I dati generati possono essere scaricati per un analisi offline con altri strumenti di debug tipici della JVM. Adesso è anche possibile riavviare i workers direttamente dalla UI.

In attesa che venga rilasciata ufficialmente la realese Hortonworks 2.5, possiamo testare la nuova release con la sandbox Tech Preview.

Add a Comment

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