L’ingestione e l’elaborazione dei dati sono passaggi fondamentali in qualsiasi soluzione di analytics: prima di poter interrogare o visualizzare i dati, occorre spostarli dalle sorgenti (database, file, API, servizi cloud) verso una destinazione centralizzata come un data lake o un data warehouse. In questa unità vediamo i due grandi approcci di elaborazione — ETL ed ELT — e come Azure Data Factory li orchestra.

ETL vs ELT: due strategie di trasformazione

Entrambi gli approcci comprendono tre operazioni — Extract (estrai), Transform (trasforma), Load (carica) — ma cambiano l’ordine e il luogo in cui avviene la trasformazione.

ETL — Extract, Transform, Load

Nell’approccio ETL i dati vengono estratti dalla sorgente, trasformati in un ambiente intermedio (motore di elaborazione dedicato) e solo dopo caricati nella destinazione già puliti e conformati.

  • Quando usarlo: quando servono trasformazioni complesse prima del caricamento, oppure per rimuovere/mascherare dati sensibili (privacy, compliance) prima che raggiungano il repository finale.
  • Vantaggio: nella destinazione arrivano solo dati già validati e strutturati.
  • Limite: la trasformazione preventiva può rallentare l’ingestione di grandi volumi.

ELT — Extract, Load, Transform

Nell’approccio ELT i dati vengono estratti e caricati subito nella destinazione (tipicamente un data lake o un data warehouse come Microsoft Fabric / Azure Synapse), dove vengono poi trasformati sfruttando la potenza di calcolo scalabile del sistema di destinazione.

  • Quando usarlo: con grandi volumi di dati, quando si vuole conservare anche il dato grezzo, o quando servono elaborazioni parallele su motori distribuiti.
  • Vantaggio: ingestione più rapida e flessibilità di ritrasformare i dati in seguito.
  • Limite: richiede una destinazione con capacità di calcolo adeguata.

Azure Data Factory: il servizio di integrazione dati

Azure Data Factory (ADF) è il servizio cloud di integrazione dati di Azure: permette di creare flussi di lavoro senza scrivere codice (approccio low-code/visuale) per spostare e trasformare dati tra sorgenti on-premises e cloud. Supporta sia scenari ETL sia ELT ed è pensato per orchestrare pipeline su larga scala.

I suoi componenti principali sono:

  • Pipeline: contenitore logico che raggruppa un insieme di attività da eseguire come unità.
  • Attività (activity): singolo passo di elaborazione all’interno della pipeline. Esistono attività di spostamento dati (Copy activity), di trasformazione (es. Data Flow, notebook, stored procedure) e di controllo di flusso (loop, condizioni).
  • Dataset: rappresentazione della struttura dei dati usati come input o output di un’attività (es. una tabella, un file CSV, una cartella nel lake).
  • Linked service: la “stringa di connessione” verso una sorgente o destinazione (definisce dove e come connettersi; concetto correlato ai dataset).

I trigger: automatizzare l’esecuzione

Un trigger stabilisce quando una pipeline deve essere eseguita, abilitando l’elaborazione batch automatica. I tre tipi principali sono:

  • Schedule trigger: avvia la pipeline secondo una pianificazione oraria ricorrente (es. ogni notte alle 02:00). È il trigger classico per i carichi batch periodici.
  • Tumbling window trigger: esegue la pipeline su finestre temporali fisse, contigue e non sovrapposte. Adatto all’elaborazione di intervalli di tempo storici, con supporto a dipendenze e ripetizione dei tentativi.
  • Event-based trigger: avvia la pipeline in risposta a un evento, tipicamente l’arrivo o l’eliminazione di un file in Azure Blob Storage / Data Lake Storage. Ideale quando l’elaborazione deve partire “appena il dato è disponibile”.

Trappole tipiche d’esame

  • “Devi mascherare dati sensibili PRIMA che arrivino nel warehouse” → scegli ETL: la trasformazione avviene prima del caricamento, così i dati riservati non raggiungono mai la destinazione.
  • “Enormi volumi da caricare velocemente e trasformare poi nel data lake / Fabric” → scegli ELT: carichi prima e trasformi sfruttando la scalabilità della destinazione.
  • “La pipeline deve partire ogni notte a orario fisso” → Schedule trigger (non tumbling window, che serve per finestre temporali storiche con dipendenze).
  • “La pipeline deve avviarsi quando un nuovo file viene caricato in Blob Storage” → Event-based trigger, non schedule.
  • “Quale servizio Azure orchestra lo spostamento e la trasformazione dei dati?” → Azure Data Factory (servizio di integrazione dati); non confonderlo con Microsoft Purview, che si occupa di governance e catalogazione.