L’orchestrazione dei flussi di ingestion e trasformazione è il cuore del data engineering su Azure. Azure Data Factory (ADF) e le Synapse Pipelines condividono lo stesso motore (Azure Integration Runtime) e lo stesso modello di oggetti: per l’esame devi conoscerne i componenti, le attività e i criteri di scelta architetturale.

I componenti fondamentali

Quattro astrazioni costruiscono ogni pipeline:

  • Linked service: la stringa di connessione a una risorsa esterna (Azure Blob, ADLS Gen2, Azure SQL, un REST endpoint). Definisce dove e come autenticarsi — idealmente con Managed Identity e segreti in Azure Key Vault, mai credenziali in chiaro.
  • Dataset: la vista tipizzata su una struttura dati raggiunta tramite un linked service (una cartella, un file, una tabella). Descrive cosa leggere/scrivere, non l’azione.
  • Activity: la singola unità di lavoro (copia, trasformazione, chiamata a un notebook, stored procedure).
  • Pipeline: il contenitore logico di attività, con dipendenze, retry, trigger (schedule, tumbling window, storage event).

L’Integration Runtime (IR) è il compute che esegue: Azure IR per fonti cloud, Self-hosted IR per accedere a origini on-premises o dentro una VNet privata.

Copy activity vs Mapping Data Flow

La distinzione più ricorrente d’esame.

La Copy activity sposta dati da A a B con trasformazioni minime (mapping colonne, cambio di formato/serializzazione). È efficiente per ingestion massiva e supporta il Copy Data Tool e lo staging via PolyBase/COPY verso un dedicated SQL pool. Non fa logica di business complessa.

Il Mapping Data Flow è la trasformazione code-free (join, aggregate, derive, pivot, surrogate key, slowly changing dimension): tu disegni il grafo visuale, ADF lo traduce e lo esegue su un cluster Spark gestito provisioning automatico. Non scrivi Scala/PySpark, ma paghi il compute Spark a runtime. Scegli Data Flow quando servono trasformazioni in-flight su larga scala senza gestire un cluster; scegli Copy quando devi solo trasferire. Per logica che richiede codice custom o librerie, ha senso invece un’attività Notebook verso Databricks o uno Spark pool Synapse.

Control flow e pipeline metadata-driven

Il control flow governa il come si eseguono le attività:

  • Lookup: legge un valore o un set di righe (spesso da una tabella di controllo) e lo passa alle attività successive.
  • ForEach: itera su un array, in parallelo o sequenziale (isSequential), per processare N elementi con la stessa logica.
  • If Condition / Switch: branching basato su espressioni.
  • Until, Get Metadata, Execute Pipeline completano il quadro.

Il pattern architetturale chiave è la pipeline parametrizzata / metadata-driven: invece di replicare una pipeline per ogni tabella, memorizzi in una control table l’elenco di sorgenti (nome tabella, schema, destinazione, watermark). Una Lookup legge la tabella di controllo, un ForEach itera sulle righe e una Copy activity parametrizzata usa quei valori. Aggiungere una nuova sorgente diventa una riga di configurazione, non un redeploy. Le parameter (impostate al trigger) e le variable (mutabili in esecuzione) alimentano le espressioni @item(), @pipeline().parameters, @activity(...).output.

Azure Data Factory vs Synapse Pipelines

Funzionalmente sono quasi sovrapposti; l’esame premia le differenze pratiche di integrazione:

  • Synapse Pipelines vivono dentro il Synapse workspace: accesso nativo a dedicated/serverless SQL pool e Spark pool, una sola UI per pipeline, notebook, SQL e Power BI. Ideale se il tuo stack è già Synapse.
  • ADF è il servizio standalone, più maturo su alcuni fronti: supporta SSIS Integration Runtime (lift-and-shift di pacchetti SSIS), i Data Flow con più connettori, e l’integrazione con Git e i Managed Airflow.
  • CI/CD: ADF usa il classico flusso ARM template + branch di collaborazione; Synapse ha il suo publish flow. Gli artefatti non sono interscambiabili tra i due.

Nota di attualità: molte funzionalità di orchestrazione confluiscono ora in Microsoft Fabric Data Factory, ma DP-203 valuta ancora ADF e Synapse “classici”.

Trappole tipiche d’esame

  • Serve trasformazione complessa senza scrivere codice, su grandi volumi → Mapping Data Flow (Spark gestito), non la Copy activity.
  • Devi solo caricare velocemente file in un dedicated SQL pool → Copy activity con staging (PolyBase/COPY), non un Data Flow.
  • Ingestion di 200 tabelle con la stessa logica → Control table + Lookup + ForEach + Copy parametrizzata (metadata-driven), non 200 pipeline.
  • Origine dati on-premises o in VNet privata → Self-hosted Integration Runtime, non l’Azure IR.
  • Lo stack è tutto in Synapse e vuoi un’unica UI con Spark e SQL pool → Synapse Pipelines; se ti serve rehosting di pacchetti SSIS, allora Azure Data Factory con SSIS IR.