Google PDE: Machine Learning, AI e Distribuzione 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

La creazione di sistemi di machine learning e di erogazione dati di livello production su Google Cloud richiede una modellazione dati disciplinata, pipeline robuste e presidi operativi. Questa sezione copre lo sviluppo di modelli in BigQuery ML, il ciclo di vita gestito su Vertex AI (dataset, training, pipeline, endpoint, ingegneria delle feature e monitoraggio), la progettazione del percorso di predizione (batch o online), i feature store e la correttezza point-in-time, l’etichettatura e i controlli del bias, la ricerca vettoriale e i pattern di retrieval-augmented generation, il lineage e la governance, il monitoraggio del drift e i trigger per il retraining, i layer di erogazione per l’analytics e l’utilizzo dei dati nel rispetto della privacy. L’enfasi è posta sulle decisioni di progettazione, sulle strategie di scalabilità e sulle modalità di fallimento comuni da evitare.

BigQuery ML e Ingegneria delle Feature

BigQuery ML permette di eseguire training, valutazione e predizione direttamente in SQL, eliminando lo spostamento dei dati e allineando lo sviluppo dei modelli con i dataset analitici.

• Creazione del modello: usare CREATE MODEL con colonne di etichette esplicite e trasformazioni delle feature per evitare il leakage e standardizzare gli input. Esempio: CREATE OR REPLACE MODEL ds.churn_model OPTIONS( model_type=‘logistic_reg’, input_label_cols=[‘churned’], l1_reg=0.0, l2_reg=1.0, data_split_method=‘AUTO’ ) TRANSFORM( standardize(tenure_months) AS tenure_std, quantile_bucketize(monthly_spend, 10) AS spend_bkt, one_hot_encoder(region) AS region_ohe, ml.feature_cross(struct(bucketize(lat, 60), bucketize(lon, 60))) AS latlon_cross, (xx + yy) AS r2 – aggiungere supporto per decision boundary circolari quando utile ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;

• Valutazione: usare ML.EVALUATE per ottenere metriche appropriate per il tipo di modello (es. ROC AUC per la classificazione, RMSE per la regressione). Tracciare baseline e intervalli di confidenza; mantenere i dataset di valutazione ordinati cronologicamente per approssimare le performance future. SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);

• Predizione: usare ML.PREDICT per uno scoring di tipo online in BigQuery, o esportare i modelli per il serving altrove. Considerare i budget di latenza del modello quando si usa BigQuery per lo scoring sincrono; per API ad alto QPS, eseguire il deploy su endpoint gestiti. SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);

• Trasformazioni delle feature: preferire le funzioni TRANSFORM dichiarative (standardize, one_hot_encoder, bucketize, quantile_bucketize, ml.feature_cross) per la riproducibilità e per vincolare il preprocessing all’artefatto del modello. Mantenere le trasformazioni idempotenti e deterministiche.

Considerazioni operative e modalità di fallimento:

• Inserimenti in streaming e freschezza delle query: lo streaming di BigQuery ha una consistenza finale (eventual consistency). Per aggregazioni in tempo reale che devono includere righe appena scritte, eseguire le query con un ritardo temporale che superi la latenza misurata del buffer di streaming. Un punto di partenza conservativo è attendere circa il doppio del ritardo medio di disponibilità osservato, o progettare watermark e gestione dei dati in ritardo (late-data) in Dataflow prima di caricarli su BigQuery.
• Costo e concorrenza: se i limiti di concorrenza degli slot on-demand diventano un collo di bottiglia, passare a prenotazioni flat-rate o flessibili e implementare la gestione del carico di lavoro (gerarchie e assegnazioni di prenotazioni) per garantire una capacità prevedibile.
• Qualità dei dati: per caricamenti batch da GCS con righe malformate, usare Dataflow per eseguire il parsing e la validazione dei record, scrivendo le righe corrette su BigQuery e quelle errate in una tabella dead-letter per l’ispezione. Evitare che BigQuery rifiuti interi file a causa di un piccolo numero di righe errate.

Ciclo di vita di Vertex AI, percorsi di previsione e feature store

Vertex AI fornisce servizi gestiti end-to-end per addestramento, pipeline, registro dei modelli, endpoint e monitoraggio.

• Set di dati e addestramento: registrare set di dati e metadati; utilizzare job di addestramento personalizzati o AutoML dove appropriato. Scegliere gli algoritmi in base ai vincoli:

  • I carichi di lavoro su singola VM con risorse limitate favoriscono modelli semplici (es. regressione lineare o regressione logistica) grazie alle basse richieste di memoria/CPU.
  • Le attività ad alta dimensionalità traggono spesso vantaggio dalla selezione delle feature o dalla combinazione di feature ridondanti per accelerare l’addestramento con una perdita minima di accuratezza.
  • Il rilevamento di anomalie non supervisionato è adatto quando gli esempi positivi sono rari e ci si aspetta che le anomalie future assomiglino a firme anomale note.

• Pipeline: implementare le Vertex AI Pipelines per codificare la preparazione dei dati, l’addestramento, la valutazione e i gate di deployment. Rendere persistenti parametri, SHA dei commit del codice, digest dei container e snapshot dei set di dati per garantire la riproducibilità.

• Endpoint e previsione:

  • Previsione online per carichi di lavoro a bassa latenza. Configurare repliche minime e massime e policy di autoscaling; profilare la latenza del modello al P95 e impostare gli SLO di conseguenza. Aggiungere deployment canary e suddivisione del traffico (traffic splitting) per rollout sicuri.
  • Previsione batch per job orientati al throughput (es. scoring notturno). Il batch evita l’overhead per richiesta ed è più economico per grandi volumi, ma offre una latenza più elevata.

• Ingegneria delle feature e feature store: utilizzare Vertex AI Feature Store per:

  • Store offline in BigQuery per l’addestramento.
  • Store online per ricerche a bassa latenza tramite ID entità. Garantire la coerenza tra addestramento e inferenza (training-serving consistency) condividendo la stessa logica di trasformazione (es. libreria Dataflow o definizioni delle feature) e utilizzando i timestamp delle feature per prevenire il data leakage. Mantenere la correttezza point-in-time con join temporali: SELECT f.* FROM ds.labels l JOIN ( SELECT entity_id, feature_ts, feature_val, ROW_NUMBER() OVER (PARTITION BY entity_id ORDER BY feature_ts DESC) AS rn FROM ds.features WHERE feature_ts <= l.event_ts ) f ON f.entity_id = l.entity_id WHERE f.rn = 1;

Compromessi di progettazione:

• Latenza dello store online vs. freschezza dei dati: gli store online basati su Bigtable forniscono bassa latenza; assicurarsi che i backfill e gli upsert in streaming siano idempotenti. Un’eccessiva asimmetria di scrittura (write skew) o “hot key” degradano le prestazioni: progettare gli ID entità per distribuire uniformemente il traffico.
• Batch vs. online: il batch riduce la complessità e il costo dell’inferenza (serving) ma può fornire previsioni obsolete (stale). Per comportamenti dinamici (es. raccomandazioni), combinare il riaddestramento periodico con feature aggiornate al momento dell’inferenza.

Qualità dei dati, etichettatura, bias, privacy e governance

Etichette di alta qualità e una governance rigorosa sono alla base di modelli affidabili.

• Etichettatura e sbilanciamento:

  • Utilizzare linee guida chiare per l’etichettatura e campionamento per il QA. Monitorare l’accordo tra annotatori (inter-annotator agreement).
  • Affrontare lo sbilanciamento delle classi con campionamento stratificato, ripesatura (reweighting) o ricampionamento (resampling); monitorare precision/recall per classe, non solo l’accuratezza complessiva.
  • Conservare intenzionalmente i valori null. Se un modello richiede input numerici, codificare i null in modo esplicito (es. 0 con un indicatore “was_null”) e validare l’impatto a valle; evitare di scartare silenziosamente valori mancanti informativi.

• Overfitting e generalizzazione:

  • Le mitigazioni includono dati di addestramento più diversificati, set di feature più piccoli e una regolarizzazione più forte.
  • L’arresto anticipato (early stopping) e la convalida incrociata (cross-validation) sono essenziali per le reti neurali; il sottocampionamento (subsampling) può ridurre i tempi di addestramento quando la scalabilità dell’architettura o dell’hardware non è praticabile.

• Governance e lineage:

  • Tracciare la derivazione (lineage) con Vertex ML Metadata, Model Registry e Data Catalog. Registrare versioni dei set di dati, trasformazioni, iperparametri e ambiente.
  • Flussi di lavoro di approvazione: richiedere l’approvazione umana prima del deployment, utilizzando gli stati di Model Registry e Cloud Build/Deploy con controlli di policy. Archiviare gli artefatti in Artifact Registry; firmare i container e applicare Binary Authorization per rollout controllati (gated).

• Monitoraggio, deriva e riaddestramento:

  • Abilitare il monitoraggio del modello per l’asimmetria delle previsioni (prediction skew), la deriva delle feature (feature drift) e il degrado delle prestazioni. Utilizzare metriche distribuzionali (es. PSI, divergenza KL) e una valutazione consapevole del ritardo del ground-truth dove le etichette arrivano in seguito.
  • Stabilire trigger di riaddestramento basati su una deriva statisticamente significativa, violazioni degli SLO o finestre di eventi di business. Automatizzare le pipeline di riaddestramento ma controllare la promozione con valutazioni e controlli del bias.
  • Fare attenzione alla deriva silenziosa dei dati (silent data drift) dovuta a modifiche dello schema a monte; imporre contratti di schema e generare alert su feature mancanti o modificate.

• Progettazione attenta alla privacy:

  • Classificare i dati utilizzando i policy tag di Data Catalog; applicare la sicurezza a livello di colonna e di riga in BigQuery, con policy di mascheramento dei dati.
  • Minimizzare la raccolta dei dati; implementare SLA di conservazione e cancellazione dei dati legati alla limitazione dello scopo.
  • Applicare DLP per la scoperta e la de-identificazione; crittografare i dati con CMEK; isolare i servizi con VPC Service Controls; garantire un IAM granulare e utilizzare account di servizio dedicati con il principio del privilegio minimo (least privilege).
  • Per il monitoraggio e il logging, redigere le PII ed evitare il logging dei payload dove non necessario.

Ricerca vettoriale, pipeline RAG e layer di serving per l’analisi

Il recupero e il serving moderni richiedono sia componenti nativi per i vettori sia store di analisi collaudati.

• Ricerca vettoriale ed embedding:

  • Utilizzare Vertex AI Vector Search o la ricerca vettoriale di BigQuery per il recupero dei nearest neighbor su larga scala e a bassa latenza; scegliere AlloyDB for PostgreSQL con pgvector per semantica incentrata sull’applicazione ed esigenze transazionali.
  • Generare embedding in batch con Vertex Pipelines; archiviare i vettori insieme a metadati densi; partizionare e indicizzare in modo intelligente (ad es., per dominio del documento) per limitare la latenza.

• Pipeline di generazione aumentata da recupero (RAG):

  • Eseguire l’ingestion dei contenuti tramite Dataflow o Dataproc, estrarre il testo, suddividerlo in chunk, creare embedding e indicizzarlo in un vector store. Mantenere i riferimenti alla fonte di verità (source-of-truth) per la tracciabilità.
  • Implementare strategie di aggiornamento (freshness): re-embedding periodico, invalidazione in seguito ad aggiornamenti della fonte e indexing canary per validare la qualità prima di sostituire gli indici.
  • Monitorare la qualità del recupero (hit rate, MRR, nDCG) e la sicurezza dei contenuti; applicare guardrail e controlli di accesso per i dati soggetti a restrizioni.

• Layer di serving per l’analisi e data product:

  • Curare data product di livello bronze/silver/gold in BigQuery; utilizzare partizionamento e clustering per minimizzare i costi di scansione. Le viste materializzate possono accelerare le query comuni.
  • Per ricerche chiave-valore a bassa latenza o contatori ad alto QPS, utilizzare Bigtable con chiavi di riga ben distribuite; evitare l’hot-spotting applicando salting o hashing ai prefissi.
  • Per carichi di lavoro OLTP e consistenza forte (strong consistency), utilizzare Cloud SQL o Spanner; scaricare l’analisi su BigQuery tramite ELT pianificati.
  • Progettazione dello streaming: Pub/Sub → Dataflow → BigQuery/Bigtable con autoscaling. Monitorare le metriche di backlog e watermark; l’autoscaling predefinito è sufficiente per carichi elastici, mantenendo i costi sotto controllo.

Suggerimento operativo:

• Per attivare notifiche su specifici job di inserimento in tabelle BigQuery, esportare le voci pertinenti di Cloud Logging in Pub/Sub utilizzando un filtro avanzato, quindi collegare gli alert dalla sottoscrizione:

undefined

undefined

undefined

Scenario pratico

AcmeStyle, un marketplace di moda, vuole mantenere aggiornate le raccomandazioni sul proprio sito man mano che le preferenze degli utenti cambiano di ora in ora. L’azienda acquisisce in streaming il comportamento di clic e acquisti e ha bisogno di combinarlo con il contesto del catalogo per aggiornare le raccomandazioni con bassa latenza e costi controllati.

Approccio:

1. Ingestion tramite streaming e quality gate

• Usare Pub/Sub per l’ingestion degli eventi dal web e dai dispositivi mobili. Un job di streaming di Dataflow valida gli schemi, arricchisce i dati con quelli del catalogo e scrive:
  • Eventi puliti in tabelle partizionate di BigQuery (event_date) per analisi offline e addestramento.
  • Aggiornamenti aggregati delle feature utente in Vertex AI Feature Store (store online) indicizzati per user_id. Motivazione: Pub/Sub disaccoppia producer e consumer; Dataflow fornisce semantica exactly-once con upsert idempotenti; BigQuery partizionato gestisce costi e conservazione dei dati; lo store online abilita ricerche in millisecondi.

2. Definizione delle feature con correttezza point-in-time

• Definire feature come CTR mobile (rolling CTR), affinità per il brand e recency con un event_time esplicito. Materializzare su:
  • Store offline in BigQuery per l’addestramento con join temporali vincolati a feature_ts <= label_ts.
  • Store online per il serving con TTL per prevenire valori obsoleti. Motivazione: Timestamp chiari prevengono il label leakage; definizioni coerenti tra offline e online assicurano la parità tra training e serving.

3. Addestramento e lineage del modello

• Implementare una Vertex AI Pipeline che:
  • Estrae i dati di addestramento da BigQuery usando finestre temporali (es. ultimi 30 giorni).
  • Applica le stesse trasformazioni usate nel serving (libreria condivisa).
  • Addestra un modello di ranking; registra i metadati (ID degli snapshot del dataset, SHA del commit del codice, iperparametri) in ML Metadata e registra il modello nel Model Registry. Motivazione: Le pipeline rendono le esecuzioni riproducibili e auditabili; il Model Registry centralizza versioni e approvazioni.

4. Percorsi di predizione batch e online

• Predizioni batch notturne che calcolano lo score dell’intera matrice catalogo-utente e lo salvano in BigQuery per backfill e A/B testing.
• Predizioni online tramite un endpoint Vertex che:
  • Recupera le feature utente più recenti dallo store online.
  • Calcola lo score dei primi K candidati filtrati per inventario e disponibilità.
  • Mette in cache i risultati per brevi periodi per assorbire i picchi di traffico. Motivazione: Il batch offre ampiezza ed efficienza dei costi; l’online cattura il comportamento più recente per le sessioni di alto valore. Gli endpoint con autoscaling mantengono gli SLO di latenza; la cache riduce la tail latency e i costi.

5. Monitoraggio, rilevamento del drift e policy di riaddestramento

• Abilitare il monitoraggio del modello per il drift delle feature e lo skew delle predizioni; confrontare le distribuzioni con le baseline di addestramento. Tracciare gli SLO di CTR/CVR e inviare alert in caso di degrado.
• Riadattare continuamente usando una finestra mobile che combina dati storici e nuovi; attivare il riaddestramento quando il drift supera le soglie o, come minimo, settimanalmente. Motivazione: Le tendenze della moda cambiano rapidamente; unire lo storico con i segnali recenti stabilizza l’apprendimento pur rimanendo al passo con i tempi.

6. Privacy e governance

• Taggare le colonne PII con i policy tag di Data Catalog; applicare la sicurezza a livello di colonna in BigQuery ed eseguire il mascheramento dove necessario. Eseguire scansioni DLP sugli eventi grezzi; archiviare solo i campi necessari.
• Richiedere l’approvazione umana per promuovere i modelli da staging a produzione tramite trigger di Cloud Build integrati con gli stati di approvazione del Model Registry. Motivazione: L’accesso con privilegi minimi (least-privilege) riduce i rischi; controllare i deployment (gating) garantisce conformità e sicurezza.

7. Controlli di costo e capacità

• Usare le reservation di BigQuery per garantire una capacità di slot prevedibile per le finestre di addestramento.
• Scalare i worker di Dataflow automaticamente in base al backlog; eseguire lo sharding delle chiavi “calde” nel feature store tramite hashing dei prefissi di user_id per prevenire l’hot-spotting. Motivazione: Una capacità prevedibile evita la contesa; l’autoscaling adegua la spesa alla domanda; chiavi bilanciate mantengono aggiornamenti a bassa latenza.

Questo design mantiene le raccomandazioni aggiornate unificando le feature di streaming per il serving con un riaddestramento regolare su dati recenti, il tutto mantenendo correttezza, governance e prestazioni prevedibili su larga scala.

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

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

Sfoglia Google →