Analisi SQL in BigQuery

BigQuery e’ il data warehouse analitico serverless di Google Cloud: si interroga in SQL (dialetto GoogleSQL) per aggregare grandi volumi, produrre report ed estrarre insight, senza gestire infrastruttura. Non e’ un database OLTP: per scritture transazionali frequenti a bassa latenza si usa Cloud SQL, non BigQuery. Il segnale d’esame tipico e’ “aggregare/analizzare/fare reportistica su dataset molto grandi” -> BigQuery.

Le query si eseguono dalla console, dalla bq CLI o via client, e i risultati possono alimentare direttamente report e dashboard. Per l’analista associate contano concetti concreti: separazione fra storage e compute, costo legato ai byte processati (quindi selezionare solo le colonne necessarie invece di SELECT * e sfruttare il partizionamento), e il fatto che BigQuery ML permette di addestrare modelli restando in SQL con CREATE MODEL, valutarli con ML.EVALUATE e generare predizioni con ML.PREDICT, senza spostare i dati fuori dal warehouse.

Notebook con Colab Enterprise

Quando l’analisi va oltre la singola query — esplorazione iterativa, trasformazioni in Python/pandas, grafici o data science — si usano i notebook Jupyter di Colab Enterprise, integrati con BigQuery e Vertex AI. Sono l’ambiente giusto per analizzare e visualizzare i dati in modo esplorativo: si legge da BigQuery, si elabora in Python e si producono visualizzazioni inline. Rispetto a un notebook locale offrono runtime gestiti, governance IAM e collaborazione. Segnale d’esame: “notebook”, “Python/pandas”, “analisi esplorativa e visualizzazione ad hoc” -> Colab Enterprise, non un tool di dashboard.

Looker vs Looker Studio

Sono due prodotti distinti, spesso confusi apposta nelle domande.

Looker Studio e’ lo strumento self-service, leggero, per costruire rapidamente dashboard e report condivisibili collegando sorgenti diverse. Ottimo per visualizzazioni veloci, prototipi e distribuzione ampia, senza modellazione centralizzata.

Looker (la piattaforma enterprise) si basa invece su un modello semantico governato e riusabile scritto in LookML: metriche e dimensioni sono definite una volta sola, in modo coerente, e riusate da tutti — la “single source of truth”. E’ la scelta quando servono governance, definizioni condivise delle metriche, controllo degli accessi e riuso su scala organizzativa. Su Looker si creano, modificano e condividono dashboard e Look (singole viste salvate) sopra questo modello.

Criterio pratico: dashboard rapida, self-service, costo minimo -> Looker Studio; metriche governate, coerenti e riusabili con un modello centrale -> Looker.

Modificare un data model con LookML

LookML e’ il linguaggio dichiarativo con cui si definisce il modello semantico di Looker. I costrutti base: un view mappa una tabella e ne descrive dimension (attributi, tipicamente colonne) e measure (aggregazioni come sum, count, average); un explore espone le view agli utenti per l’analisi self-service; le relazioni fra view si definiscono con i join. Modificare un data model, a livello associate, significa toccare parametri semplici — cambiare il type o l’sql di una dimension, aggiungere una measure, o rendere un campo disponibile in un explore — cosi’ che il cambiamento si propaghi a tutte le dashboard che ne dipendono. Il vantaggio rispetto a ridefinire la logica in ogni report e’ proprio la centralizzazione: correggi una volta e vale ovunque.

Trappole tipiche d’esame

  • Reportistica analitica su dataset enormi -> soluzione: BigQuery (warehouse serverless), non Cloud SQL, che e’ OLTP relazionale regionale per scritture transazionali.
  • “Notebook / Python / pandas per esplorare e visualizzare” -> soluzione: Colab Enterprise, non Looker o Looker Studio, che servono per dashboard e non per analisi in codice.
  • Metriche governate, coerenti e riusabili in tutta l’azienda -> soluzione: Looker con modello LookML, non Looker Studio (self-service, privo di semantic layer centrale).
  • Dashboard veloce, self-service, da piu’ sorgenti -> soluzione: Looker Studio, non Looker (piu’ orientato alla governance enterprise).
  • Cambiare la definizione di una metrica una volta per tutti i report Looker -> soluzione: modificare la measure/dimension nel view in LookML, non editare ogni singola dashboard.
  • Addestrare un modello ML restando in SQL sui dati del warehouse -> soluzione: BigQuery ML (CREATE MODEL / ML.PREDICT), non esportare i dati verso un altro tool.