BigQuery come data warehouse analitico

BigQuery e’ un data warehouse serverless orientato all’analisi OLAP su grandi volumi, non un database OLTP: la sua unita’ logica e’ il dataset (contenitore con una location geografica) che raccoglie tabelle e view. Lo storage e’ columnar e separato dal compute, per cui i costi di storage e di query si misurano e si ottimizzano in modo indipendente. Aspettati query analitiche che scandiscono milioni di righe con aggregazioni e join; per lookup a bassa latenza per singola chiave, aggiornamenti puntuali ad alta frequenza o carichi transazionali la risposta d’esame non e’ BigQuery ma Bigtable o Cloud SQL/Spanner. Poiche’ il modello on-demand fattura i byte scansionati, la regola d’oro dell’ottimizzazione e’ leggere meno dati: da qui nascono partitioning e clustering.

Partitioning e clustering

Il partitioning divide fisicamente la tabella in segmenti e permette di potare (partition pruning) le partizioni non rilevanti: la query legge solo cio’ che serve. Le tre modalita’ sono partition per time-unit column (una colonna DATE/TIMESTAMP, es. la data evento), per ingestion time (pseudo-colonna del momento di caricamento) e per integer range. Scegli la colonna piu’ usata nei filtri temporali; puoi impostare require_partition_filter per obbligare chi interroga a filtrare, evitando full scan accidentali.

Il clustering ordina i dati all’interno delle partizioni (o dell’intera tabella) in base a fino a quattro colonne, secondo l’ordine dichiarato: migliora filtri di uguaglianza/range e aggregazioni sulle colonne cluster, e riduce i byte letti tramite block pruning. Partitioning e clustering sono complementari: si partiziona sulla dimensione temporale a bassa cardinalita’ e si clusterizza sulle colonne ad alta cardinalita’ interrogate spesso (customer_id, region). Attenzione: sul modello on-demand il partition pruning riduce il costo in modo prevedibile, mentre il beneficio del clustering sui byte fatturati e’ stimato e non garantito a priori.

External table, BigLake e ingestion

Le external table permettono di interrogare dati che restano fuori da BigQuery (Cloud Storage, Bigtable, Google Sheets) senza caricarli: utili per dati esplorativi o poco interrogati, ma con performance inferiori e senza le ottimizzazioni dello storage nativo. BigLake estende le external table con governance e sicurezza fine-grained (row/column-level security, permessi coerenti) su dati in Cloud Storage e su formati open (Parquet, ORC, Iceberg), tramite connessioni gestite: e’ la scelta quando vuoi un lakehouse governato senza duplicare i dati nel warehouse.

Per l’ingestion: i batch load sono gratuiti (paghi solo lo storage risultante), mentre gli streaming insert rendono i dati disponibili in near-real-time ma sono a pagamento. Il time travel consente di interrogare o ripristinare lo stato della tabella fino a un massimo di 7 giorni indietro, utile per recuperare cancellazioni accidentali.

Modelli di prezzo e ottimizzazione

Lo storage ha due tariffe: active (tabella o partizione modificata di recente) e long-term, applicata automaticamente e a costo ridotto quando dati/partizione non vengono modificati per 90 giorni consecutivi (la lettura non azzera il timer). Il compute ha due modelli: on-demand (paghi i byte scansionati, semplice ma imprevedibile) e capacita’ basata su slot tramite reservation/BigQuery editions (Standard/Enterprise/Enterprise Plus), con commitment o autoscaling per carichi costanti e budget prevedibile. Best practice: evita SELECT * (leggi solo le colonne necessarie, dato il columnar), sfrutta partition pruning e clustering, materializza risultati ricorrenti, e usa BigQuery ML per addestrare modelli con SQL senza spostare i dati.

Trappole tipiche d’esame

  • Serve lookup per singola chiave a bassa latenza / alta frequenza di scrittura → non BigQuery: e’ analitico OLAP, usa Bigtable (row key design) o Cloud SQL/Spanner per l’OLTP.
  • Costo query fuori controllo con filtri per data → partitioning + require_partition_filter: il partition pruning taglia i byte scansionati; il flag impedisce full scan accidentali.
  • Filtri e aggregazioni su colonne ad alta cardinalita’ → clustering, non un’altra partizione: puoi partizionare su una sola colonna; il clustering ordina fino a 4 colonne dentro le partizioni.
  • Carico costante e budget prevedibile → slot/reservation (editions), non on-demand: on-demand fattura i byte ed e’ imprevedibile; i commitment fissano la spesa compute.
  • Dati in Cloud Storage con security a livello di riga/colonna → BigLake, non external table semplice: BigLake aggiunge governance fine-grained sui file open-format senza duplicarli.
  • Storage costoso su dati storici → long-term storage automatico: dopo 90 giorni senza modifiche la partizione passa a tariffa ridotta; leggere i dati non resetta il conteggio.