Riconoscere i formati dei dati

Distinguere i formati è il primo passo per scegliere strumento e destinazione.

  • CSV: testuale e tabellare, senza schema né tipizzazione forte. Human-readable e universale, ma verboso, fragile sui caratteri speciali e privo di compressione nativa. Utile per scambi semplici.
  • JSON: testuale e semi-strutturato, adatto a dati annidati con schema flessibile. Per il load in BigQuery si usa il newline-delimited JSON.
  • Apache Parquet: binario colonnare e compresso. Ideale per query analitiche perché legge solo le colonne necessarie; formato preferito per data lake e per il caricamento efficiente in BigQuery.
  • Apache Avro: binario row-based con schema embedded, forte su serializzazione, streaming ed evoluzione dello schema. Caricamento parallelizzabile e veloce.
  • Tabelle strutturate: dati con schema fisso, tipico dei database relazionali.

Regola pratica: colonnare (Parquet) per l’analitica, row-based (Avro) per write intensive, streaming e schema evolution.

Strumenti di estrazione e caricamento

  • gcloud storage e bq (CLI): upload di file su Cloud Storage e load batch semplici in BigQuery.
  • BigQuery Data Transfer Service: ingest schedulato e gestito, senza codice, da sorgenti SaaS e da Cloud Storage. La scelta quando serve un caricamento ricorrente e no-code.
  • Dataflow: pipeline Apache Beam serverless, batch e streaming, per trasformazioni ETL/ELT custom.
  • Cloud Data Fusion: ETL/ELT visuale (low/no-code) per orchestrare molte fonti senza scrivere pipeline a mano.
  • Database Migration Service: migrazione di database (es. verso Cloud SQL o Spanner) con downtime minimo.

Ricorda la differenza: ETL trasforma prima del load, ELT carica il raw e trasforma dopo — con BigQuery spesso conviene l’ELT in SQL.

Scegliere lo storage per tipo di dato

  • BigQuery: data warehouse analitico serverless per OLAP e query SQL su grandi volumi. NON è un database transazionale.
  • Cloud Storage: object storage per dati non strutturati (file, immagini, backup, log, landing zone). Le classi Standard/Nearline/Coldline/Archive si scelgono in base alla frequenza di accesso.
  • Cloud SQL: relazionale gestito OLTP (MySQL, PostgreSQL, SQL Server), scala regionale, per transazioni applicative.
  • Bigtable: NoSQL wide-column a bassa latenza e throughput elevatissimo (time-series, IoT, telemetria). Non relazionale.
  • Firestore: NoSQL documentale, ideale per app mobile/web con sincronizzazione in tempo reale.
  • Spanner: relazionale con scala orizzontale e consistenza forte globale, per OLTP mission-critical multi-regione.

Il tipo di location

  • Zonal: risorsa in una singola zona; la perdita della zona ne causa l’indisponibilità (es. un cluster Bigtable risiede in una zona).
  • Regional: replica su più zone della stessa regione, resiliente alla perdita di una zona e con bassa latenza locale.
  • Dual-region: due regioni specifiche, combina prestazioni e ridondanza geografica.
  • Multi-region: area geografica ampia (US, EU, ASIA) per massima disponibilità e durabilità.

Trade-off: più ampia è la location, maggiori sono resilienza e disponibilità, ma possono crescere costo e latenza. Scegli in base a SLA, vicinanza agli utenti e requisiti di data residency.

Trappole tipiche d’esame

  • Dati transazionali applicativi a scala regionale → Cloud SQL: relazionale OLTP gestito; BigQuery è analitico e non è adatto a scritture transazionali frequenti.
  • Migliaia di scritture al secondo, time-series/IoT a bassa latenza → Bigtable: NoSQL wide-column; Firestore (documentale) e Cloud SQL non reggono quel throughput.
  • App con dati documentali e sync realtime per mobile/web → Firestore: non è Bigtable; Firestore è pensato per documenti e client offline-first.
  • Database relazionale globale con consistenza forte e scala orizzontale → Spanner: Cloud SQL resta regionale e non scala orizzontalmente su più regioni come Spanner.
  • File/oggetti non strutturati o landing zone per l’ingest → Cloud Storage: non caricarli come tabelle; la classe si sceglie per frequenza d’accesso, non per tipo di dato.
  • Ingest schedulato e no-code da una sorgente SaaS → BigQuery Data Transfer Service: Dataflow serve solo quando occorre trasformazione custom o streaming Beam.