Dataflow Gen2: il motore Power Query in Microsoft Fabric

Dataflow Gen2 è l’esperienza di trasformazione low-code di Microsoft Fabric, basata sul motore di Power Query online (linguaggio M). Consente di connettersi a centinaia di sorgenti (database, file, API, servizi SaaS), applicare trasformazioni tramite un’interfaccia grafica a passi e materializzare il risultato in una destinazione dati gestita. È lo strumento pensato per data analyst e professionisti che conoscono Power Query da Power BI, ma che ora devono alimentare il data estate di Fabric anziché un singolo modello semantico.

A differenza di un notebook Spark, qui non scrivi codice imperativo: definisci una sequenza di applied steps e il motore genera ed esegue la query. Sotto il cofano, per le sorgenti che lo supportano, Power Query effettua query folding, cioè traduce i passi in SQL nativo eseguito dalla sorgente, riducendo i dati trasferiti.

Data destination: la vera novità rispetto a Gen1

Il salto architetturale rispetto a Dataflow Gen1 è la separazione tra logica di trasformazione e output. In Gen1 l’output era vincolato allo storage interno del dataflow (Azure Data Lake), consumabile quasi solo da Power BI. In Gen2 scegli esplicitamente una o più data destination:

  • Lakehouse — scrive tabelle in formato Delta/Parquet su OneLake; scelta tipica per pattern medallion e consumo da Spark/SQL analytics endpoint.
  • Warehouse — carica in tabelle T-SQL transazionali; adatto quando a valle servono modelli dimensionali e query SQL.
  • KQL database (Eventhouse) — per scenari di analisi time-series/log.
  • Azure SQL Database e altre destinazioni SQL esterne.

Per ogni tabella definisci il metodo di scrittura: Replace (sovrascrive) o Append (accoda), oltre alla gestione dello schema (mapping automatico o fisso). Questa flessibilità rende Gen2 un vero strumento di ingestion + transform, non solo di preparazione dati per report.

Refresh e orchestrazione con Data Factory pipeline

Un Dataflow Gen2 si aggiorna con un refresh, avviabile:

  • manualmente dal portale;
  • su schedule (pianificazione ricorrente configurata sull’artefatto);
  • come attività dentro una pipeline di Data Factory in Fabric.

L’orchestrazione via pipeline è la scelta corretta quando il dataflow è un tassello di un flusso più ampio: ad esempio una Copy activity che sbarca file grezzi, poi una Dataflow Gen2 activity che pulisce e conforma, infine una Notebook activity o una stored procedure per aggregazioni pesanti. La pipeline gestisce dipendenze, retry, parametri e trigger che il refresh schedulato del singolo dataflow non offre.

Quando Dataflow Gen2 è la scelta giusta (e quando no)

  • Scegli Dataflow Gen2 quando l’autore è un analista o power user, le trasformazioni sono self-service e dichiarative (merge, unpivot, type casting, filtri, colonne calcolate), le sorgenti supportano il folding e i volumi sono medio-piccoli.
  • Scegli un notebook Spark/PySpark quando servono logiche complesse, riuso di codice, librerie custom, gestione fine del parallelismo o quando i volumi sono grandi: Spark scala orizzontalmente e va in table in modo più efficiente, mentre il motore Power Query può diventare costoso e lento su dataset molto ampi.

Su Fabric tutto consuma la stessa capacity (CU): il refresh di un Dataflow Gen2, specie con staging attivo (che scrive dati intermedi in un Lakehouse/Warehouse di staging per abilitare il folding sulle destinazioni), può generare consumo significativo. Il fast copy riduce i tempi per grandi caricamenti da sorgenti file/database, ma il principio resta: valuta sempre il rapporto tra comodità low-code e costo di capacity.

Trappole tipiche d’esame

  • Scenario: un analista deve trasformare dati con Power Query e caricarli in un Warehouse, integrandoli in un flusso con retry e dipendenze. → Risposta: Dataflow Gen2 con data destination = Warehouse, orchestrato come attività in una pipeline Data Factory, non con il refresh schedulato standalone.
  • Scenario: trasformazione su decine di milioni di righe con logica complessa e requisiti di performance/costo. → Risposta: usa un notebook Spark, non Dataflow Gen2; Power Query non scala come Spork e brucia più capacity (CU).
  • Scenario: serve scrivere l’output in Lakehouse, Warehouse e KQL database. → Risposta: è possibile solo con Gen2; Gen1 non supporta data destination configurabili.
  • Scenario: i refresh sono lenti e il consumo di CU è alto pur con sorgente SQL. → Risposta: verifica il query folding e valuta lo staging; passi non-foldable forzano l’elaborazione lato motore Fabric.
  • Scenario: migrazione da Dataflow Gen1. → Risposta: Gen1 non offre destinazioni multiple né integrazione nativa nelle pipeline; per l’ingestion moderna in Fabric si adotta Gen2.