Revevol: creazione di dashboard BI con GCP per monitorare l'adozione di G Suite
Nota del redattore: vuoi sapere come utilizzare gli ottimi strumenti di analisi e visualizzazione dei dati offerti da Google Cloud Platform? Utilizzando una combinazione di App Engine, Cloud Storage, Cloud Dataflow, BigQuery e Data Studio, un partner di Google Cloud, Revevol, ha creato una serie di dashboard per aiutare un cliente a capire meglio come i suoi dipendenti utilizzano G Suite. Per saperne di più, continua a leggere!
In Revevol abbiamo implementato G Suite in dozzine di aziende, migrando oltre 400mila utenti e formandone 80mila con i nostri programmi di gestione delle modifiche. Dopo aver utilizzato G Suite per alcuni anni, uno dei nostri clienti più grandi, un'azienda industriale globale di 30mila dipendenti, voleva capire meglio come i suoi dipendenti utilizzassero effettivamente G Suite. Aveva bisogno di un approccio basato principalmente sui dati per fornire servizi e gestire le modifiche al fine di ottimizzare la collaborazione.
Ma con la loro complessa struttura organizzativa, era quasi impossibile rispondere a domande su come veniva utilizzata G Suite nell'ambito dell'organizzazione, quali erano i punti deboli per i dipendenti e come riuscire a migliorare utilizzando la Console Admin di G Suite. Quindi il nostro cliente si è rivolto a noi per ottenere un quadro completo dell'utilizzo di G Suite da parte dei suoi utenti basato sui log di attività e metadati.
Avendo un'attività GCP di lunga data, sia per i nostri progetti che per i nostri prodotti (come AODocs), ci siamo rivolti subito a GCP per trovare la soluzione migliore. Il cliente desiderava visualizzare i dati relativi all'utilizzo e all'attività filtrati in base a località, paese, regione, business unit e orario, e poter esportare i dati su fogli di calcolo per ulteriori analisi. Ciò comportava l'unione dei dati di G Suite Directory e dell'utilizzo di G Suite, e la loro visualizzazione tramite un dashboard filtrabile di Business Intelligence (BI) simile a questo:

Ecco come è strutturata l'architettura ad alto livello: estraiamo i dati dalle API G Suite utilizzando App Engine, li archiviamo in Google Cloud Storage, li trasformiamo in Cloud Dataflow e li archiviamo in BigQuery per ulteriori analisi. Quindi usiamo Data Studio per la visualizzazione. Andiamo a vedere ciascuno di questi componenti.
Estrazione dei dati
Il primo passo per creare una soluzione come questa è estrarre i dati. Ci sono due modi per farlo: le API REST e la funzione BigQuery Export.
API REST
G Suite offre un numero elevato di API REST che consentono di eseguire query sui metadati dei servizi, come i documenti archiviati in Google Drive e i log di attività. In questo caso, abbiamo sviluppato un modulo di estrazione su App Engine. App Engine è eccezionale perché è completamente serverless e può essere scalato senza dover modificare la configurazione, la capacità di provisioning o gestire il bilanciamento del carico.
Esistono numerose API da cui si possono estrarre i dati e ci sono due tipi di estrazioni: snapshot dello stato corrente e log di attività. Gli snapshot vengono estratti dalle API Directory, Drive o Groups Settings. L'estrazione della directory archivia un elenco di utenti in BigQuery. Per Drive, richiediamo tutti i documenti di proprietà di ciascun utente tramite la rappresentazione di un account di servizio, ossia un tipo speciale di account Google che appartiene all'applicazione anziché a un singolo utente finale. L'applicazione assume l'identità dell'account di servizio per chiamare le API di Google in modo che gli utenti non siano coinvolti direttamente. Grazie all'integrazione dell'identità tra G Suite e GCP, diventa un gioco da ragazzi.
Inoltriamo richieste all'API utilizzando Google Cloud Tasks. Ogni utente riceve i propri Task in una Task Queue, che vengono avviati al ritmo di 100 per volta. Tutte le risposte API vengono inviate al Cloud Storage. Se l'utente possiede così tanti documenti che è impossibile sfogliarli tutti nei 10 minuti concessi, il task dell'utente si aggiunge alla coda dei task. Anche quando non riescono, le estrazioni tornano in coda. Lo stato dell'estrazione viene mantenuto come contatore decrescente in Memcache, che viene aggiornato da ciascun task se ha un esito positivo. Quando il contatore raggiunge lo 0, il lavoro viene eseguito attivando i processi di backup/trasformazione.
Se hai prestato attenzione, probabilmente ti starai chiedendo cosa succederà ai Team Drive e come estrarre i dati dai documenti archiviati lì? Ottima domanda. Anche se, in qualità di amministratore, puoi ottenere l'elenco di tutti i Team Drive di un dominio, non è possibile elencare i documenti archiviati all'interno di questi Team Drive, quindi il processo è un po' complesso. Ecco come risolviamo la questione: per prima cosa elenchiamo tutti i Team Drive nel dominio. Quindi esaminiamo ciascun utente per trovare gli utenti appartenenti a ciascun Drive e poterli rappresentare con l'account di servizio e infine elenchiamo i file nel Team Drive.
Grazie alla potenza e alla flessibilità di Google Cloud Tasks, siamo stati in grado di implementare una coda di task parallela e coordinata molto facilmente, senza preoccuparci dei server, e di estrarre tutti i contenuti dei metadati di Drive di un'azienda di 35mila dipendenti in meno di 10 minuti. In effetti, il collo di bottiglia è la quota dell'API Drive.
Estrarre i log di attività è più semplice poiché provengono dall'API Report Admin, quindi non è necessario rappresentare tutti gli utenti. Essendo dati della serie temporale, li interroghiamo quotidianamente, attivati da un cronjob in App Engine che viene affidato a Task Queue.
BigQuery Export
A differenza di altri prodotti G Suite, i clienti di G Suite Enterprise possono esportare i log giornalieri di Gmail direttamente in BigQuery. Questo è un esempio della completa integrazione tra G Suite e GCP. Se esistessero possibilità di esportazione simili con altri servizi di G Suite, ignoreremmo completamente le API e implementeremmo l'intera soluzione senza scrivere una singola riga di codice (eccetto ovviamente le query SQL).
Trasformazione e archiviazione dei dati
I dati che sono stati esportati dalle API REST ora si trovano nel Cloud Storage di JSON raw e li teniamo lì per scopi di backup e archiviazione. Per l'analisi, tuttavia, dobbiamo copiarli su BigQuery. Alla fine di ogni estrazione viene inviato un messaggio a Cloud Pub/Sub a cui ci siamo abbonati utilizzando le Cloud Functions. La funzione cloud carica i dati utilizzando le API BigQuery e Cloud Storage.
Se vogliamo trasformare i dati prima che raggiungano BigQuery, possiamo utilizzare Cloud Dataflow in modalità batch. In caso contrario, possiamo utilizzare le query di BigQuery per creare tabelle trasformate dalle tabelle raw. La tua decisione sarà probabilmente influenzata dai due fattori seguenti:
- Costi: i modelli di prezzatura di BigQuery e Dataflow sono molto diversi. Se le tue trasformazioni analizzano spesso tabelle di grandi dimensioni, i costi di BigQuery possono essere elevati.
- Costi di manutenzione: in genere è più semplice mantenere Cloud Dataflow, e il relativo codice chiaro e leggibile, invece delle tipiche query SQL lunghe, complesse senza versione, che vengono archiviate nell'UI Web di BigQuery.
Al momento eseguiamo le trasformazioni in BigQuery poiché è più veloce da prototipare, ma prevediamo di spostare presto alcune delle trasformazioni più grandi in Cloud Dataflow. Possiamo anche provare Cloud Dataprep che potrebbe consentirci di descrivere le pipeline di trasformazione Dataflow senza scrivere codice, ma non l'abbiamo ancora provato.
Visualizzazione dei dati
Data Studio, un prodotto BI gratuito che fa parte di Google Marketing Platform (GMP), è un ottimo esempio della stretta integrazione tra Google Cloud e il vasto ecosistema Google. I dashboard di Data Studio rispettano gli stessi pattern di accesso di Documenti e Fogli Google (autorizzazioni utente, gruppo e dominio), hanno le stesse funzionalità di collaborazione in tempo reale e sono disponibili per chiunque disponga di un account Google.
Sin dall'inizio, il nostro cliente desiderava un dashboard per il servizio G Suite, e uno per Google Drive, Gmail, Hangouts Meet e così via. Data Studio fornisce un connettore a BigQuery, che consente la creazione di origini dati basate sulle tabelle BigQuery. Chi crea l'origine dati è l'unica persona ad avere bisogno di accedere al set di dati sottostante e le credenziali di G Suite consentono l'autenticazione nel background, senza dover configurare nulla.
Abbiamo creato un'origine dati per dashboard, a cui abbiamo aggiunto grafici e KPI tramite l'UI di Data Studio. Pertanto, senza scrivere alcun codice nel front-end o SQL, siamo in grado di visualizzare KPI e grafici basati su tabelle BigQuery, il tutto in un dashboard chiaro e professionale, oltre a poter aggiungere filtri.
Sebbene Data Studio sia un ottimo prodotto, ci sono alcune cose da tenere a mente, ad esempio:
- Avere funzioni di aggregazione aggiuntive come AVG_DISTINCT può aiutare a visualizzare il numero medio dei partecipanti alla riunione di Meet filtrati in base alla località.
- Se il semplice controllo degli accessi basato su G Suite/Drive non funziona per uno specifico caso d'uso, forse dovrai implementare una soluzione personalizzata utilizzando l'accesso a livello di riga in BigQuery o creando il tuo Community Connector.
- Sebbene esistano modelli riutilizzabili, le origini dichiarative (simili a YAML) sono ideali per industrializzare la gestione e la manutenzione del dashboard.
- Non esiste un modo semplice per approfondire i dati sottostanti utilizzati per creare il grafico.
- I controlli di sicurezza sulle origini dati BigQuery non semplificano la collaborazione: sarebbe utile poter visualizzare una query pur non essendone il proprietario.
Ci auguriamo di vedere alcune di queste funzionalità nelle versioni future di Data Studio. Detto questo, Data Studio è un prodotto di BI semplice ma potente, utilizzabile per un lungo periodo prima di dover passare un'offerta a pagamento.
Esportazione dei dati
Forse ricorderai che il nostro cliente voleva un modo per esportare i dati del grafico sottostanti in un foglio di calcolo per poter effettuare ulteriori analisi. Quindi abbiamo approfittato ancora una volta delle integrazioni di G Suite con GCP utilizzando il nuovissimo connettore dati di Google Sheets per BigQuery. È molto semplice da usare: basta selezionare il progetto e lo schema dall'UI di Fogli Google, inserire la query (che può essere parametrizzata), eseguirla et voilà!

Fogli Google dispone anche di un pulsante di aggiornamento per gli utenti finali che consente di aggiornare i dati.
È importante rendersi conto che sia nei casi di visualizzazione che di esportazione, se i servizi GCP e G Suite non fossero così ben integrati, avremmo dovuto creare un'API complessa per esporre i dati da BigQuery, gestire l'autenticazione e mantenerla nel caso la query o gli schemi cambiassero. Con questa soluzione, non abbiamo dovuto fare nulla di tutto ciò.
Conclusioni
La maggior parte del nostro lavoro è stata suddivisa in tre aree principali:
- Estrarre i dati dalle API. Di per sé, questo processo non aggiunge valore aziendale e potrebbe essere completamente evitato se G Suite esportasse metadati e log per tutti i servizi direttamente in BigQuery, come fa per Gmail.
- Trasformare i dati per renderli utili dal punto di vista aziendale: è qui che la nostra esperienza di collaborazione con G Suite ha veramente dato il massimo.
- Creare dashboard per rendere i dati trasformati facili da utilizzare e apportare ulteriore valore aziendale.
In particolare, da questo elenco manca l'integrazione dei servizi o l'esecuzione di task DevOps, come nel caso della configurazione dell'infrastruttura di registrazione, la gestione della capacità del database, la replica e il backup nonché l'impostazione di reti e VM. Questo ci ha permesso di fornire una soluzione tempestiva di business intelligence funzionante, creata da un piccolo team di bravi sviluppatori, molto in linea con ciò che pensiamo di GCP: ossia una piattaforma che ci dà la possibilità di concentrarci sul valore aziendale piuttosto che sui server o sulla scrittura di codice di integrazione. Se hai ulteriori domande su come abbiamo realizzato questa soluzione o se vuoi saperne di più su Revevol e le nostre offerte, contattaci a stanislas.marion@revevol.eu