Dai requisiti alla scelta tra batch e streaming

Ogni design parte dalla traduzione dei requisiti di business in vincoli tecnici: latenza tollerata, throughput, freshness dei dati, costo e affidabilità. Se il consumo accetta ritardi (report giornalieri, riconciliazioni, training di modelli), il batch è quasi sempre più economico e più facile da rendere idempotente. Se servono decisioni in tempo quasi reale (fraud detection, monitoring, personalizzazione), si passa allo streaming, accettando maggiore complessità operativa.

In Google Cloud lo streaming tipico usa Pub/Sub come ingestion buffer disaccoppiato, seguito da Dataflow per la trasformazione. Dataflow (Apache Beam) è serverless e adotta lo stesso modello di programmazione per batch e streaming, quindi permette di unificare le due pipeline. Attenzione alla semantica di consegna: Pub/Sub è at-least-once di default, perciò la pipeline deve gestire i duplicati (dedup su una chiave, oppure exactly-once dove supportato). Nello streaming contano anche windowing, watermark e late data: sono i concetti con cui l’esame distingue chi conosce Beam da chi no.

Selezione di storage e motore di processing

La scelta dello storage segue l’access pattern, non le preferenze:

  • Analytics su grandi volumi con SQL → BigQuery, il data warehouse analitico (colonnare, MPP). Non è un database OLTP: evita update/delete riga per riga ad alta frequenza.
  • Letture/scritture a bassa latenza e altissimo throughput su chiavi (time series, IoT, profili) → Bigtable, NoSQL wide-column. Richiede row key design attento per evitare hotspotting; niente join SQL.
  • File grezzi, landing zone, backup, formati aperti (Parquet, Avro) → Cloud Storage, base del data lake.
  • Dati relazionali transazionali → Cloud SQL o Spanner (scala orizzontale globale).

Per il processing: Dataflow per pipeline serverless batch+streaming; Dataproc per lift-and-shift di workload Spark/Hadoop esistenti, idealmente con cluster effimeri che leggono e scrivono su Cloud Storage per separare compute e storage. Per orchestrare più step usa Cloud Composer (Apache Airflow gestito). Per l’ML direttamente sul warehouse, BigQuery ML addestra modelli con SQL, evitando l’estrazione dei dati.

Data lake, warehouse e lakehouse: BigQuery, BigLake, Dataplex

Il data lake (Cloud Storage) è economico e flessibile ma privo di schema forte; il data warehouse (BigQuery) offre performance e governance ma richiede ingestion strutturata. Il lakehouse combina i due: BigLake consente di interrogare dati su Cloud Storage in formati aperti come tabelle governate, con security a livello di colonna e riga, senza duplicarli nel warehouse. Dataplex aggiunge la governance trasversale: catalogazione, gestione della data quality, organizzazione logica in lake e zone, e data mesh su dati distribuiti tra lake e warehouse. Quando la domanda parla di “governance unificata su dati sparsi” la risposta è Dataplex; quando parla di “query su file in Cloud Storage senza spostarli” è BigLake.

In BigQuery il controllo dei costi passa dal partitioning (riduce i dati scansionati filtrando per data o intervallo) e dal clustering (ordina i dati per accelerare filtri e aggregazioni su colonne ad alta cardinalità). Sono leve di costo/performance, non indici transazionali.

Data modeling, schema design e migrazione

Nel warehouse spesso conviene la denormalizzazione con campi nested e repeated invece di molti join, sfruttando il modello colonnare. In Bigtable il modello è guidato dalla query: la row key determina la distribuzione e va progettata per evitare hotspot (ad esempio evitando chiavi monotone crescenti). Per la migrazione si ragiona per fasi: assessment, scelta tra lift-and-shift (Hadoop/Spark → Dataproc) e re-architecting (verso BigQuery/Dataflow), trasferimento dei dati (Storage Transfer Service, o Transfer Appliance per volumi enormi) e convivenza durante il cutover. Il trade-off è tra velocità di migrazione (lift-and-shift) e beneficio a lungo termine dei servizi serverless gestiti.

Trappole tipiche d’esame

  • Update/delete frequenti su singole righe → NON BigQuery: BigQuery è analitico, non OLTP; per scritture transazionali usa Cloud SQL o Spanner.
  • Bassa latenza a chiave con enormi volumi → Bigtable, non BigQuery: progetta la row key per evitare hotspotting e ricorda che non esistono join SQL.
  • Ridurre i costi delle query → partitioning + clustering: il partitioning taglia i dati scansionati, il clustering ordina; non confonderli con indici da OLTP.
  • Duplicati nello stream → Pub/Sub è at-least-once: costruisci pipeline idempotenti o con dedup; non dare per scontato l’exactly-once di default.
  • Query su file in Cloud Storage senza ingestion → BigLake: per la governance unificata su dati distribuiti la risposta è invece Dataplex.
  • Workload Spark/Hadoop da migrare in fretta → Dataproc: lift-and-shift con cluster effimeri su Cloud Storage; scegli Dataflow solo se vuoi ri-progettare in serverless Beam.