Google PDE: Archiviazione dei Dati, Data Lake e Formati di File — 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.

Formati dei file, compressione e comportamento delle query

La scelta del formato corretto ha un impatto di primo ordine su costi e prestazioni.

• Formati colonnari (Parquet, ORC)

  • Punti di forza: eliminazione delle colonne (column pruning), pushdown dei predicati (predicate pushdown), codifica e compressione per colonna, statistiche e file divisibili (splittable).
  • Compromessi: maggiore utilizzo della CPU in fase di scrittura; l’evoluzione dello schema deve essere gestita con attenzione (es. l’aggiunta di colonne è sicura; le modifiche dei tipi sono rischiose).
  • Compressione: Snappy per la velocità, ZSTD per rapporti di compressione migliori dove supportato. Evitare GZIP per i formati colonnari, a meno che non sia richiesto da vincoli di interoperabilità.

• Avro, orientato alle righe

  • Punti di forza: evoluzione dello schema con tipizzazione forte (strong typing), compressione a livello di blocco, divisibile (splittable); eccellente per le zone di atterraggio (landing zone) dello streaming e per l’interscambio di dati.
  • Compromessi: meno efficiente nella scansione per l’analisi rispetto ai formati colonnari; convertire in Parquet/ORC nelle zone curate.

• CSV e JSON (semi-strutturati)

  • CSV: leggibile dall’uomo, overhead minimo con valori semplici; manca di schema, tipi e coerenza nei caratteri di escape; costoso da analizzare (parsing) su larga scala.
  • JSON: autodescrittivo e flessibile; il formato JSON delimitato da newline è necessario per letture distribuite scalabili; verboso e pesante da analizzare (parsing) in termini di CPU.
  • Ove possibile, salvare i dati grezzi in CSV/JSON, quindi convalidarli e convertirli in Avro/Parquet per l’analisi.

• Tabelle esterne BigQuery e BigLake

  • Le tabelle esterne Parquet/ORC beneficiano del pushdown e dell’eliminazione delle colonne; le tabelle CSV/JSON in genere no, il che porta a un maggior numero di byte scansionati.
  • Le tabelle esterne CSV compresse (GZIP) non possono essere suddivise tra i worker; aspettarsi letture più lente.
  • Esempio: creazione di una tabella BigLake in formato Parquet con partizioni in stile Hive: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Layout, partizionamento, ingegneria delle prestazioni, residenza e migrazione

• Layout e partizionamento degli oggetti

  • Adottare percorsi in stile Hive per partizioni e chiavi di clustering: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Mantenere le dimensioni dei singoli file nell’intervallo 128–1024 MB per un parallelismo bilanciato e un overhead delle attività ottimale. Evitare milioni di file per partizione.
  • Mitigare i problemi legati a file di piccole dimensioni:
    • Raggruppando gli upload lato client.
    • Utilizzando job di compattazione Dataflow/Spark per unire i file di piccole dimensioni nelle ore non di punta.
    • Archiviando i file originali di piccole dimensioni ed esponendo solo i dati compattati agli strumenti di analisi.

• Partizionamento e clustering di BigQuery

  • Partizionare in base al tempo di ingestione o a una colonna di filtro ad alta cardinalità (es. event_date). Evitare il sovra-partizionamento (es. al minuto) che fa esplodere i metadati.
  • Creare cluster in base a dimensioni comunemente filtrate/ordinate (fino a quattro). Il clustering aumenta la località dei dati e riduce i byte scansionati.
  • Preferire tabelle BigQuery native per analisi interattive intensive; usare BigLake/tabelle esterne per l’accesso governato al lake, la condivisione tra motori diversi e l’isolamento dei costi.

• Implicazioni sulle prestazioni delle query

  • I formati colonnari riducono materialmente i costi di scansione esterna; le tabelle esterne CSV/JSON richiedono spesso la scansione completa dei file.
  • Le garanzie di consistenza eliminano la necessità di ritardi artificiali nelle letture da Cloud Storage, ma i sistemi a valle (es. inserimenti in streaming in BigQuery) possono mostrare una breve latenza nella visibilità dei dati: progettare utilizzando watermark o ritardi di lettura dove necessario.

• Residenza, durabilità e ripristino

  • Selezionare le location di bucket/dataset per soddisfare i vincoli di residenza; collocare le risorse di calcolo nella stessa location per ridurre l’egress e la latenza.
  • Usare dual-region con turbo replication per un RPO basso; versioning e policy di conservazione per il ripristino da errori umani e ransomware.
  • Per il DR, replicare i bucket in un progetto/regione separata utilizzando la replica dei bucket e proteggerli con confini IAM separati.

• Migrazione e validazione sicure

  • Pianificare in più fasi: seed (trasferimento massivo), sincronizzazione incrementale (copia basata su mtime/finestre temporali), cutover (sorgente in sola lettura) e validazione post-cutover.
  • Validare con checksum, conteggi, totali in byte e decodifica di campioni. Per dati tabellari, confrontare i conteggi delle righe e gli aggregati hash:

undefined

• Usare precondizioni (ifGenerationMatch) per prevenire sovrascritture durante la copia parallela. Mantenere una finestra di rollback con il versioning o conservando la sorgente.
• Dopo la migrazione, abilitare il ciclo di vita e Autoclass in base al nuovo profilo di accesso; evitare di abilitare il blocco di conservazione (retention lock) finché le validazioni non sono state superate.

Scenario di un Problema Pratico

Acme Retail riceve quotidianamente invii di file CSV da un partner logistico in un bucket regionale di Cloud Storage. I file contengono occasionalmente righe malformate. Acme deve acquisire, validare, convertire in un formato pronto per l’analisi e caricare i dati in BigQuery per dashboard quasi in tempo reale, conservando le righe errate per ispezione e applicando la governance.

Approccio:

1. Acquisire e governare i dati grezzi in Dataplex

   • Creare un lake Dataplex con un asset di una zona “raw” mappato su gs://acme-raw/logistics/.
   • Motivazione: Governance, metadati e lineage centralizzati. Applicare IAM a livello di zona e contrassegnare i campi sensibili con policy tag per l’applicazione a valle.

2. Applicare ciclo di vita e conservazione

   • Applicare una policy di conservazione del bucket di 30 giorni e abilitare il versioning degli oggetti su acme-raw.
   • Motivazione: Protegge da sovrascritture/cancellazioni accidentali da parte del partner; una breve conservazione bilancia costi e recuperabilità. Il versioning facilita il rollback di consegne errate.

3. Validare e ingerire con una pipeline batch di Dataflow

   • Attivare un job Dataflow giornaliero tramite notifiche di finalizzazione dell’oggetto. Leggere i CSV con uno schema e una validazione per singolo record; scrivere i record validi in una tabella di staging di BigQuery (partizionata per event_date) e instradare gli errori di parsing/validazione a una tabella BigQuery dead-letter.
   • Motivazione: Dataflow fornisce un parsing parallelo e scalabile e una gestione robusta dei messaggi non recapitabili (dead-letter), consentendo agli analisti di ispezionare le righe errate. Questo rispecchia le best practice per la gestione di CSV di qualità eterogenea.

4. Compattare e convertire in Parquet nella zona curata

   • La stessa pipeline scrive i dati validati in gs://acme-curated/logistics/date=YYYY-MM-DD/ come file Parquet di dimensioni comprese tra ~256 e 512 MB.
   • Motivazione: Parquet abilita il column pruning e il predicate pushdown in BigQuery e Spark, riducendo i byte scansionati e migliorando la latenza; la compattazione mitiga l’overhead dei file di piccole dimensioni derivante dallo schema di consegna del partner.

5. Esporre analisi governate tramite BigLake

   • Creare una tabella esterna BigLake sul percorso Parquet curato con partizionamento automatico in stile Hive; applicare policy tag a livello di colonna e policy di accesso a livello di riga per filtri specifici del partner.
   • Motivazione: Accesso granulare e uniforme tra BigQuery e Spark con audit centralizzato. Il partition pruning riduce i costi di scansione sui filtri per data.

6. Caricare aggregati critici in tabelle BigQuery native

   • Per le dashboard ad accesso frequente (“hot”), eseguire un job BigQuery pianificato che ingerisca gli ultimi N giorni dalla tabella esterna Parquet curata in una tabella nativa partizionata e clusterizzata.
   • Motivazione: Lo storage nativo accelera la BI ad alta concorrenza, mentre la tabella esterna BigLake rimane il system-of-record governato per un accesso più ampio.

7. Monitorare e allertare con Cloud Logging e Pub/Sub

   • Creare un sink di log che filtri gli esiti dei job di Dataflow e di caricamento di BigQuery verso Pub/Sub; integrare con lo strumento di monitoraggio per allarmi istantanei su fallimenti o tassi elevati di righe errate.
   • Motivazione: Visibilità operativa mirata e specifica per tabella senza polling; supporta le pratiche SRE.

8. Ottimizzare classe di archiviazione e residenza

   • Mantenere il Parquet curato in classe Standard per 14 giorni, passare a Coldline dopo 30 giorni tramite una regola del ciclo di vita; archiviare sia i bucket raw che quelli curati nella stessa regione dei dataset BigQuery per evitare costi di egress.
   • Motivazione: Bilancia le prestazioni di lettura “hot” con i costi. La co-locazione mantiene la conformità e minimizza la latenza e i costi di egress.

9. Validare la qualità end-to-end

   • Dopo ogni esecuzione, confrontare conteggi e aggregati hash tra le tabelle di staging, esterna curata e nativa di BigQuery; mettere in quarantena le anomalie.
   • Motivazione: Rilevamento precoce di schema drift o regressioni nell’ingestione; gli hash crittografici o di tipo fingerprint forniscono una garanzia leggera senza la necessità di riscansioni complete.

Questo design fornisce un’ingestione resiliente con analisi dei messaggi non recapitabili (dead-letter), dati in formato Parquet pronti per l’analisi per query efficienti, governance centralizzata tramite Dataplex e BigLake, e policy del ciclo di vita ottimizzate per i costi, il tutto aderendo al principio dell’accesso con privilegi minimi e a operazioni auditabili.

← Architettura e Progettazione dell’Ingegneria dei Dati · Tutti i domini · Analisi con BigQuery e Ingegneria del Data Warehouse →

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

Sfoglia Google →