SQL analytics su larga scala con BigQuery

BigQuery è un data warehouse serverless e analitico (OLAP), a storage colonnare e con separazione netta tra storage e compute. Non è un motore transazionale: per carichi OLTP con molte scritture puntuali a bassa latenza si usano Cloud SQL o Spanner, mentre BigQuery brilla su scansioni e aggregazioni di grandi volumi. Supporta standard SQL con window function, tipi nested (ARRAY, STRUCT), UDF e BigQuery ML per creare modelli direttamente in SQL.

Sul modello di prezzo la scelta è dirimente: on-demand (paghi i byte scansionati) conviene per workload sporadici o imprevedibili; le capacity/slot reservation (BigQuery editions con autoscaling) danno costo prevedibile su carichi costanti e intensi. Poiché il formato è colonnare, SELECT * fattura tutte le colonne lette: selezionare solo i campi necessari è la prima leva di risparmio.

Ottimizzare le query: partitioning, clustering, materialized view, BI Engine

Il partitioning (per data, ingestion time o integer range) abilita il partition pruning: se il filtro WHERE usa la colonna di partizione, BigQuery legge solo le partizioni pertinenti riducendo i byte scansionati. Il clustering ordina fisicamente i dati su colonne ad alta cardinalità usate in filtri e aggregazioni, migliorando il block pruning; è complementare al partitioning, non un suo sostituto.

Le materialized view precalcolano e memorizzano risultati di aggregazioni con refresh incrementale automatico; l’optimizer può riscriverle nelle query sulle tabelle base anche senza referenziarle esplicitamente. Il trade-off è tra costo di refresh/storage e risparmio a query time: convengono per aggregazioni ricorrenti su tabelle che cambiano in modo contenuto.

BI Engine è un layer di analisi in-memory basato su reservation che porta le dashboard a latenza sub-secondo su tabelle molto interrogate: è la scelta per accelerare Looker Studio e Looker in modo interattivo. Buone pratiche trasversali: evitare SELECT *, filtrare presto e usare funzioni approssimate (APPROX_*) quando l’esattezza non è richiesta.

Controlli di costo e condivisione sicura

Per governare la spesa, maximum bytes billed fissa un tetto ai byte fatturabili per singola query: se superato, la query fallisce invece di generare costo a sorpresa. Le custom quota limitano invece i query bytes giornalieri per progetto o per utente, ponendo un budget aggregato. Il dry run stima il costo prima dell’esecuzione; table/partition expiration e long-term storage automatico contengono i costi di storage.

Per condividere senza esporre i dati grezzi si usano authorized view (e authorized dataset/routine): gli utenti interrogano risultati derivati o filtrati senza ricevere permessi IAM sulle tabelle sottostanti, pattern ideale per distribuire viste curate tra team e progetti.

Governance dei dati e business intelligence

La column-level security si basa su policy tag definiti in una taxonomy (Data Catalog/Dataplex): limita l’accesso a colonne sensibili senza duplicare tabelle, e gli stessi policy tag abilitano la dynamic data masking. La row-level security, tramite row access policy, filtra invece le righe visibili per utente.

Sul fronte BI, distinguere i due strumenti è centrale: Looker è la piattaforma enterprise con modello semantico LookML, metriche governate e coerenti, embedding e controllo centralizzato; Looker Studio è il tool di dashboarding self-service leggero e gratuito, con connessione diretta a BigQuery e ottimo abbinamento a BI Engine. In sintesi: semantica condivisa e metriche riusabili → Looker; report rapidi e ad hoc → Looker Studio.

Trappole tipiche d’esame

  • Filtro non sulla colonna di partizione → nessun pruning: se il WHERE non usa la partition column (o la avvolge in una funzione non SARGable) BigQuery scansiona tutto; il clustering non compensa un partitioning assente.
  • Serve l’accesso ai risultati ma non alle tabelle base → authorized view: non concedere IAM sulle tabelle sottostanti, usa authorized view/dataset per esporre solo l’output.
  • Tetto di spesa per la singola query → maximum bytes billed, non custom quota: la custom quota limita il totale giornaliero; confondere i due è un distrattore classico.
  • Dashboard sub-secondo su tabella molto interrogata → BI Engine: la materialized view precalcola aggregazioni, ma l’accelerazione interattiva in-memory è BI Engine.
  • Nascondere colonne sensibili senza duplicare i dati → policy tag/column-level security: niente tabelle separate né una vista per ruolo.
  • Metriche di business coerenti e governate tra team → Looker (LookML): Looker Studio è self-service e non offre un semantic layer condiviso.