ETL, ELT ed ETLT: dove avviene la trasformazione

Il criterio guida è dove e quando trasformi. Nell’ETL (Extract, Transform, Load) i dati vengono trasformati in uno stage intermedio prima del load nel warehouse: utile quando devi pulire, standardizzare o mascherare dati sensibili prima che tocchino la destinazione, o quando il target ha capacità di calcolo limitate. Nell’ELT (Extract, Load, Transform) carichi i dati grezzi e trasformi dentro la destinazione: su Google Cloud il pattern tipico è caricare in BigQuery e trasformare con SQL, sfruttando il calcolo serverless e scalabile del data warehouse. L’ELT riduce la latenza di ingestion e conserva il dato grezzo per ri-elaborazioni future. L’ETLT è l’approccio ibrido: una trasformazione leggera a monte (formattazione, deduplica di base, filtri) e il grosso della logica a valle in BigQuery. Per l’esame associa ELT a BigQuery + SQL, ETL a scenari con pulizia o compliance a monte, e ricorda che Dataform orchestra trasformazioni ELT in SQL dentro BigQuery (non è Spark).

Trasferire i dati: Storage Transfer Service vs Transfer Appliance

La scelta dipende da online vs offline e dal volume rapportato alla banda disponibile. Storage Transfer Service è il servizio online e gestito per spostare dati verso Cloud Storage: da altri cloud (Amazon S3, Azure Blob Storage), tra bucket Cloud Storage, o da sorgenti on-premises tramite agenti. Supporta trasferimenti schedulati e ricorrenti, ideale per sincronizzazioni continue quando la banda è sufficiente. Transfer Appliance è invece la soluzione offline: un dispositivo fisico che Google spedisce, tu popoli in sede e rispedisci per l’ingestion in Cloud Storage. Si usa quando i volumi sono nell’ordine di molti TB o PB e la rete renderebbe il trasferimento online troppo lento o costoso. Regola pratica: online e ricorrente → Storage Transfer Service; volume enorme, una tantum, con banda insufficiente → Transfer Appliance.

Qualità dei dati e data cleaning

Valutare la qualità significa misurare dimensioni come completezza, accuratezza, coerenza, validità, unicità e freschezza. Prima di trasformare conviene profilare i dati (valori NULL, duplicati, outlier, formati incoerenti). Su Google Cloud queste verifiche si eseguono con query SQL in BigQuery, mentre Dataplex offre data quality scan per applicare regole di qualità governate a livello di lake.

Per il cleaning gli strumenti si scelgono in base a competenze e caso d’uso:

  • BigQuery + SQL: la via più diretta in ottica ELT — deduplica, normalizzazione, gestione dei NULL e cast di tipo direttamente sui dati già caricati.
  • Cloud Data Fusion: ETL visuale, code-free, basato su connettori e pipeline drag-and-drop; adatto a chi non scrive codice e per integrare molte sorgenti con trasformazioni riutilizzabili.
  • Dataflow: pipeline Apache Beam serverless per batch e streaming; la scelta quando la trasformazione è complessa, ad alto volume o in tempo reale, o non è esprimibile in SQL.

Il trade-off: SQL è rapido e familiare ma vive dentro BigQuery; Data Fusion è visuale e governato ma introduce un ambiente dedicato; Dataflow è il più potente e flessibile ma richiede competenze di programmazione (Beam).

Trappole tipiche d’esame

  • Volume enorme e banda scarsa → Transfer Appliance: se il testo enfatizza PB di dati o rete lenta/costosa, la risposta è l’offline fisico, non Storage Transfer Service.
  • Trasferimento ricorrente da S3/Azure a Cloud Storage → Storage Transfer Service: online, schedulato e gestito; qui Transfer Appliance è il distrattore.
  • “Trasforma con SQL dentro il warehouse” → ELT in BigQuery (Dataform): non è ETL, e la trasformazione SQL orchestrata è Dataform, non Dataflow né Dataproc.
  • Pulizia o mascheramento prima del load per compliance → ETL: se i dati sensibili non devono arrivare grezzi alla destinazione, trasformi a monte, quindi ETL (o ETLT).
  • Pipeline visuale senza codice → Cloud Data Fusion: quando lo scenario chiede un tool grafico per non sviluppatori, non è Dataflow, che richiede Beam e codice.
  • Streaming o trasformazione complessa non-SQL → Dataflow: batch e streaming con Apache Beam; il solo SQL di BigQuery non copre il tempo reale.