Google PDE: Ingestione, Integrazione e Migrazione 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’acquisizione, l’integrazione e la migrazione dei dati in Google Cloud comprendono pattern ripetibili, servizi gestiti e controlli operativi che trasformano sistemi di origine eterogenei in set di dati affidabili e interrogabili. Le progettazioni efficaci separano il trasporto dalla trasformazione, disaccoppiano producer e consumer e favoriscono pipeline idempotenti e con checkpoint, dotate di lineage e verifica chiari. Questa sezione tratta i pattern di acquisizione, i servizi Google Cloud per lo spostamento e il CDC, i controlli sullo schema e sulla qualità dei dati, la connettività e l’integrazione ibrida, e le strategie di cutover, evidenziando per ciascun argomento i compromessi di progettazione (trade-off) e le modalità di fallimento.

Pattern di Acquisizione e Workload

• Acquisizione batch: Pull periodici o rilascio di file a intervalli definiti. Ideale per costi prevedibili e backfill. Modalità di fallimento: batch di grandi dimensioni e poco frequenti causano picchi di risorse, lunghe finestre di recupero e mancato rispetto degli SLA. Mitigazione: dimensionare correttamente le finestre batch, partizionare (shard) per tempo o chiave e utilizzare il parallelismo.
• Caricamento massivo (bulk): Caricamenti una tantum o su larga scala (es. backfill storico iniziale). Preferire formati colonnari o autodescrittivi (Parquet, Avro) e caricare direttamente nello storage analitico (BigQuery) o in una fase di staging su Cloud Storage. Compromesso (trade-off): l’interrogazione di tabelle esterne evita le fasi di caricamento ma sposta i costi sulla scansione al momento della query.
• Caricamento incrementale: Caricamenti delta periodici tramite timestamp o “high-water mark”. Richiede una deduplicazione robusta e operazioni di upsert idempotenti. Modalità di fallimento: disallineamento degli orologi (clock skew) o record che arrivano in ritardo. Utilizzare timestamp di commit lato server e watermarking.
• Change Data Capture (CDC): Replica continua di inserimenti, aggiornament

Schema, convalida e qualità dei dati al perimetro

• Mappatura dello schema e conversione dei tipi: standardizzare precocemente su schemi a tipizzazione forte. Avro o Parquet preservano lo schema e si evolvono in modo pulito. In BigQuery, preferire tabelle partizionate e clusterizzate per ridurre i costi di scansione. Esempio: creare una tabella partizionata per l’analisi giornaliera CREATE TABLE dataset.tracking_table ( event_ts TIMESTAMP, device_id STRING, payload STRING ) PARTITION BY DATE(event_ts) CLUSTER BY device_id;
• Gestione dei record malformati: instradare gli scarti verso una coda di messaggi non recapitabili (dead-letter queue) (Pub/Sub) o un bucket di quarantena in Cloud Storage. Utilizzare output secondari (side output) in Dataflow o collettori di errori in Data Fusion. Registrare gli errori di parsing con payload di esempio e versioni dello schema per il triage.
• Convalida: eseguire controlli al perimetro prima della persistenza:
  • Strutturale: conformità dello schema, campi obbligatori, tipi di dati, domini enum.
  • Referenziale: esistenza di chiavi esterne (foreign key) tramite lookup su dimensioni memorizzate in cache.
  • Ragionevolezza: intervalli per timestamp, geofence, importi non negativi.
  • Unicità: collisioni di chiavi primarie o composite.
• Caricamento idempotente: utilizzare chiavi deterministiche e operazioni di upsert. In BigQuery, implementare MERGE con una chiave di modifica naturale o surrogata. Esempio: MERGE dataset.orders T USING dataset.orders_stage S ON T.order_id = S.order_id WHEN MATCHED THEN UPDATE SET amount = S.amount, status = S.status WHEN NOT MATCHED THEN INSERT (order_id, amount, status) VALUES (S.order_id, S.amount, S.status);
• Watermark e dati in ritardo: nelle pipeline di streaming, configurare i watermark basati sull’event-time e il ritardo consentito (allowed lateness) per bilanciare completezza e latenza. I dati in ritardo vengono instradati verso percorsi correttivi o attivano dei backfill.
• Riconciliazione: tracciare il conteggio delle righe e i checksum per partizione/finestra dalla sorgente alla destinazione (sink). Acquisire le posizioni dei log CDC (LSN/SCN) e i timestamp di commit; memorizzarli in una tabella di controllo per dimostrare la continuità e identificare le lacune.

Connettività, affidabilità e operazioni

• Connettività di rete e accesso privato:

  • Ibrido: utilizzare Cloud VPN o Dedicated/Partner Interconnect per la connettività privata. Abilitare Private Google Access o Private Service Connect per l’accesso privato alle API di Google come Cloud Storage.
  • Sicurezza: utilizzare i service account per l’identità dei workload, IAM con il principio del privilegio minimo (least-privilege), VPC Service Controls per la prevenzione dell’esfiltrazione dei dati e CMEK dove richiesto.
  • Throughput: scalare il parallelismo lato client, ma in ultima analisi è la larghezza di banda a determinare il throughput. Per trasferimenti massivi, preferire Transfer Appliance per il caricamento iniziale (bulk), poi STS o CDC per gli aggiornamenti incrementali.

• Checkpoint e backpressure: Dataflow gestisce i checkpoint e l’autoscaling; progettare destinazioni (sink) in grado di assorbire picchi di carico (buffer su Cloud Storage, scritture batch su BigQuery). Per Pub/Sub, ottimizzare il controllo di flusso (flow control) e le deadline di ack per prevenire tempeste di riconsegna dei messaggi.

• Ordinamento e coerenza con CDC:

  • Datastream preserva l’ordine intra-transazionale ed emette metadati di commit; i consumer ricostruiscono l’ordine per chiave utilizzando i timestamp di commit. Aspettarsi una semantica at-least-once; implementare l’idempotenza.
  • DMS garantisce la coerenza del database durante lo snapshot e il cutover della replica utilizzando i log nativi. Utilizzare repliche di lettura (read replica) o strategie di doppia scrittura (dual-write) per un cutover graduale.

• Strategia dei file per l’analytics: per l’accesso da parte di più motori (multi-engine) a grandi volumi di dati, archiviare i dati canonici in Cloud Storage e, dove economicamente vantaggioso, esporre tabelle esterne permanenti per query ad hoc. Per l’analytics di produzione, caricare i dati in tabelle BigQuery partizionate per minimizzare i costi di scansione per query.

• Ottimizzazione per file di piccole dimensioni: raggruppare i file piccoli (es. ~1.000 per archivio tar) prima del trasferimento, quindi espanderli nel cloud. Utilizzare gsutil in parallelo e regole di ciclo di vita (lifecycle rule) per spostare su livelli di archiviazione inferiori (tiering) e far scadere gli artefatti di staging.

• Problematiche operative e mitigazioni:

  • Schema drift da SaaS: abilitare l’evoluzione dello schema in Data Fusion e imporre la compatibilità. Generare alert in caso di modifiche che causano rotture (breaking change).
  • Fuso orario e codifica: normalizzare in UTC e UTF-8 in fase di ingresso (ingress).
  • Lacune nel CDC: monitorare la conservazione (retention) dei log della sorgente; generare alert quando il ritardo della replica (replica lag) si avvicina ai limiti di conservazione.
  • Quote: insert in streaming di BigQuery, limiti di velocità (rate limit) delle API; raggruppare in batch quando ci si avvicina ai limiti.

Cutover, Backfill e Verifica

• Pianificazione del cutover:
  • Big bang: blocco breve, passaggio unico. Complessità operativa minima; rischio massimo in caso di rollback.
  • Graduale o blue/green: esecuzione duale con scritture replicate (mirrored writes), spostamento progressivo del traffico e letture ombra (shadow reads). Costo più elevato; rollback più sicuro.
• Backfill:
  • Eseguire un caricamento massivo iniziale (Transfer Appliance o STS) utilizzando Avro/Parquet per preservare lo schema. Partizionare e clusterizzare durante il caricamento per evitare rilavorazioni.
  • Avviare il CDC da una posizione di log nota in concomitanza con lo snapshot per catturare i delta durante il trasferimento massivo. Riconciliare a un watermark comune prima di aprire all’ambiente di produzione.
• Rollback:
  • Mantenere il sistema legacy in sola lettura durante la verifica. Per scenari di doppia scrittura (dual-write), proteggere le scritture con un feature flag per un ripristino rapido. Mantenere un checkpoint coerente per rieseguire (replay) o annullare (unwind) le modifiche del CDC, se necessario.
• Verifica della migrazione:
  • Strutturale: corrispondenza del conteggio delle righe e dei checksum per partizione; equivalenza di schema e vincoli.
  • Temporale: assenza di gap dal confine dello snapshot al cutover; continuità delle posizioni del CDC.
  • Parità di business: confrontare aggregati e KPI su finestre temporali; eseguire query di accettazione.
  • Prestazioni: convalidare il throughput di ingestione, la latenza delle query e i costi rispetto ai budget.

Scenario Pratico

Northstar Retail deve consolidare un mix globale di sistemi transazionali on-premise Oracle e MySQL, eventi da CRM SaaS e file CSV giornalieri in Google Cloud per alimentare analytics e machine learning quasi in tempo reale. Deve inoltre migrare un cluster Hadoop legacy senza sostenere costi elevati per lo storage a blocchi e realizzare un cutover con downtime nullo o minimo.

1. Stabilire una connettività ibrida sicura

• Utilizzare Partner Interconnect per la larghezza di banda primaria e Cloud VPN come fallback. Abilitare Private Google Access per consentire ai carichi di lavoro on-premise di accedere privatamente a Cloud Storage e Pub/Sub. Motivazione: I percorsi privati minimizzano l’esposizione del traffico in uscita (egress) e la latenza, e Private Google Access evita la necessità di IP pubblici rispettando le policy di sicurezza.

2. Caricare i dati storici in modo efficiente

• Per 800 TB di dati storici su HDFS, copiarli su Cloud Storage utilizzando Transfer Appliance (caricamento massivo iniziale). Dopo il caricamento iniziale, eseguire Storage Transfer Service giornalmente dall’export NFS on-premise per acquisire le modifiche fino al cutover. Motivazione: Transfer Appliance evita una saturazione prolungata della rete; STS fornisce una sincronizzazione incrementale pianificata e con checksum. L’archiviazione in Cloud Storage con il GCS connector consente l’elaborazione con Dataproc senza la necessità di 50 TB di Persistent Disk per nodo.

3. Migrare i database operativi con CDC

• Utilizzare DMS per migrare MySQL e PostgreSQL con downtime minimo. Per il CDC da Oracle verso l’ambiente di analytics, utilizzare Datastream per il landing su Cloud Storage, quindi un template Dataflow fornito da Google per caricare i dati in BigQuery. Motivazione: DMS sfrutta la replica nativa per uno snapshot affidabile e una sincronizzazione continua; Datastream fornisce un CDC serverless con metadati di commit, mentre il template Dataflow garantisce scritture ordinate e idempotenti su BigQuery.

4. Ingerire feed SaaS e basati su file

• Costruire pipeline Cloud Data Fusion utilizzando connettori SaaS per gli eventi CRM con token incrementali, e una pipeline di file per ingerire i CSV giornalieri da un SFTP di un fornitore tramite STS. Normalizzare in formato Avro in un bucket Cloud Storage curato, quindi caricare tabelle BigQuery partizionate. Motivazione: Data Fusion centralizza connettori, trasformazione e lineage. La standardizzazione su Avro preserva lo schema e facilita l’evoluzione; le tabelle BigQuery partizionate riducono i costi delle query.

5. Elaborare eventi in tempo reale (streaming)

• Pubblicare eventi web e dai punti vendita su Pub/Sub. Elaborarli con Dataflow per parsing, validazione, arricchimento e watermarking; scrivere su BigQuery tramite la Storage Write API e archiviare i dati grezzi in formato Avro su Cloud Storage. Motivazione: Pub/Sub disaccoppia producer e consumer; Dataflow offre autoscaling, elaborazione stateful, checkpoint e gestione dei dati in ritardo (late data); la doppia scrittura (dual-write) garantisce sia analytics a bassa latenza sia una conservazione durevole dei dati grezzi.

6. Applicare controlli di qualità dei dati e dello schema all’ingresso

• Implementare uno schema registry e la validazione in Dataflow/Data Fusion. Indirizzare i record malformati a un bucket di quarantena su GCS e a un topic dead-letter di Pub/Sub. Applicare controlli di dominio (es. codici valuta, timestamp UTC) e deduplicare utilizzando chiavi composite. Motivazione: Il rifiuto e la quarantena precoci impediscono la propagazione di dati errati; l’idempotenza e la deduplicazione proteggono dalla semantica di consegna at-least-once delle sorgenti CDC e di streaming.

7. Ottimizzare lo storage e l’accesso per l’analytics

• Caricare i dataset curati in tabelle BigQuery partizionate e clusterizzate. Esporre gli archivi grezzi come tabelle esterne permanenti per esplorazioni a bassa frequenza. Per i carichi di lavoro OLTP che rimangono transazionali, mantenere Cloud SQL con repliche di lettura (read replicas). Motivazione: Il partizionamento e la clusterizzazione minimizzano i costi di scansione; le tabelle esterne evitano caricamenti non necessari per accessi occasionali; Cloud SQL preserva la semantica ACID per le applicazioni transazionali.

8. Pianificare cutover, backfill e rollback

• Eseguire snapshot + CDC per ogni RDBMS; raggiungere un punto di riconciliazione in cui il conteggio delle righe e i checksum corrispondono. Eseguire in modalità blue/green con doppie scritture (dual-writes) per 48 ore, spostando gradualmente le letture su BigQuery. Mantenere un feature flag per annullare le scritture in caso di rilevamento di discrepanze. Motivazione: La modalità blue/green riduce il rischio; la verifica a un watermark noto garantisce la completezza; i flag consentono un rollback rapido.

9. Verifica e osservabilità

• Costruire tabelle di controllo che acquisiscono LSN/SCN della sorgente, timestamp di commit, conteggio delle righe e checksum per partizione. Monitorare il lag di Datastream, lo stato di replica di DMS, i watermark di Dataflow, il backlog di Pub/Sub, lo stato dei job di STS e le metriche di inserimento in streaming di BigQuery. Motivazione: Il lineage end-to-end e i controlli quantitativi forniscono una prova verificabile (auditable) della correttezza e un sistema di allerta tempestivo su gap o ritardi.

Separando i layer di landing, curation e serving; utilizzando Cloud Storage come staging e archivio durevole a basso costo; sfruttando DMS/Datastream per il CDC con consumer idempotenti; e applicando controlli di schema e qualità all’ingresso, Northstar Retail realizza un’ingestione sicura e scalabile e una migrazione a basso rischio, verificabile e con costi prevedibili.

← Spark · Tutti i domini · Orchestrazione dei Flussi di Lavoro e Automazione delle Pipeline →

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

Sfoglia Google →