Best practice per IoT in produzione: implementazione con Google Cloud (Parte 2/3)

L'articolo prosegue dalla Parte Uno, in cui abbiamo visto come integrare in sicurezza una flotta di dispositivi IoT in produzione che invia dati di telemetria all'ambiente Google Cloud tramite IoT Core e Pub/Sub.

Ottimo lavoro: hai registrato diversi dispositivi IoT. E adesso?

Il passo successivo è progettare un sistema che abiliti archiviazione, analisi e visualizzazione su larga scala dei tuoi dati, oltre alla creazione di dashboard.

Per riuscirci, occorre definire in anticipo un'architettura del flusso dati capace di sostenere operazioni di queste dimensioni. In questo articolo trovi una guida pratica passo passo per farlo.

Panoramica

L'articolo è suddiviso nelle sezioni che seguono:

1. Caricamento batch nei data sink
2. Archiviazione e analisi dei dati
3. Visualizzazione dei dati nel data warehouse

A differenza della prima parte, tutto ciò che vedremo qui può essere fatto interamente dalla console web di GCP. È sufficiente una conoscenza base di SQL.

Vedremo i seguenti servizi Google Cloud, tutti completamente gestiti e con auto-scaling:

• Pub/Sub — coda di messaggi serverless
• Dataflow — motore di elaborazione dati in streaming e batch
• BigQuery — data warehouse serverless
• Data Studio — servizio per la visualizzazione dei dati e la creazione di dashboard

Caricamento batch nei data sink

Verificare l'arrivo dei messaggi

Se hai integrato correttamente i dispositivi nel registro IoT e hai avviato lo streaming dei dati verso IoT Core, dalla dashboard principale di GCP IoT dovresti vedere un flusso costante di messaggi in arrivo:

Tre dispositivi connessi correttamente che trasmettono dati di temperatura ogni cinque secondi

Come illustrato nella Parte Uno, gli stessi messaggi confluiscono anche nel topic Pub/Sub 'temperature':

Messaggi Pub/Sub in arrivo nel topic 'temperature'

Streaming verso BigQuery

Bene: i messaggi arrivano in Google Cloud. Ora dobbiamo trasferire i messaggi Pub/Sub in un data warehouse, dove i dati possano restare per una conservazione a lungo termine a costi contenuti e per analisi facilmente scalabili. È qui che entra in gioco BigQuery.

BigQuery, il data warehouse serverless di Google Cloud, completamente gestito e con auto-scaling, ti consente di pagare sia il calcolo sia lo storage con un modello di pricing on-demand: un data sink ideale per archiviare e analizzare i nostri dati IoT.

Ma come si fa lo streaming dei messaggi Pub/Sub verso BigQuery? Con Dataflow.

Dataflow, la versione completamente gestita e con auto-scaling di Apache Beam targata Google Cloud, è pensato per spostare dati da un servizio all'altro. Permette, in modo opzionale, di filtrare e trasformare i dati e di ottimizzare il caricamento batch verso servizi soggetti a limiti sulle operazioni di caricamento, come database e soluzioni di data warehousing.

Dataflow include diversi template predefiniti realizzati da Google Cloud, tra cui un template Pub/Sub-to-BigQuery: non serve quindi scrivere una riga di codice per collegare l'acquisizione dei dati ai servizi di archiviazione e analisi.

Dato che Pub/Sub, Dataflow e BigQuery sono tutti servizi completamente gestiti e con auto-scaling, e (con la sola eccezione di Dataflow) anche serverless, è possibile costruire un sistema end-to-end di gestione dei dati IoT che scala senza sforzo dai test di sviluppo a operazioni nell'ordine dei petabyte, con una gestione dell'infrastruttura praticamente nulla durante lo scaling.

Vediamo questi servizi in azione, collegati tra loro!

Configurare la sottoscrizione Pub/Sub

Prima di trasferire i dati da Pub/Sub a Dataflow, conviene creare una sottoscrizione Pub/Sub agganciata al topic.

Perché? I messaggi che arrivano a un topic Pub/Sub vengono inviati subito ai subscriber del topic (con strategia Push) e poi rimossi dal topic. I subscriber, invece, possono trattenere i messaggi finché un processo non li richiede (con strategia Pull). È possibile collegare Dataflow direttamente a un topic anziché a una sottoscrizione, ma se il job Dataflow subisse un'interruzione, i messaggi che arrivano al topic durante il downtime andrebbero persi.

Collegando invece Dataflow a una sottoscrizione Pub/Sub agganciata al topic, eviti la perdita di messaggi durante un'interruzione. Se il job Dataflow venisse messo in pausa, tutti i messaggi IoT non ancora elaborati resterebbero nella sottoscrizione Pub/Sub in attesa che il job riprenda a estrarli.

Una sottoscrizione Pub/Sub a un topic crea quindi un'architettura dati resiliente alle interruzioni dei servizi di acquisizione a valle.

Per creare una sottoscrizione in Pub/Sub:

1. Vai a Subscriptions
2. Fai clic su "Create Subscription" e chiama la sottoscrizione "temperature_sub"
3. Aggancia la sottoscrizione al topic Pub/Sub "temperature"
4. Lascia le altre opzioni ai valori predefiniti

Creazione della sottoscrizione Pub/Sub 'temperature_sub' al topic Pub/Sub 'temperature'

Una volta creata la sottoscrizione, facendo clic su di essa e poi su " Pull" dovresti vedere i primi messaggi in arrivo:

Esempio di messaggi in streaming nella sottoscrizione Pub/Sub

Archiviazione e analisi dei dati

Ora che la sottoscrizione Pub/Sub riceve i messaggi, siamo quasi pronti a creare un job Dataflow per spostarli in BigQuery. Prima però dobbiamo creare in BigQuery la tabella di destinazione dei dati provenienti da Dataflow.

Configurare la tabella BigQuery

Vai a BigQuery, fai clic su "Create Dataset" e chiama il dataset 'sensordata', lasciando le altre opzioni ai valori predefiniti:

Finestra di creazione del dataset BigQuery

Una volta creato il dataset, selezionalo, fai clic su " Create table" e chiama la nuova tabella "temperature". Assicurati di impostare lo schema e le opzioni di partitioning e clustering mostrate negli screenshot qui sotto: sono pensate per supportare i pattern di query più comuni.

Schema della nuova tabella BigQuery 'temperature'Opzioni di partitioning e clustering per la tabella 'temperature'

Se tutto è andato a buon fine, la nuova tabella vuota apparirà così:

Tabella BigQuery 'temperature' vuota all'interno del dataset 'sensordata'

Una volta caricati i dati, mostreremo un pattern di query IoT molto comune: eseguire analisi sui dati di un intervallo temporale specifico (ad esempio una finestra di un'ora del giorno corrente) per un determinato dispositivo.

Il design della tabella appena creata è ideale per query di questo tipo perché:

• Il partitioning sul campo timestamp UTC permette alle query con filtro per data di evitare la scansione delle partizioni DateTime relative ai giorni non interessati
• All'interno di una partizione, il clustering (ordinamento) su deviceId e timestamp epoch consente un recupero più efficiente dei dati per uno specifico dispositivo e intervallo temporale all'interno di quella partizione di data.

Per scrivere queste query servono dei dati nella tabella. Avviamo dunque il job Dataflow!

Configurare Dataflow

A questo punto abbiamo i messaggi in attesa nella sottoscrizione Pub/Sub e una tabella BigQuery pronta ad accoglierli. Manca solo il "collante" ETL che metta in comunicazione le due parti. Poiché Pub/Sub e BigQuery sono entrambi servizi completamente gestiti, con auto-scaling e serverless, idealmente vorremmo uno strumento ETL con le stesse caratteristiche.

Dataflow soddisfa (in larga parte) questi requisiti. Il marketing di Dataflow lo presenta come dotato di tutte e tre le caratteristiche, ma in realtà non è del tutto serverless. Devi infatti specificare tipo e dimensioni delle istanze, il numero minimo e massimo entro cui può oscillare l'auto-scaling, oltre allo spazio disco temporaneo necessario a ciascuna istanza. Non gestisci direttamente queste istanze né le decisioni di scaling, ma queste specifiche le devi comunque fornire. È una differenza rispetto a Pub/Sub e BigQuery, che si scalano automaticamente senza alcuna configurazione dell'infrastruttura.

Pur non essendo completamente serverless, Dataflow è perfetto per il nostro requisito ETL Pub/Sub-to-BigQuery. È anche semplice da usare, soprattutto perché GCP offre numerosi template predefiniti per i job Dataflow, incluso uno che supporta proprio un workflow Pub/Sub-to-BigQuery. A parte la necessità di alzare il numero massimo di istanze consentite dall'auto-scaling man mano che il throughput dei dati IoT cresce nel tempo, in teoria non dovrai mai preoccuparti della gestione dell'infrastruttura che alimenta Dataflow.

Chiariti i fondamentali, passiamo all'implementazione di un job Dataflow. Vai a Dataflow, fai clic su " Create Job from Template" e segui questi passaggi:

• Chiama il job 'pubsub-temp-to-bq'
• Usa il template di streaming predefinito 'Pub/Sub Subscription to BigQuery'
• Inserisci il nome completo della sottoscrizione Pub/Sub
• Inserisci l'ID completo della tabella BigQuery
• Indica il percorso di un bucket Cloud Storage in cui Dataflow possa archiviare i dati temporanei durante il caricamento batch in BigQuery
• Lascia le altre opzioni ai valori predefiniti. Di norma espanderesti le Advanced Options per indicare parametri come tipo e dimensione della macchina, valori min/max di auto-scaling e dimensione del disco per macchina. In fase di test, però, puoi tranquillamente lasciare i valori predefiniti.

La schermata di creazione del job Dataflow dovrebbe apparire così:

Dopo aver fatto clic su " Create" e atteso qualche minuto perché l'infrastruttura sottostante venga avviata, vedrai i dati fluire dalla sottoscrizione Pub/Sub alla tabella BigQuery di destinazione.

Lo script Python di streaming della temperatura fornito nella Parte Uno trasmette al ritmo di un record al secondo. Nel Directed Acyclic Graph (DAG) di Dataflow mostrato qui sotto dovresti quindi vedere x elementi al secondo in streaming, dove x è il numero di dispositivi con cui stai facendo i test. Nel mio caso, sono tre i dispositivi che trasmettono:

Messaggi inoltrati correttamente da Pub/Sub a BigQuery tramite un job Dataflow

Una volta verificato che il job Dataflow è attivo e sta trasferendo correttamente i dati della sottoscrizione Pub/Sub a BigQuery, puoi eseguire in BigQuery una query come la seguente e vedere i dati arrivare in tempo reale nella tabella:

SELECT *
FROM `iottempstreaming.sensordata.temperature`
WHERE DATE(timestamp_utc) = "2020-12-18"
ORDER BY timestamp_epoch DESC
LIMIT 10

Possiamo verificare che il filtraggio per partizione funziona osservando come la quantità totale di dati scansionati aumenti rimuovendo la clausola WHERE che filtra per giorno.

Con il mio dataset di esempio vengono scansionati 1,1 MB di dati filtrati (come visto sopra) e 1,7 MB di dati non filtrati (qui sotto):

SELECT *
FROM `iottempstreaming.sensordata.temperature`
ORDER BY timestamp_epoch DESC
LIMIT 10

Calcoliamo ora i valori medio, minimo e massimo di temperatura registrati da ciascun sensore nell'ultima ora:

SELECT
  device_id,
  ROUND(AVG(temp_f), 1) AS temp_f_avg,
  MIN(temp_f) AS temp_f_min,
  MAX(temp_f) AS temp_f_max
FROM `iottempstreaming.sensordata.temperature`
WHERE timestamp_utc > DATETIME_ADD(CURRENT_DATETIME(), INTERVAL -60 MINUTE)
GROUP BY device_id

Statistiche per ciascun dispositivo che trasmette dati di temperatura

Ottimo lavoro! Hai appena messo in piedi un workflow di dati completamente gestito end-to-end, dall'acquisizione fino al backend analitico. Prima di chiudere la guida, vediamo in pochi passaggi quanto sia semplice visualizzare questi dati con Data Studio.

Visualizzazione dei dati nel data warehouse

Inizia eseguendo in BigQuery una query simile alla seguente, che recupera tutte le righe di dati relative a un determinato giorno:

SELECT *
FROM `iottempstreaming.sensordata.temperature`
WHERE DATE(timestamp_utc) = "2020-12-18"
ORDER BY timestamp_epoch DESC

A destra di " Query Results", fai clic su " Explore Data" e poi su " Explore with Data Studio":

Verrà caricata una tabella che riepiloga i dati appena interrogati. Per impostazione predefinita, però, mostra una tabella poco interessante con il numero totale di record trasmessi al secondo.

Modifichiamo qualche valore nella sezione Data sulla destra per renderla più significativa:

• Imposta "Line Chart" come tipo di visualizzazione, al posto di "Table"
• Rimuovi "Record Count" come metrica e sostituiscila con "temp_f". Ricorda di cambiare la metrica predefinita da "SUM" ad "AVG".
• Aggiungi "device_id" come dimensione di breakout

Le impostazioni del layout della dashboard dovrebbero risultare simili a queste:

Il grafico mostrerà i valori di temperatura di ciascun dispositivo nel tempo, ma la scala automatica potrebbe non essere ottimale, dato che il valore minimo predefinito sull'asse y è zero. Per sistemarla, fai clic sulla scheda "Style", scorri fino all'opzione "Left Y-Axis" e imposta valori più adeguati:

Potresti anche voler aumentare il numero di punti dati visualizzabili nel grafico:

Con questi accorgimenti otterrai un grafico curato e interattivo, in cui scorrere i valori di temperatura dei dispositivi mentre fluttuano nel tempo:

Prossima tappa: Machine Learning

Non perdere la terza parte: costruiremo un modello di machine learning funzionante su questo dataset BigQuery e lo useremo per generare previsioni in tempo reale.