Nel precedente post abbiamo definito una architettura di data processing affidabile e performante, allo scopo di collezionare i dati di utilizzo di progetti Google Cloud Platform e renderli disponibili per l’analisi. Tale architettura si compone dei seguenti elementi:

  • Google Cloud Platform Billing Export: il meccanismo che estrae i dati di utilizzo di ogni progetto: costituisce la sorgente dei nostri dati.
  • Google Cloud Storage: servizio di block storage scalabile e affidabile, utilizzato come area di staging per i file JSON prodotti da Billing Export.
  • Google Cloud Functions: piattaforma Serverless per l’esecuzione di microservizi event-based. Costituisce lo strato di ETL (Extract-Transform-Load) della nostra soluzione.

In questa seconda parte esploriamo gli strumenti di analisi che consentono di estrarre rapidamente informazioni dai dati collezionati.

  • Google BigQuery: Data Warehouse analitico che garantisce prestazioni di interrogazione near-real-time su dataset massivi (Terabyte/Petabyte).
  • BIME: Strumento di dashboarding e reporting Cloud-based, interagisce con Google BigQuery per realizzare grafici e visualizzazioni interattive a partire dai dati.
  • Google Cloud DatalabBETA: strumento per l’analisi esplorativa dei dati, colleziona una serie di potenti strumenti di elaborazione e visualizzazione in una conveniente interfaccia notebook-style.

Architettura (parte 2)

Google BigQuery

Arthur C. Clarke, visionario scrittore di fantascienza – famoso principalmente per il soggetto e la sceneggiatura del film 2001: Odissea nello spazio – ha formulato nel suo libro “Hazards of Prophecy: The Failure of Imagination” quella che è divenuta famosa come Terza legge di Clarke:

“Qualunque tecnologia sufficientemente avanzata
è indistinguibile dalla magia.”

Cos’ha a che fare la terza legge di Clarke con Google BigQuery? Date un’occhiata a questa query:

SELECT language, SUM(views) as views FROM [bigquery-samples:wikipedia_benchmark.Wiki10B] WHERE REGEXP_MATCH(title,"G.*o.*o.*g") GROUP BY language ORDER BY views DESC

Niente di speciale: i record di una tabella vengono filtrati sulla base di una espressione regolare, poi un aggregato è calcolato raggruppando secondo il campo language. Ciò che rende veramente speciale questa query è il fatto che la tabella di origine contiene più di 10 miliardi (sic!) di record, e la sua esecuzione in BigQuery richiede meno di 10 secondi. Per rendere le cose più chiare: le performance di BigQuery consentono di applicare una operazione di REGEXP_MATCH su ognuno di quei 10 miliardi di record in meno di 10 secondi – trascurando il tempo (per la verità non trascurabile) necessario al raggruppamento. Sono più di 1 miliardo di operazioni al secondo. No, non si tratta di magia, ma inizialmente anch’io ho avuto qualche dubbio.

Vediamo quindi come una tale potenza di fuoco può essere messa in azione nel nostro scenario: per chi avesse perso l’episodio precedente, ricordo che abbiamo a che fare con tabelle giornaliere (BILLINGyyyyMMdd) che contengono i dati di utilizzo delle risorse Cloud Platform all’interno di vari progetti e Billing Account.

Year-to-date

Grazie al meccanismo delle Wildcard Tables, possiamo prendere in considerazione intervalli temporali arbitrari: un caso comune è costituito dalle analisi Year-to-date o Month-to-date – dall’inizio dell’anno/mese corrente fino ad ora.

Ecco quindi la somma dei costi per ogni Billing Account a partire dall’inizio dell’anno.

SELECT
accountName,
SUM(cost.amount)
FROM TABLE_DATE_RANGE(noovle_billing_analytics.BILLING,TIMESTAMP(UTC_USEC_TO_YEAR(CURRENT_TIMESTAMP())),CURRENT_TIMESTAMP())
GROUP BY
accountName

Notate l’utilizzo di funzioni dinamiche come CURRENT_TIMESTAMP() all’interno della funzione TABLE_DATE_RANGE() di selezione dell’intervallo temporale.

Trailing averages

Nell’analisi di time series, è spesso utile calcolare medie mobili per valutare l’andamento delle misure attenuando gli effetti di eventuali fluttuazioni momentanee. BigQuery supporta l’utilizzo di Window Functions che permettono di specificare aggregazioni di questo tipo con una sintassi compatta:

SELECT
accountName,
data,
AVG(cost) OVER (PARTITION BY accountName ORDER BY data ASC ROWS BETWEEN 7 PRECEDING AND CURRENT ROW) AS trailingAverage
FROM (
SELECT
accountName,
startTime AS data,
SUM(cost.amount) cost
FROM
TABLE_DATE_RANGE(noovle_billing_analytics.BILLING,TIMESTAMP(UTC_USEC_TO_YEAR(CURRENT_TIMESTAMP())),CURRENT_TIMESTAMP())
GROUP BY
accountName,
data
ORDER BY
data ASC)

Il valore trailingAverage viene calcolato per ogni giorno come media della spesa relativa ai sette giorni precedenti: in questo modo si eliminano le fluttuazioni dovute ad eventuali variazioni di utilizzo nel fine settimana. Notate anche l’utilizzo di subqueries per organizzare logicamente la query.

Cohort analysis

Quando i dati presentano molte dimensioni di analisi, è spesso utile individuare dei cluster di elementi su cui calcolare aggregazioni – una operazione a cui ci si riferisce con il termine Cohort analysis. Nell’esempio che segue, classifichiamo ogni Billing Account sulla base del suo utilizzo di Google App Engine (GAE). Specificamente, attraverso le funzioni EVERY() e SOME(), individuiamo tre categorie (o coorti) di Account: quelli il cui utilizzo è esclusivamente limitato a GAE, quelli che usano GAE insieme a qualche altro servizio, e quelli che non usano affatto GAE. Per ognuna di queste categorie calcoliamo, a titolo di esempio, la media di spesa annuale.

SELECT
allAppEngine,
someAppEngine,
noAppEngine,
AVG(costAmount) costAverage
FROM (
SELECT
accountId,
SUM(costAmount) costAmount,
EVERY(isAppEngine) allAppEngine,
SOME(isAppEngine) someAppEngine,
NOT SOME(isAppEngine) noAppEngine
FROM (
SELECT
accountId,
IF(LOWER(lineItemId) CONTAINS "com.google.cloud/services/app-engine",TRUE,FALSE) isAppEngine,
cost.amount AS costAmount
FROM
TABLE_DATE_RANGE(noovle_billing_analytics.BILLING,TIMESTAMP(UTC_USEC_TO_YEAR(CURRENT_TIMESTAMP())),CURRENT_TIMESTAMP()))
GROUP BY
accountId)
GROUP BY
allAppEngine,
someAppEngine,
noAppEngine

Molte altre funzioni sono disponibili, tutte documentate sulla relativa pagina della documentazione.

BIME Analytics

Google BigQuery è qui per fare la gioia dei Data Analyist, d’accordo. Ma i dati, affinché diventino actionable insights realmente utili, devono essere condivisi con i decision makers; e in quel caso, un’immagine vale più di mille tabelle.

bime dashboard

Tra i numerosi strumenti di reporting e visual analytics presenti sul mercato, BIME presenta alcune caratteristiche che lo rendono interessante per il mondo Cloud. In primo luogo, è esso stesso un prodotto Cloud, che non richiede installazioni software o particolari configurazioni per essere utilizzato. In secondo luogo, la sua semplicità d’uso (sebbene limiti le sue potenzialità rispetto ad alcuni suoi “fratelli maggiori”) lo rende uno strumento estremamente agile e versatile.

BIME è dotato di una serie di connettori che lo integrano con le sorgenti dati più disparate: dai tradizionali RDBMS ai social networks, da semplici spreadsheet a strumenti OLAP come BigQuery. Una caratteristica interessante è costituita dalla funzionalità Query Blender, che consente di fondere sorgenti diverse in un’unica visualizzazione: un esempio ricorrente è una serie temporale su BigQuery che fa riferimento ad una anagrafica su un RDBMS (per esempio Google Cloud SQL).

BIME_Studio_1

 

L’autenticazione verso BigQuery avviene attraverso le proprie credenziali Google. La selezione di progetti, dataset e tabelle,  così come la creazione della dashboard vera e propria, è semplificata da un’interfaccia dinamica e user-friendly.

BIME_Studio

Al termine della realizzazione della dashboard, è possibile scegliere la sua modalità di condivisione (privata, protetta da username/password o tramite autenticazione Google, pubblica).

Google Cloud DatalabBETA

Cloud Datalab è un tool interattivo per esplorare, analizzare e visualizzare dati su Google Cloud Platform. Nasce dal progetto open source Jupyter, e da esso eredita l’interfaccia di editing, basata su notebook interattivi e condivisibili.

Datalab abilita l’analisi di dati su Google BigQuery, Google Compute Engine e Google Cloud Storage, utilizzando Python, SQL e Javascript. Le possibilità di eseguire Datalab vanno da una modalità totalmente client-based (basata su container Docker), a una modalità totalmente Cloud-based (su una istanza Compute Engine), fino a una modalità ibrida, in cui un client locale sfrutta tutta la potenza di calcolo di Google Cloud Platform per svolgere le computazioni, mantenendo tuttavia la definizione dei notebook sulla propria macchina.

Una volta avviato, Datalab offre un’interfaccia per la creazione di nuovi notebook. Nel nostro caso replichiamo una delle query descritte nei paragrafi precedenti, per poi visualizzarne il risultato in forma grafica.

analisi di coorte

Come riportato in figura, i notebook consentono di intercalare snippet di codice a sezioni rich-text, utili per descrivere passo per passo le operazioni della propria procedura.

Il nostro notebook si compone di due soli snippet: uno esegue la query, l’altro visualizza un grafico. Nel primo caso, occorre anteporre alla query SQL che eseguiremmo su BigQuery l’intestazione %%sql –module <nome-modulo>. In questo modo specificheremo a Datalab che quella cella contiene una query SQL che deve essere associata alla label <nome-modulo>, così da poterla indirizzare da altre celle.

%%sql --module cohorts
SELECT accountId
...

L’altra cella contiene la definizione di un grafico secondo la sintassi delle Google Charts API:

%%chart bars --fields label,costAverage --data cohorts
title: App Engine usage
height: 600
width: 800

Notate alla riga 1  il riferimento al modulo cohorts e ai campi label e costAverageUn apposito pulsante permette di eseguire interattivamente il codice di ogni cella. Il risultato finale è questo:

Cohort_analysis

da cui evinciamo il seguente (prevedibile) risultato: i progetti che insieme ad App Engine coinvolgono altre risorse Cloud Platform comportano mediamente una spesa mensile maggiore.

Al di là della scarsa utilità di questa specifica analisi, appare chiaro il valore di uno strumento come Cloud Datalab in un contesto di Data Analysis. La possibilità di implementare query SQL complesse, script di processing e visualizzazioni grafiche in un ambiente integrato, performante e flessibile, dà modo agli esperti di esprimere al meglio le proprie skills seguendo un approccio iterativo di tipo try → fail → learn → repeat.

Eccoci giunti al termine di questo viaggio nel mondo della Serverless Data Analysis! Il nostro intento era quello di farvi “dare una sbirciatina” sul panorama delle smisurate possibilità che si aprono nel seguire un approccio di questo tipo… Speriamo di aver solleticato il vostro appetito!

Ti è piaciuto l’articolo? Lo hai trovato interessante, sbalorditivo e anche utile? Ecco allora è il caso che vieni al Change the Game mercoledì 5 ottobre, perchè potremmo affrontare questi temi di persona, perchè sentirai le testimonianze concrete di aziende che fanno del Cloud il loro driver strategico di Business e perchè avrai i responsabili della divisione di Google Cloud Platform proprio di fronte a te! Non esitare, registrati qui.