Google PCA: Storage dei dati, database e architettura di analytics — Guida allo studio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Panoramica

La progettazione dello storage dei dati, dei database e degli analytics su Google Cloud richiede di abbinare i pattern dei carichi di lavoro ai servizi, pianificando al contempo durabilità, disponibilità, controllo degli accessi, costi e resilienza operativa. Questa sezione tratta lo storage a oggetti e la governance del ciclo di vita; i database operativi e le cache; il warehouse per l’analisi e l’elaborazione dei dati; le architetture di ingestion; e le pratiche di governance, protezione e performance. Evidenzia le scelte di progettazione, i ragionamenti operativi e le modalità di guasto o i compromessi più comuni.

Architettura dello Storage e degli Oggetti

Progettazione dei bucket di Cloud Storage

Posizione: scegliere una region per carichi di lavoro a bassa latenza e sensibili ai costi; una dual-region per la continuità operativa con failover prevedibile; una multi-region per l’accesso in lettura a livello globale. La dual-region offre una replica turbo opzionale per un RPO basso supportato da SLA; altrimenti la replica è asincrona.
Namespace e separazione: utilizzare bucket separati per domini di dati, ambienti e livelli di sensibilità. Impiegare l’accesso uniforme a livello di bucket e la prevenzione dell’accesso pubblico per permessi coerenti.
Classi di storage: Standard per dati ad accesso frequente (hot); Nearline per dati ad accesso poco frequente (mensile); Coldline per accesso trimestrale; Archive per la conservazione a lungo termine. Autoclass può ottimizzare automaticamente il posizionamento nelle classi con un lavoro operativo minimo.
Policy del ciclo di vita: automatizzare la transizione e la cancellazione in base all’età, alla classe di storage o al prefisso dell’oggetto. Esempio per eliminare oggetti più vecchi di 90 giorni: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Applicare con: gsutil lifecycle set lifecycle.json gs://my-bucket
Conservazione e blocchi legali (legal hold): configurare le policy di conservazione del bucket e, opzionalmente, bloccarle per impedirne la riduzione (compliance). I blocchi basati su eventi (event-based hold) e il versioning degli oggetti consentono il ripristino da cancellazioni o sovrascritture accidentali.
Replica: scegliere una dual-region per una semantica di coerenza sincrona a livello di API con replica in background tra due region; utilizzare la replica da bucket a bucket (per copie tra progetti o tra località diverse) per soddisfare RPO/RTO specializzati o la separazione dei compiti.

Modalità di guasto e compromessi

La mancata corrispondenza della classe aumenta costi e latenza. Autoclass riduce questo problema ma aggiunge un overhead di gestione per singolo oggetto.
Il blocco della conservazione (retention lock) è irreversibile; testare le policy in ambienti non di produzione.
La replica migliora la durabilità ma può aumentare la latenza di scrittura e i costi; progettare i percorsi di lettura/scrittura per le località target.

Pattern

Data lake: zone per dati grezzi (raw) e curati (curated) su Cloud Storage; governance tramite Dataplex; schemi esternalizzati in Data Catalog.
Archiviazione: classe Archive con blocco della conservazione (retention lock) per la compliance, con tabelle esterne di BigQuery o ripristino on-demand per analisi rare.
Lakehouse: utilizzare BigLake per unificare l’accesso tra Cloud Storage e BigQuery con una sicurezza coerente.

Datastore operativi e Caching

Cloud SQL

Alta disponibilità: HA a livello regionale con replica sincrona su un’istanza di standby; failover automatico tipicamente in pochi secondi o un paio di minuti. L’endpoint dell’istanza rimane lo stesso, minimizzando le modifiche all’applicazione.
Repliche di lettura: all’interno della regione o tra regioni diverse (cross-region), asincrone; ideali per lo scale-out in lettura e il Disaster Recovery (DR). Monitorare il lag; letture di dati non aggiornati (stale reads) possono compromettere la correttezza.
Backup e PITR: backup pianificati più ripristino point-in-time (point-in-time recovery) utilizzando i log delle transazioni (generalmente una finestra fino a 7 giorni, a seconda del motore). Testare regolarmente il ripristino.
Connettività privata: l’IP privato tramite VPC peering riduce l’esposizione e la latenza; pianificare gli intervalli IP per evitare sovrapposizioni.
Migrazione: Database Migration Service supporta spostamenti a basso downtime da ambienti on-premise o altri cloud; per collegamenti ad alto volume, preferire Dedicated o Partner Interconnect rispetto a una VPN per ridurre la perdita di pacchetti e la latenza.

Trade-off e modalità di fallimento

I failover HA reimpostano le connessioni; le applicazioni devono ritentare con un meccanismo di backoff. Le finestre di manutenzione possono degradare brevemente le prestazioni.
Le transazioni a lunga esecuzione aumentano il lag di replica e il tempo di ripristino del PITR.
Lo storage sovradimensionato è un’assicurazione a basso costo; un IOPS sottodimensionato causa fallimenti latenti durante i picchi di carico.

Cloud Spanner

Scalabilità e coerenza globali: letture/scritture a coerenza forte (strongly consistent) tra le regioni utilizzando TrueTime e il commit a due fasi (two-phase commit). Scegliere la configurazione regionale per la latenza di scrittura più bassa; multi-regionale per una maggiore disponibilità e letture globali.
Transazioni: coerenza esterna e pienamente ACID su righe e tabelle; le transazioni di sola lettura scalano attraverso le repliche.
Progettazione dello schema: scegliere chiavi primarie che evitino hotspot; usare tabelle interlacciate (interleaved tables) per la località; considerare l’amplificazione di scrittura e il comportamento di backfill degli indici secondari.
Regionalità: il posizionamento della regione leader determina la latenza di scrittura; la configurazione multi-regionale aggiunge i costi del quorum e la latenza di commit.

Trade-off

La latenza di scrittura cresce con l’impronta geografica; evitare la configurazione multi-regionale a meno che la disponibilità e la distribuzione globale non la giustifichino.
Il costo di base è più alto rispetto ai database su VM a singolo nodo; la pianificazione della capacità deve essere allineata con gli SLO e la crescita.

Firestore, Bigtable, Memorystore e selezione

Firestore: database a documenti per backend mobile/web; coerenza forte per singoli documenti; sicurezza granulare; indicizzazione automatica. Attenzione alla contesa (contention) su documenti aggiornati di frequente; utilizzare contatori distribuiti e scritture batch (batched writes).
Bigtable: wide-column, su scala petabyte, a bassissima latenza per serie temporali e IoT; progettare le chiavi di riga (row keys) per evitare hotspot (es. hashing o salting); scalare tramite nodi e cluster; routing multi-cluster per la disponibilità. La replica è asincrona; la coerenza forte è per-cluster.
Memorystore for Redis: cache in-memory; il livello Basic è una singola istanza (senza HA); il livello Standard fornisce una replica e failover automatico (sono possibili brevi disconnessioni). Trattare come una cache, non come una fonte di verità; le funzionalità di persistenza riducono la volatilità ma non sostituiscono i backup del database.

Selezione basata sul carico di lavoro

Relazionale con join/ACID e scala moderata: Cloud SQL.
Relazionale globale con scalabilità orizzontale e coerenza esterna: Cloud Spanner.
Serie temporali/telemetria ad alto throughput o key-value molto grandi: Bigtable.
Modelli a documenti incentrati sull’applicazione con query gerarchiche: Firestore.
Accelerazione effimera e rate limiting: Memorystore.

Analisi, Ingestione ed Elaborazione

BigQuery

Dataset: confini logici per la sicurezza e la fatturazione; adottare convenzioni di denominazione per dominio e fase del ciclo di vita.
Partizionamento: al momento dell’ingestione (ingestion-time) o basato su colonna per il filtraggio temporale; anche partizionamento per intervallo di interi. Usare il partizionamento per unità di tempo su event_ts per ridurre le scansioni (pruning).
Clustering: fino a quattro colonne per co-locare i dati correlati nello storage; migliora le prestazioni e il costo delle query selettive.
Prenotazioni (Reservations): gestire slot dedicati tramite prenotazioni e assegnazioni; usare flex slot per esperimenti con picchi di carico (bursty); isolare i carichi di lavoro critici per evitare la starvation (carenza di risorse).
Controllo degli accessi: IAM a livello di progetto e dataset; controllo a livello di tabella/colonna con policy a livello di riga e policy tag; condividere dati curati tramite viste e routine autorizzate.

Esempio utile:

undefined

Trade-off e modalità di fallimento

Un partizionamento inadeguato porta a scansioni complete della tabella (full-table scans) e a costi fuori controllo.
Il clustering aiuta solo quando i filtri o i join includono le colonne clusterizzate; riorganizzazioni frequenti possono ridurne il beneficio.
Il sottodimensionamento degli slot mette in coda i job; il sovradimensionamento aumenta i costi. Monitorare l’utilizzo degli slot e lo “spilled shuffle”.

Ingestione ed elaborazione dei dati

Pub/Sub: consegna globale, durevole, “at-least-once”; le chiavi di ordinamento (ordering keys) garantiscono l’ordine per chiave con un trade-off sul throughput. Progettare consumer idempotenti.
Dataflow: elaborazione unificata batch e streaming con autoscaling, elaborazione stateful “exactly-once”, windowing e trigger; lo Streaming Engine esternalizza la gestione dello stato. Usare topic dead-letter e sorgenti riproducibili (replayable).
Dataproc: Spark/Hadoop gestito per codice ed ecosistemi esistenti; cluster effimeri o con autoscaling; da usare per librerie di ML o quando il porting è costoso.

Trade-off tra batch e streaming

Lo streaming riduce la latenza e supporta il tempo reale, ma aumenta la complessità (stato, watermarking, dati in ritardo) e i costi operativi.
Il batch semplifica la correttezza e il controllo dei costi; è accettabile quando gli SLA tollerano un ritardo.
Pattern ibridi: salvare gli eventi grezzi in Cloud Storage, inviare in streaming i KPI aggregati a BigQuery ed eseguire ricalcoli batch notturni per la precisione.

Pattern di Warehouse

Warehouse: BigQuery come sistema di analisi; viste materializzate e query pianificate per servire la BI.
Lakehouse: gestire i dati in Cloud Storage con formati aperti; esporli tramite BigLake a BigQuery con una sicurezza coerente.

Governance, protezione e prestazioni

Governance e sicurezza dei dati

Metadati e lineage: utilizzare Data Catalog per i metadati tecnici e di business; abilitare l’acquisizione del lineage da Dataflow, BigQuery e Dataproc per tracciare le dipendenze.
Qualità: applicare regole con la data quality di Dataplex e orchestrare i controlli in Composer o Dataform; mettere in quarantena i record non validi.
Perimetri di accesso: utilizzare VPC Service Controls attorno a BigQuery e Cloud Storage per ridurre il rischio di esfiltrazione; IAM Conditions per l’accesso context-aware; CMEK per il controllo crittografico; policy tag per restrizioni a livello di colonna.
Conservazione (retention): allineare la retention dei bucket di Cloud Storage, il time travel delle tabelle di BigQuery (configurabile fino a 7 giorni) e la scadenza di dataset/tabelle con i requisiti legali.

Backup, PITR e protezione dalla cancellazione

Convalidare i backup: ripristinare periodicamente i backup di Cloud SQL e Spanner in ambienti isolati ed eseguire checksum e convalide a livello di applicazione.
Bigtable: abilitare il PITR per ripristinare a un timestamp specifico entro il periodo di retention configurato; testare i ripristini a livello di tabella o di cluster.
Spanner: utilizzare i backup per il disaster recovery; sfruttare le stale read entro il periodo di conservazione delle versioni per le query di audit.
Cloud Storage: abilitare il versioning degli oggetti e il blocco della retention del bucket (retention lock) per proteggersi da cancellazioni accidentali; replicare su un progetto separato per l’isolamento da errori operativi.
BigQuery: utilizzare il time travel e gli snapshot delle tabelle; evitare i comandi DROP sui dataset di produzione con approvazioni richieste e protezione dalla cancellazione a livello di dataset.

Prestazioni dei dati e controllo dei costi

Evitare hot key: distribuire le row key di Bigtable (prefissi hash), scegliere chiavi primarie di Spanner che randomizzino le leadership election, eseguire lo sharding dei contatori di Firestore.
Indici: mantenere gli indici SQL e NoSQL necessari; in BigQuery, creare cluster sui filtri comuni; in Cloud SQL, monitorare le query lente ed eseguire regolarmente vacuum/analyze su Postgres.
Pianificazione della capacità: definire una baseline con test di carico; impostare SLO e error budget; monitorare l’utilizzo degli slot di BigQuery, le latenze CPU/read-modify-write di Bigtable, CPU/IOPS di Cloud SQL e il backlog di Pub/Sub.
Controlli dei costi: utilizzare i commitment di slot di BigQuery per carichi di lavoro stabili, Autoclass per Cloud Storage, compattare le tabelle di Bigtable e ottimizzare i filtri di Bloom, far scadere partizioni e dataset obsoleti e implementare budget e avvisi per team.

Scenario pratico

Acme Retail Group necessita di una piattaforma unificata a bassa latenza per l’analisi di clickstream e ordini. Requisiti: KPI in tempo reale entro 10 secondi, analisi storica su cinque anni con SQL, obiettivi di ripristino inferiori a un’ora (sub-hour recovery), residenza dei dati rigorosamente negli Stati Uniti e prevenzione della perdita accidentale di dati.

Acquisire eventi grezzi e implementare un’ingestion durevole

Creare bucket Cloud Storage dual-region us-central1/us-east1 per le zone ‘raw’ (grezza) e ‘curated’ (curata); abilitare Autoclass e il versioning degli oggetti sulla zona raw.
Motivazione: la configurazione dual-region soddisfa i requisiti di durabilità e residenza; il versioning protegge da backfill errati; Autoclass ottimizza automaticamente i costi di storage.

Inviare eventi in streaming in modo affidabile con Pub/Sub e Dataflow

Pubblicare eventi di clickstream e ordini su topic Pub/Sub con ordering key per user_id; implementare una pipeline di streaming Dataflow per convalidare, deduplicare, arricchire e diramare l’output verso BigQuery (KPI ‘hot’) e Cloud Storage (parquet nella zona curata).
Motivazione: Pub/Sub fornisce una consegna globale, durevole e at-least-once; Dataflow offre stato exactly-once e autoscaling; la diramazione (branching) mantiene un pattern lakehouse per la rielaborazione.

Erogare funzionalità in tempo reale con Bigtable e Redis

Scrivere un sottoinsieme di eventi arricchiti su Bigtable con una row key composta da user_id con salting e timestamp (salted user_id#timestamp); utilizzare Memorystore for Redis come cache frontale per le sessioni più recenti.
Motivazione: Bigtable offre scritture a bassa latenza e alto throughput per le serie temporali; il salting evita gli hotspot; Redis riduce la tail latency per la personalizzazione in tempo reale.

Centralizzare e ottimizzare le query in BigQuery

Creare dataset partizionati per event_date e clusterizzati per user_id, channel. Utilizzare viste materializzate per i KPI e compattazioni pianificate per i caricamenti di file di piccole dimensioni; acquistare una prenotazione di slot di base con un piccolo buffer di slot flessibili per i picchi di carico.
Motivazione: il partizionamento e il clustering eliminano le scansioni non necessarie (scan pruning) e riducono i costi; le viste materializzate accelerano le dashboard; le prenotazioni limitano i costi e proteggono i carichi di lavoro critici dall’accodamento.

Gestire l’accesso e prevenire l’esfiltrazione

Applicare IAM a livello di dataset per i gruppi di analisti; utilizzare policy tag per limitare l’accesso alle colonne con PII e viste autorizzate per l’accesso dei fornitori. Applicare VPC Service Controls attorno a BigQuery e Cloud Storage; utilizzare CMEK per i dataset regolamentati.
Motivazione: principio del privilegio minimo (least-privilege) a livello di dataset e di colonna; VPC SC riduce il rischio di esfiltrazione dei dati; CMEK soddisfa i requisiti di controllo crittografico.

Implementare backup, PITR e test di ripristino

Abilitare il PITR di Bigtable per 7–14 giorni; creare backup settimanali di Spanner o Cloud SQL per gli archivi transazionali degli ordini; creare snapshot giornalieri delle tabelle critiche di BigQuery e affidarsi al time travel per gli errori. Eseguire esercitazioni di ripristino trimestrali in un progetto isolato.
Motivazione: opzioni di ripristino stratificate per gestire errori logici e disastri; le esercitazioni regolari convalidano RPO/RTO e i runbook.

Controllare la conservazione (retention) e il ciclo di vita dei dati

Applicare una regola del ciclo di vita (lifecycle rule) per eliminare gli oggetti grezzi dopo 30 giorni e quelli curati dopo cinque anni; bloccare una policy di retention a livello di bucket che soddisfi la conformità. Impostare la scadenza predefinita per dataset/tabelle di BigQuery per i dati transitori.
Motivazione: l’applicazione automatica riduce il rischio operativo; il blocco della retention (retention lock) previene l’indebolimento accidentale o non autorizzato della policy.

Monitorare prestazioni e costi e mitigare gli hotspot

Tracciare l’utilizzo degli slot di BigQuery, i byte scansionati e la concorrenza delle query di BI; monitorare la CPU di Bigtable e la latenza di read-modify-write; impostare avvisi sul backlog di Pub/Sub. Se emergono hotspot su user_id, aumentare l’ampiezza del salt e rieseguire il backfill delle chiavi tramite Dataflow.
Motivazione: la telemetria continua rileva precocemente i colli di bottiglia; modifiche proattive alla strategia delle chiavi preservano gli SLO senza una riprogettazione completa.

Fornire connettività privata e isolamento

Per le dipendenze ibride, utilizzare Partner o Dedicated Interconnect con Cloud Router; assicurare intervalli IP non sovrapposti; utilizzare Private Service Connect per gli endpoint dei servizi gestiti.
Motivazione: i percorsi privati riducono la latenza e la perdita di pacchetti; una chiara pianificazione degli IP e PSC garantiscono isolamento e routing prevedibile.

Operazionalizzare l’affidabilità

Abilitare pipeline Dataflow canary e viste BigQuery blue/green; imporre l’evoluzione dello schema tramite approvazioni in Data Catalog; integrare le code dead-letter con la gestione degli incidenti (incident response).
Motivazione: i rollout controllati limitano il raggio d’impatto (blast radius); le modifiche governate dello schema mantengono la qualità dei dati; le DLQ (Dead-Letter Queue) assicurano che nessun dato venga perso durante gli incidenti.

← Compute · Tutti i domini · Networking →

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