Google PDE: Architettura e Progettazione dell'Ingegneria dei Dati — Guida allo studio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Fa parte della Google Professional Data Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’architettura e la progettazione del data engineering su Google Cloud bilanciano i confini di dominio, i pattern di elaborazione e le capacità dei servizi per fornire piattaforme dati affidabili, scalabili ed economicamente efficienti. Una progettazione efficace rende lo storage, il calcolo, l’orchestrazione e l’erogazione dei dati scalabili in modo indipendente; codifica i contratti affinché i domini possano interoperare; e convalida i rischi precocemente con obiettivi di livello di servizio (SLO) misurabili. Questa sezione riassume gli stili architetturali canonici (data mesh, data lake, data warehouse, lakehouse, archivi operativi), le modalità di elaborazione (batch, micro-batch, streaming, event-driven, lambda) e i compromessi tra scalabilità, latenza, disponibilità, coerenza e costo. Copre anche il posizionamento regionale e multi-cloud, l’evoluzione degli schemi, il ciclo di vita completo dei dati, la selezione dei servizi in base al carico di lavoro e le pratiche di convalida basate sul rischio, specifiche per Google Cloud.

Paradigmi Architetturali e Pattern di Elaborazione

• Data mesh, domini e prodotti di dati:
  • Responsabilizzare i team di dominio a pubblicare “prodotti di dati” con proprietà, SLO, policy di accesso e documentazione chiari. Utilizzare Dataplex per definire i domini, governare i metadati e applicare policy coerenti su BigQuery e Cloud Storage. I prodotti possono esporre dataset di BigQuery, topic di Pub/Sub o percorsi di Cloud Storage con contratti applicati tramite gli schemi di Pub/Sub e gli schemi delle tabelle di BigQuery.
• Data lake:
  • Archiviazione di dati grezzi in formato aperto (Parquet/Avro) in Cloud Storage con gestione del ciclo di vita e versioning. Adatto a carichi di lavoro eterogenei (Spark su Dataproc, Dataflow, Presto/Trino) e alla portabilità multi-cloud. Compromesso: semantica di “eventual consistency” negli object store; progettare per l’idempotenza e la deduplicazione basata su metadati.
• Data warehouse:
  • Analisi curate e governate in BigQuery. Ottimizzato per SQL ANSI, separazione tra storage e calcolo e sicurezza a grana fine. Compromessi: gli inserimenti in streaming presentano una breve obsolescenza dei dati al momento della query; preferire caricamenti batch o inserimenti con query bufferizzate per SLA di freschezza rigorosi.
• Lakehouse:
  • Unisce l’archiviazione aperta del data lake con le capacità di un data warehouse. Su Google Cloud, archiviare Parquet/Avro in Cloud Storage; utilizzare le tabelle esterne di BigQuery per ragioni economiche e le tabelle gestite di BigQuery per prestazioni e governance. Dataflow o Dataproc mantengono una semantica di unione simile ad ACID con strategie di partizionamento/clustering.
• Architettura con archivi operativi:
  • Archivi transazionali o chiave-valore a bassa latenza a supporto delle applicazioni. Scegliere Cloud SQL per l’OLTP tradizionale, Cloud Spanner per SQL globalmente coerente con scalabilità orizzontale e Bigtable per pattern di accesso a colonne larghe con throughput molto elevato. Separare gli archivi operativi da quelli analitici; utilizzare il CDC (Datastream) per catturare le modifiche e inviarle a Pub/Sub, Cloud Storage o BigQuery.

Pattern di elaborazione e quando utilizzarli:

• Batch: Trasformazioni periodiche su larga scala (es. generazione notturna di feature). Strumenti: Dataflow batch, Dataproc. Modalità di fallimento: timeout di job a lunga esecuzione, skew (asimmetria dei dati); mitigare con l’autoscaling e il ripartizionamento.
• Micro-batch: Batch piccoli e frequenti (es. ogni minuto) per bilanciare freschezza, stabilità e costi. In BigQuery, utilizzare query pianificate o Dataflow con finestre fisse.
• Streaming: Latenza da millisecondi a secondi su dati illimitati (unbounded). Utilizzare Pub/Sub + Dataflow. Gestire eventi in ritardo o fuori sequenza con finestre basate sull’orario dell’evento (event-time) e watermark; garantire l’idempotenza per prevenire duplicati.
• Event-driven: Attivato da cambiamenti (finalizzazione di un oggetto GCS, messaggi Pub/Sub). Utilizzare Cloud Functions o Cloud Run per reazioni stateless e Dataflow per elaborazioni stateful. Compromesso: costi per singolo evento rispetto al throughput.
• Pattern Lambda: Mantenere percorsi sia di streaming che batch per accuratezza e rielaborazione. La complessità raddoppia; considerare una semplificazione simile a Kappa in cui tutto è riproducibile da un log immutabile (archiviazione da Pub/Sub a Cloud Storage).

Breve esempio di configurazione streaming di Dataflow per dati in ritardo:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

Proprietà di Dominio, Prodotti di Dati e Contratti

• Proprietà e SLO:
  • Ogni team di dominio definisce e gestisce i propri prodotti di dati con SLO di disponibilità, latenza e qualità dei dati. Pubblicare gli SLO tramite i cataloghi di Dataplex e monitorarli con gli SLI di Cloud Monitoring (ad es., la completezza delle partizioni nei tempi previsti).
• Contratti e interoperabilità:
  • Imporre gli schemi con Pub/Sub Schema Registry (Avro/Proto) e con gli schemi delle tabelle di BigQuery. Per l’ingestion di CSV, validare in Dataflow e instradare le righe malformate a una tabella per i messaggi non elaborabili per l’analisi. Interoperare con formati aperti in Cloud Storage e con le tabelle esterne di BigQuery quando più motori devono leggere gli stessi dati.
• Evoluzione dello schema:
  • Privilegiare modifiche retrocompatibili: aggiungere colonne che ammettono valori null, aggiungere campi opzionali in Avro/Proto, evitare rinomine/eliminazioni senza finestre di deprecazione. Comunicare le modifiche tramite contratti versionati e piani di deprecazione.
  • Esempio in BigQuery (aggiunta di colonna retrocompatibile):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Impatto sui consumatori:
  • Mantenere il versioning semantico degli schemi; pubblicare sia la v1 che la v2 durante la migrazione. Per lo streaming, instradare verso topic versionati o includere un campo per la versione dello schema. Fornire viste autorizzate in BigQuery per isolare i consumatori dalle modifiche fisiche.
• Governance e lignaggio dei dati:
  • Utilizzare Dataplex e Data Catalog per metadati, tag (ad es., PII) e lignaggio dei dati. Applicare la sicurezza a livello di riga e di colonna in BigQuery. Per la prevenzione della perdita di dati (DLP), integrare Cloud DLP nell’ingestion (ad es., tramite trasformazioni in Cloud Run o Dataflow) per tokenizzare o oscurare i campi sensibili prima dell’archiviazione.

Compromessi non funzionali e topologia di deployment

• Scalabilità:
  • BigQuery scala in modo elastico per l’analisi dei dati; Bigtable scala linearmente con il numero di nodi ma richiede un’attenta progettazione della row-key (ad es. prefissi con hash o a rotazione) per evitare l’hotspotting. L’autoscaling di Dataflow risponde ai backlog; progettare per la contropressione (backpressure) sfruttando il controllo di flusso (flow control) di Pub/Sub.
• Latenza:
  • Lo streaming su BigQuery offre inserimenti a bassa latenza, ma le query possono presentare un leggero ritardo; progettare le query con un buffer di aggiornamento (freshness buffer) o finestre basate su watermark. Per letture su larga scala sotto i 100 ms, pre-calcolare e servire i dati da Bigtable o Memorystore.
• Disponibilità e consistenza:
  • Cloud Spanner fornisce SQL distribuito a livello globale con consistenza forte (strong consistency). Bigtable offre alta disponibilità con consistenza finale (eventual consistency) tra i cluster. La disponibilità di BigQuery è a livello regionale o multi-regionale; materializzare i set di dati critici in una configurazione multi-regionale per la resilienza.
• Costo:
  • Ottimizzare BigQuery con partizionamento e clustering per ridurre i byte scansionati. Per file di piccole dimensioni su connessioni di rete limitate, raggruppare in batch o aggregare (bundle) per ridurre l’overhead delle RPC. Utilizzare BigQuery BI Engine per dashboard interattive e memorizzate nella cache, dove appropriato.
• Regionale, multi-regionale, ibrido e multi-cloud:
  • Una progettazione regionale riduce la latenza e i costi; lo storage multi-regionale (ad es. BigQuery multi-region US/EU, Cloud Storage dual-/multi-region) aumenta la durabilità e le opzioni di località. Per il DR (Disaster Recovery), definire RPO/RTO e replicare i set di dati critici. In scenari ibridi, utilizzare Datastream per il CDC (Change Data Capture) e Transfer Appliances o Storage Transfer Service per la migrazione di massa (bulk). Per il multi-cloud, standardizzare su formati aperti in Cloud Storage e utilizzare capacità di calcolo portabile (Apache Beam/Dataflow, Spark on Dataproc) pur tenendo conto dell’overhead operativo e dei costi di egress.

Stratificazione, ciclo di vita e selezione dei servizi

• Separazione dei livelli (layer):
  • Storage: Cloud Storage per dati grezzi/bronze e archiviazione; BigQuery per l’analisi dei dati curati/serviti; Bigtable per l’accesso a chiavi a bassa latenza; Spanner/Cloud SQL per OLTP.
  • Compute: Dataflow per elaborazione serverless in streaming/batch; Dataproc per ecosistemi Spark/Hadoop; BigQuery per ELT in-warehouse; Cloud Run/Functions per microservizi basati su eventi.
  • Orchestrazione: Cloud Composer (Airflow) o Workflows per DAG e coreografia di API; Scheduler per trigger di tipo cron.
  • Serving: Bigtable o Spanner per letture online; BigQuery per la BI; Looker/BI Engine per le dashboard; Memorystore per il caching.
• Ciclo di vita dei dati:
  • Ingestione (Ingest): Pub/Sub per gli stream; Storage Transfer o gsutil per i file; Data Transfer Service per i SaaS. Convalidare, deduplicare e depositare i dati grezzi immutabili in Cloud Storage con il versioning degli oggetti.
  • Elaborazione (Process): Usare Dataflow o BigQuery per trasformare i dati da grezzi (raw) a silver (puliti, conformati), e poi a gold (data mart pronti per il business).
  • Servizio (Serve): Pubblicare viste/tabelle BigQuery per l’analisi; pre-calcolare feature o previsioni su Bigtable per le API.
  • Conservazione e archiviazione (Retain and archive): Applicare le regole del ciclo di vita di Cloud Storage per la transizione ai livelli Coldline/Archive; usare il partizionamento temporale di BigQuery con scadenza delle partizioni per la retention. Abilitare CMEK dove richiesto e VPC Service Controls per la protezione dall’esfiltrazione dei dati.
• Selezione dei servizi in base alle caratteristiche del carico di lavoro:
  • Serie temporali ad alto throughput con righe larghe e bassa latenza: Bigtable.
  • OLTP globale a consistenza forte (strongly consistent) con SQL ANSI: Cloud Spanner.
  • Transazioni relazionali tradizionali su scala modesta: Cloud SQL.
  • Analisi su scala petabyte con SQL ANSI e separazione tra storage e compute: BigQuery.
  • Ingestione ed elaborazione in tempo reale: Pub/Sub + Dataflow.
  • Batch Spark/Hadoop o strumenti specifici per librerie: Dataproc.

Breve esempio di partizionamento in BigQuery:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

Scenario pratico

Contoso Mobility gestisce una flotta globale di monopattini elettrici e necessita di ingestione, elaborazione, archiviazione e analisi in tempo reale per la telemetria delle corse e la fatturazione. Deve supportare milioni di eventi al minuto, regole antifrode con esecuzione sotto il secondo, dashboard aggiornate, controlli sulla privacy e operazioni resilienti multi-regione.

Approccio:

1. Stabilire l’ingestione degli eventi con Cloud Pub/Sub.

• Motivazione: Pub/Sub fornisce un singolo endpoint globale, buffering durevole e scalabilità orizzontale per il traffico discontinuo (bursty) dei dispositivi. Utilizzare chiavi ordinate per ogni monopattino per preservare l’ordine degli eventi all’interno del singolo dispositivo per finestre di 1 ora.

2. Implementare l’elaborazione in streaming con Cloud Dataflow (Apache Beam).

• Motivazione: L’autoscaling di Dataflow gestisce i picchi di traffico e offre sink con semantica exactly-once se combinato con chiavi idempotenti. Utilizzare finestre basate sull’event-time e watermark per gestire la telemetria in ritardo o fuori ordine. Emettere un output principale verso stream curati e un output secondario per i record non elaborabili (dead-letter).
• Configurazione:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. Persistere i dati grezzi e curati rispettivamente in Cloud Storage e BigQuery.

• Motivazione: Depositare i file Avro grezzi (bronze) in un bucket Cloud Storage dual-region per il replay e l’audit. Scrivere gli stream curati (silver) in tabelle partizionate di BigQuery per l’analisi, con clustering su scooter_id per ricerche puntuali efficienti. Applicare un piccolo buffer di aggiornamento (freshness buffer) sulle query delle dashboard per evitare dati transitoriamente non aggiornati (stale) dallo streaming.

4. Servire le ricerche operative e i controlli antifrode da Cloud Bigtable.

• Motivazione: La valutazione delle regole in meno di 100 ms richiede un accesso casuale a bassa latenza. Pre-calcolare gli aggregati (es. corse per dispositivo per finestra di 5 minuti) in Dataflow e scriverli su Bigtable usando una row key con prefisso hash (es. h(prefisso)+device_id+inizio_finestra) per evitare l’hotspotting e parallelizzare le letture tra i tablet.

5. Gestire la fatturazione transazionale in Cloud Spanner.

• Motivazione: La fatturazione richiede SQL globalmente consistente, consistenza forte (strong consistency) e alta disponibilità. Utilizzare un’istanza leader nella regione geografica primaria con repliche di sola lettura nelle regioni secondarie per ridurre le latenze di lettura per i portali dei clienti.

6. Applicare la governance con Dataplex, Data Catalog e Cloud DLP.

• Motivazione: Classificare i campi PII, etichettare i set di dati e applicare la sicurezza a livello di colonna in BigQuery. Integrare Cloud DLP nella pipeline di Dataflow per tokenizzare gli attributi sensibili prima dell’archiviazione. I domini di Dataplex riflettono la proprietà organizzativa; ogni dominio pubblica data product documentati con SLO.

7. Orchestrazione e operatività con Cloud Composer e Cloud Monitoring.

• Motivazione: Composer coordina i backfill batch, le compattazioni e la materializzazione delle feature di ML. Monitoring osserva gli SLI end-to-end: backlog di Pub/Sub, ritardo del watermark di Dataflow, completezza delle partizioni di BigQuery e latenze di coda (tail latencies) di Bigtable. Generare alert in caso di violazione degli SLO; eseguire l’autoscaling di Dataflow in base alla crescita del backlog.

8. Ottimizzare i costi e il ciclo di vita con partizionamento e tiering.

• Motivazione: Le tabelle BigQuery sono partizionate per event_ts con una retention di 90 giorni e clusterizzate per scooter_id. Cloud Storage utilizza regole del ciclo di vita per trasferire i dati grezzi a Coldline dopo 30 giorni e ad Archive dopo 180 giorni. Job pianificati di BigQuery compattano i piccoli file dei micro-batch in oggetti Parquet più grandi per ridurre l’overhead del numero di file per i job Spark a valle.

9. Convalidare rischi e resilienza.

• Motivazione: Eseguire test di carico al doppio del picco previsto per convalidare le quote di Pub/Sub e l’autoscaling di Dataflow. Eseguire un’esercitazione di failover regionale: i set di dati multi-regione di BigQuery e i bucket dual-region mantengono la disponibilità; l’istanza multi-regione di Spanner mantiene un RPO=0 e l’RTO configurato tramite failover automatico. Utilizzare Infrastructure as Code (Terraform) con convalida delle policy per imporre l’uso di CMEK e VPC Service Controls.

Questa architettura separa nettamente le responsabilità (separation of concerns): Pub/Sub gestisce il buffering dell’ingestione, Dataflow esegue i calcoli, Cloud Storage e BigQuery archiviano e servono i dati per l’analisi, Bigtable accelera le letture operative e Spanner garantisce transazioni consistenti. Bilancia scalabilità e latenza controllando i costi tramite partizionamento, clustering, policy del ciclo di vita e autoscaling, e integra governance e affidabilità attraverso data product documentati, contratti e convalida continua.

Tutti i domini · Archiviazione dei Dati →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →