In Microsoft Fabric l’ingestion e la trasformazione dei dati si possono realizzare con tre strumenti diversi, che vivono tutti nell’esperienza Data Factory e Data Engineering: la data pipeline, il Dataflow Gen2 e il notebook Spark. Non sono alternative equivalenti: ciascuno ha un modello di esecuzione, un profilo di costo e un pubblico ideale differenti. Nella DP-700 buona parte delle domande scenario chiede proprio di scegliere lo strumento giusto dato un vincolo di volume, complessità o competenze del team.
Data pipeline: orchestrazione e movimento massivo
La data pipeline è il motore di orchestrazione. Il suo compito primario non è trasformare i dati, ma coordinare attività: la Copy activity per il movimento massivo da sorgenti esterne (database on-prem via on-premises data gateway, API, storage, altri cloud) verso OneLake, più attività di controllo del flusso come ForEach, If Condition, Lookup, Invoke pipeline e l’esecuzione di notebook o dataflow.
- Ideale per ingestion ad alto volume senza trasformazioni complesse (pattern copy-then-transform).
- Gestisce scheduling, dipendenze, retry e parametrizzazione.
- Non è il posto giusto per logica di trasformazione riga-per-riga: al massimo mapping e conversioni di tipo nella Copy activity.
Scenario tipico: “copiare quotidianamente 200 tabelle da un SQL Server on-prem al Lakehouse”. Qui la risposta è pipeline con Copy activity (spesso in un pattern metadata-driven con ForEach), non un dataflow.
Dataflow Gen2: trasformazione low-code
Il Dataflow Gen2 porta l’esperienza Power Query (linguaggio M) dentro Fabric. È lo strumento low-code/no-code per chi conosce Excel o Power BI e vuole trasformare visivamente: merge, unpivot, tipizzazione, deduplica, gestione errori.
- Ottimo per self-service e team con competenze prevalentemente analitiche, non di programmazione.
- Supporta staging e i data destination configurabili (Lakehouse, Warehouse, KQL Database, SQL Database).
- Riusabilità limitata: la logica vive dentro il dataflow, difficile da versionare e testare come codice.
È la scelta giusta quando la trasformazione è di complessità media, i volumi sono ragionevoli e conta la velocità di sviluppo più della performance di picco.
Notebook Spark: trasformazioni complesse e codice riusabile
Il notebook esegue codice PySpark, Spark SQL, Scala o R sul motore Spark distribuito di Fabric. È la scelta pro-code per alta scala e logica sofisticata.
- Migliore su volumi molto grandi: parallelismo distribuito, ottimizzazioni su Delta Lake / tabelle Lakehouse (partizioni,
OPTIMIZE, V-Order). - Logica riusabile e testabile: moduli condivisi, parametrizzazione via
%%configure, integrazione con Git e CI/CD. - Adatto a trasformazioni complesse (window function, join massivi, machine learning, streaming).
df = spark.read.format("delta").load("Tables/raw_sales")
agg = df.groupBy("region").sum("amount")
agg.write.mode("overwrite").saveAsTable("sales_by_region")Matrice decisionale
| Criterio | Data pipeline | Dataflow Gen2 | Notebook Spark |
|---|---|---|---|
| Volume | Alto (solo copia) | Basso-medio | Molto alto |
| Complessità trasformazione | Minima | Media, visuale | Alta, arbitraria |
| Riusabilità / versioning | Media (parametri) | Bassa | Alta (Git, moduli) |
| Competenze richieste | Basse-medie | Basse (Power Query) | Alte (Spark/Python) |
| Focus | Orchestrazione + movimento | Trasformazione low-code | Trasformazione a scala |
Nella pratica gli strumenti si combinano: una pipeline orchestra la Copy activity per l’ingestion, poi invoca un notebook per la trasformazione pesante nel layer Silver/Gold di un’architettura medallion.
Trappole tipiche d’esame
- Scenario: dataset di svariati miliardi di righe, trasformazioni complesse, ottimizzazione di costo e performance. → Risposta: notebook Spark, non Dataflow Gen2. Il dataflow è comodo ma su volumi molto grandi diventa più lento e più costoso perché consuma più Capacity Unit rispetto a Spark.
- Scenario: copiare in blocco molte tabelle da una sorgente on-prem verso il Lakehouse, senza trasformare. → Risposta: data pipeline con Copy activity (e on-premises data gateway), non un notebook o un dataflow.
- Scenario: analisti senza competenze di coding devono creare trasformazioni self-service con logica di merge e pulizia. → Risposta: Dataflow Gen2 (Power Query), non un notebook.
- Scenario: serve schedulare, gestire dipendenze e retry tra più step di ingestion e trasformazione. → Risposta: data pipeline come orchestratore che invoca dataflow e notebook; l’orchestrazione non si fa dentro un singolo notebook.
- Scenario: la stessa logica di trasformazione va riusata su più progetti, versionata in Git e testata. → Risposta: notebook (codice modulare), non un dataflow difficile da versionare.