Skip to Content

Image Logo

Back

IOT AND BIG DATA WITH LIFERAY

 

Abstract

Lo sviluppo web sta radicalmente cambiando, la crescita esponenziale di nuova tecnologie e tool di sviluppo ha semplificato di molto l'attività di implementazione del software ed ha aumentato la produttività degli sviluppatori.
Come tutte le evoluzioni, anche questa ha aperto nuovi orizzonti e l'avanzamento tecnologico, unito alla riduzione dei costi dell'hardware, ci ha portato in una nuova era dove a farla da padrone sono sensori e dispositivi intelligenti. L'avvento dell'IoT (che non necessariamente si traduce in una problematica BigData) ha spostato le esigenze del pubblico, al quale non basta più visualizzare le informazioni su una piattaforma web, ma desidera anche controllare i dispositivi che inviano tali informazioni ed analizzarle secondo propri criteri.
Sono molte le tecnologie presenti sul mercato che permettono di realizzare un'architettura server in grado di gestire l'IoT (anche ad alte frequenze), molte di queste sono servizi cloud, ovvero servizi che danno a disposizione altri servizi, ma il collegamento tra di essi deve essere comunque "implemetato". Altri invece, forniscono un'infrastruttura completa, gestendo interamente il processo di acquisizione, salvataggio, visualizzazione e analisi del dato, ma spesso queste soluzioni sono prodotti a pagamento e non OpenSource.
La tematica dell'IoT e dei BigData, nella mia personale esperienza, si è scontrata anche con il mio interesse verso Liferay, che considero una tecnologia che a livello Enterprise fa davvero la differenza. Avendo quindi acquisito una commessa su IoT e BigData e dovendo anche progettare e realizzare un'infrastruttura server per l'acquisizione e la presentazione dei dati, ho pensato proprio di avventurarmi in questo fantastico mondo realizzando, quella che secondo me può essere un'architettura di riferimento nell'ecosistema Liferay per offrire soluzioni nel campo dell'IOT e dei Big Data.

Il Problema

Il progetto che mi è stato proposto consiste in un portale destinato alla visualizzazione e alla condivisione di dati provenienti da alcuni sensori collocati su un wearable computer. Questi sensori acquisiscono dati di vario genere (purtroppo mi è impossibile dare ulteriori dettagli poiché il progetto è in corso ed è coperto da segreto industriale) ad alte frequenze (anche dati a 100Hz) che vengono inviati tramite WiFi o rete GSM verso un cloud che deve:

  • Acquisire il dato, deserializzandolo
  • Dare la possibilità ad un utente di visualizzare il realtime in una sua pagina personale
  • Salvare i dati
  • Effettuare del post-processing sui dati acquisiti: in particolare deve essere possibile definire degli algoritmi da caricare sull'infrastruttura cloud e farli partire secondo degli scheduling definiti dagli amministratori di portale

Altri requisiti sono:

  • Implementazione di una parte social del portale dove gli utenti possono condividere queste "esperienze" di rilevazioni
  • Avere meccanismi di friendship/fellowship
  • Avere una parte di front-end che presenti il prodotto
  • Dare al cliente la completa gestione delle pagine e dei contenuti multimediali sul portale

Mentre la prima parte di richieste mi ha fatto sicuramente pensare ad una tematica sia IoT ma anche alla gestione BigData, la seconda invece mi portava dritto dritto verso Liferay. Inoltre, c'è un punto di contatto tra i due rami di specifiche, ovvero che sul portale bisogna mostrare i dati in realtime e soprattutto che c'è una parte di gestione degli algoritmi da caricare e far eseguire.
Da qui è iniziato uno studio che mi ha portato alla definizione di un'archiettura al centro della quale vi è Liferay inteso come gestore delle altre tecnologie utilizzate.

L'architettura

L'immagine di seguito mostra quello che è una prima versione del cluster:


Partiamo con analizzare i tipo di utenti che vengono identificati:

  • Tester: Utente che possiede il dispositivo, che effettua quindi la "rilevazione" inviando i dati, in streaming o in differita, sul cloud
  • PortalUser: Utente che accede al portale e vuole visualizzare i dati in realtime dell'utente che sta effettuando la rilevazione.

Inoltre, l'immagine riporta in rosso due percorsi possibili per ogni pacchetto inviato:

  • Data Saving Path: percorso obbligatorio per ogni pacchetto che, dopo aver attraversato differenti layer, arriva ad essere salvato su un database Cassandra
  • Realtime Path: Percorso opzionale che si attiva solo nel momento in cui un utente è sulla pagina personale di un altro che sta effettuando una rilevazione. In questo caso, il pacchetto arriva direttamente (tramite websocket) sulla pagina e viene mostrato all'interno di un grafico.

Si possono identificare, dunque, le seguenti tematiche:

  • Serializzazione dei messaggi
    • ProtoBuf Google
  • Broker di messaggi
    • Apache ActiveMQ (MQTT)
    • Apache Kafka
  • Streaming
    • Apache Storm
  • NoSQL
    • Apache Kafka
  • Micro-Batching
    • Apache Spark
  • Portale
    • Liferay

Di seguito, per alcuni dei punti indicati, andremo nel dettaglio per capire meglio come sono stati realizzati.

Serializzazione dei messaggi

Per l'efficienza della comunicazione è stato utilizzata la tecnologia ProtoBuf di google. Tale soluzione permette di definire un file ".proto" inserendo al suo interno la specifica dei vari pacchetti inviati. Una volta terminata la stesura del file, si procede alla sua compilazione che produce come output una classe Java (si può produrre l'output in differenti linguaggi) che può essere condivisa tra il server (che deserializza il dato) ed il client (che serializza il dato).
Esistono in realtà strumenti molto più avanzati di questo come ad esempio Apache Avro, ma per questione di tempistiche si è scelto di andare verso i protoBuf e non si esclude affatto una futura
integrazione di Avro.

Brokers di messaggi:MQTT e Kafka

I requisiti iniziali per lo streaming riguardavano principalmente la sicurezza del dato ed il fatto che ogni utente deve visualizzare solo i dati per i quali gli è stato consentito l'accesso (ovvero si possono visualizzare solo i dati dei propri "amici"). Se questa tematica in una normale applicazione è quasi banale, nello streaming dei dati non lo è. Infatti, utilizzando MQTT che è un protocollo publish/subscribe bisogna impedire che un utente possa registrarsi a dei topics che non gli competono. Inoltre, gestendo le relazioni di "amicizia" tra gli utenti, ed i relativi permessi, in Liferay, si è presentato fin da subito l'esigenza di "collegare" l'identificazione e l'autorizzazione dell'utente sul broker MQTT con l'identificazione e autorizzazione dell'utente su Liferay, quindi una sorta di SSO tra i due componenti. Ma andiamo con ordine.

MQTT – ActiveMQ

Come è stato detto in precedenza, MQTT è stato selezionata come protocollo di riferimento per la trasmissione dati, avendo anche una versione SSL. La scelta del broker è ricaduta sul prodotto Apache ActiveMQ che integra un connettore specifico per MQTT, per i seguenti motivi:

  • Si intendeva realizzare uno stack Apache
  • è configurabile in cluster
  • è semplice da customizzare (almeno per la mia esperienza)
Plugin Custom per gestione della sicurezza del broker su Liferay

Il device che desidera inviare i dati si connette al broker utilizzando le credenziali salvate all'interno di liferay sarà compito del broker validarle e restituire al client la lista dei topics ai quali è consentito l'accesso per l'utenza fornita.
Se un utente tenta di iscriversi ad un topic per il quale non ha accesso, la richiesta di iscrizione viene rigettata.
Per fare questo è stato sviluppato un plugin di sicurezza custom per ActiveMQ che si interfaccia con Liferay per la validazione delle credenziali e dei topic ai quali gli utenti si iscrivono.

Plugin Custom per il forward verso Kafka

Una volta che il pacchetto giunge sul broker, questo segue il percorso "obbligato" verso apache Kafka. Nel paragrafo successivo verranno argomentate le motivazioni che hanno portato al "doppio broker". Il passaggio del pacchetto verso Kafka è stato implementato tramite Apache Camel che è direttamente integrato all'interno di ActiveMQ ed è semplicemente una riga di configurazione. In tale impostazione si indica al broker MQTT di fare il "forward" di tutti i messaggi verso una risorsa Kafka (Camel ha già al suo interno un connettore per Kafka).

Scalabilità dello streaming ed integrazione di Kafka

A questo punto la domanda sorge spontanea, perché due livelli di broker? Non basta solo il broker MQTT? La risposta è: dipende.
Inizialmente nella fase prototipale, lo streaming MQTT arrivava direttamente a Liferay in questa casistica il problema era relativo al caso in cui ci fossero state più istanze in cluster di liferay.
Ogni istanza, essendo registrata sui topic del broker avrebbe ricevuto tutti i pacchetti causando una duplicazione dei pacchetti inviati. Questo era inaccettabile. Per evitarlo è stato introdotto
Kafka che ha una gestione dei gruppi. Il pacchetto da Kafka viene consumato solo da un'istanza per gruppo. Quindi, in sostanza è bastato registrare le istanze in cluster di liferay ad un singolo
gruppo Kafka. Questo approccio è molto utile per scalare le soluzioni MQTT.

Successivamente,nella fase di sviluppo, la parte di streaming si è spostata da Liferay, verso Apache Storm, ma nonostante questo cambio la struttura del doppio broker è stata mantenuta per i seguenti motivi:

  • Kafka rappresenta un secondo layer di parallelismo per lo strato di broking dei messaggi
  • Kafka implementa un meccanismo di message retention che permette di mantenere il dato anche se non vi è alcun consumer connesso
  • Kafka divide concettualmente il suo storage interno in partizioni, ogni partizione può essere "consumata" da thread differenti, aumentando la capacità di parrallelizzare il consumo dei messaggi
  • Kafka si integra nativamente con Apache Storm rendendo robusta l'intera infrastruttura di streaming

Nonostante tutti questi pro non si esclude la possibilità di fare un'analisi ulteriore per ridurre i broker di messaggi.

Streaming: Apache Storm

Apache storm è una soluzione che permette di definire delle vere e proprie topologie di streaming.
Ogni topologia è composta da nodi di differente tipo: Spout e Bolts. I primi rappresentano i nodi sorgente, ovvero dei componenti che si "connettono" all'esterno (nel nostro caso Kafka) per prelevare i dati. I Bolts sono nodi che processano i dati che vengono immessi nella rete. Questo tipo di approccio permette di avere differenti livelli di parallelismo:

  • All'interno di una singola istanza (inteso come nodo del cluster): aumentando il numero di componenti che processano i dati (sia gli spouts che i bolts)
  • Scalando orizzontalmente il cluster aumentando il numero di macchine all'interno del cluster stesso.

Questa parte attualmente comunica con Liferay (per la sincronizzazione di alcune entità) tramite servizi REST, ma nelle future versioni si potrà introdurre all'interno del portale stesso una portlet di controllo e gestione delle topologie Storm (o anche la definizione di una nuova rete mediante Apache Thrift).
Una volta arrivato su Kafka il dato viene prelevato dagli Spouts della topologia Storm, e salvato su cassandra.

Visualizzazione realtime in Liferay

Se l'utente è sulla pagina di portale predisposta per il realtime, vedrà fluire i dati in realtime mostrati all'interno di un grafico. Questa portlet di visualizzazione realtime è stata implementata sviluppando due componenti lato server:

  • Connettore MQTT
  • WebSocket

In particolare, non appena un utente entra in pagina, viene inizializzato il componente WebSocket, che al suo interno ha un client MQTT. All'inizializzazione della pagina il componente:

  • Si connette al broker e si registra ai topic relativi all'utente connesso
  • Apre il websocket tra il server e la pagina

La magia avviene proprio in questo componente: essendo il websocket anche registrato al broker, non appena viene notificat la ricezione di un messaggio dal broker MQTT, questo viene inviato sul
websocket. In questo modo non appena i dati sono disponibili vengono immediatamente resi disponibili al thread javascript della pagina che li renderizzerà nel grafico.

Micro-batching: Apache Spark

Il cliente ha richiesto la possibilità di far caricare ai propri sviluppatori degli algoritmi all'interno della piattaforma, al fine di analizzare i dati salvati. Tali algoritmi devono essere schedulati in maniera configurabile ad esempio: all'inizio di una rilevazione o alla fine, oppure schedulati solo se la rilevazione è di un certo tipo.
Per fare questo, è stato sviluppato una portlet all'interno del pannello di controllo di Liferay che comunica direttamente con Apache Spark.
Spark è una tecnologia che permette di implementare micro-batching. Anche questa soluzione prevede la possibilità di fare "streaming" in stile storm ma in realtà è sempre un streaming in modalità micro-batch che in alcuni casi potrebbe comunque risultare utile.
Il compito della portlet sviluppata è dialogare tramite servizi REST con spark, inviando i Jar degli algoritmi che vengono caricati da pannello di controllo e controllando lo stato dei job eseguiti.

Apache Spark Job Server

Per implementare questo tipo di funzionalità si è sfruttato un progetto OpenSource chiamato Spark-JobServer che espone dei servizi REST permettendo quindi il dialogo diretto con Spark.

LIoT Plugins for Liferay

Al termine di una prima fase di questo progetto, tutte le soluzioni sviluppate sono state ripensate e reimplementate dentro un plugin per il Marketplace di Liferay. Il plugin si chiama "LIoT-Plugins
for Liferay" (Liferay Internet Of Thing Plugins for Liferay). Di seguito viene riportato un link al video che spiega come utilizzarlo:

https://www.youtube.com/watch?v=Epy_b2R_bEc&feature=youtu.be

 

 
Previous
Comments
No comments yet. Be the first.

Recent Post

Informativa Cookies
Questo sito o gli strumenti terzi da questo utilizzati si avvalgono di cookie necessari al funzionamento ed utili alle finalità illustrate nella cookie policy.
Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie.