Ogni scenario di ingestion in Microsoft Fabric si risolve scegliendo fra tre strumenti: Dataflow Gen2, data pipeline e notebook Spark. L’esame DP-600 non chiede quale sia “il migliore”, ma quale sia adeguato a un requisito preciso: volume, competenze del team, orchestrazione, destinazione.
I tre strumenti a confronto
| Criterio | Dataflow Gen2 | Data pipeline | Notebook Spark |
|---|---|---|---|
| Motore | Power Query (M) | Copy activity / orchestratore | Spark (PySpark, Spark SQL, Scala, R) |
| Skill richiesta | Low-code, analisti | Low-code, data engineer | Codice, data engineer |
| Volume ideale | Piccolo/medio (Fast Copy per volumi alti) | Molto alto, copia massiva | Molto alto, con logica complessa |
| Trasformazioni | Sì, ricche e visuali | No (solo mapping colonne e conversione tipi) | Sì, arbitrarie |
| Orchestrazione e dipendenze | No | Sì (unico strumento che orchestra) | No (ma è invocabile) |
| Destination mapping | Lakehouse, Warehouse, KQL Database, Azure SQL | Molte sink, anche esterne | Qualsiasi tabella Delta in OneLake |
Regola pratica: se il requisito parla di “trasformazioni Power Query senza scrivere codice” o “analisti self-service” → Dataflow Gen2. Se parla di “orchestrare più attività con dipendenze, retry e schedulazione” → data pipeline. Se parla di “milioni di righe, merge/upsert Delta, logica di business complessa” → notebook.
Il pattern canonico: pipeline come orchestratore
Il pattern che l’esame premia quasi sempre è quello a due stadi, che separa il movimento dal calcolo:
- Copy activity copia i dati dal sistema sorgente (SQL, ADLS Gen2, API REST, S3) nella zona bronze del Lakehouse, in formato Delta o file grezzi. Nessuna trasformazione, massimo throughput.
- Notebook activity (o Dataflow activity) legge il bronze e produce silver/gold: pulizia, join, deduplica, tipi, aggregazioni.
- Attività successive — Stored procedure sul Warehouse, Semantic model refresh — chiudono la catena.
Le dipendenze fra activity si impostano trascinando i connettori nella canvas, scegliendo la condizione On success, On failure, On completion o On skipped. Più frecce entranti in una stessa activity si comportano come un AND: tutti i predecessori devono soddisfare la condizione.
Parametri e variabili fra activity
- Parametri di pipeline: valori in sola lettura passati all’avvio (
@pipeline().parameters.dataInizio). Usati per rendere la pipeline riusabile fra ambienti. - Variabili di pipeline: mutabili a runtime tramite l’activity Set variable / Append variable (
@variables('ultimoWatermark')). - Output di activity: si legge con
@activity('Copy dati vendite').output.rowsCopiedo, per una Lookup,@activity('Leggi watermark').output.firstRow.LastLoadDate. - Verso un notebook si passano i base parameters della Notebook activity, che diventano variabili della cella marcata come parameter cell; il notebook restituisce valori con
notebookutils.notebook.exit(), leggibili come@activity('Trasforma').output.result.exitValue.
Carico incrementale
Il pattern watermark è tutto pipeline: Lookup sull’ultimo valore caricato → Copy activity con query filtrata (WHERE ModifiedDate > '@{activity('Lookup').output.firstRow.wm}') → Stored procedure o notebook che fa il MERGE Delta → Set variable / update del nuovo watermark. Dataflow Gen2 offre l’incremental refresh dichiarativo, ma richiede una colonna DateTime e una destinazione compatibile: è più semplice, meno flessibile.
Trappole tipiche d’esame
- “Dobbiamo copiare 200 GB e applicare regole di business complesse: usiamo solo la Copy activity” → sbagliato: la Copy activity non trasforma. Fa mapping di colonne, conversione di tipi e poco altro. La trasformazione va delegata a un notebook, a un Dataflow Gen2 o a una stored procedure orchestrata dalla stessa pipeline.
- “Il carico incrementale duplica le righe a ogni run” → nella destinazione del Dataflow Gen2 è impostato Append invece di Replace. Append aggiunge sempre; Replace tronca e ricarica. Per un vero upsert servono un notebook con MERGE Delta o una stored procedure sul Warehouse: la destination del dataflow non fa upsert.
- “Lo storage nel workspace è il doppio dei dati attesi” → è lo staging del Dataflow Gen2, abilitato per default, che materializza i dati nel lakehouse di staging prima di scriverli nella destination. Disabilitalo per passthrough semplici verso un Lakehouse; lascialo attivo quando serve per la destinazione Warehouse o per il fast copy.
- “Il refresh del semantic model deve partire solo se il caricamento è andato a buon fine” → non schedulare due job indipendenti: metti tutto in una pipeline con dipendenza On success verso la Semantic model refresh activity.
- “Gli analisti devono manutenere le regole di pulizia senza scrivere codice” → Dataflow Gen2, non un notebook, anche se il volume è consistente: qui vince l’esperienza Power Query, non la performance.