Cos'è Power Query e perché pulire prima di modellare

Power Query è il motore di ETL (Extract, Transform, Load) integrato in Power BI Desktop (e in Excel, e in Fabric Dataflow Gen2). Esegue trasformazioni sui dati prima che vengano caricati nel modello.

L'editor di Power Query è una UI dove costruisci la pipeline di trasformazioni cliccando (rinomina, filtra, cambia tipo, unisci...). Ogni click genera uno stepscritto in linguaggio M. La sequenza di step diventa una "ricetta" riproducibile a ogni refresh.

La regola d'oro di Power BI: "clean before you model". Tutti gli errori dati (tipi sbagliati, nomi brutti, valori nulli, colonne extra) vanno risolti in Power Query — non con misure DAX "patch" né con trucchi nel report.

Perché:

• Performance: ogni colonna inutile pesa su VertiPaq. Toglierla in PQ risparmia memoria e tempo refresh.
• Robustezza: nomi consistenti = misure DAX leggibili. Tipi corretti = niente errori a runtime.
• Manutenibilità: la logica di trasformazione sta in un unico posto (gli Applied Steps), non sparsa tra mille misure correttive.
• Query folding: gli step PQ "translatable" in SQL vengono spinti sulla sorgente (vedi 2.2) — performance da DirectQuery moltiplicate.

Ogni azione cliccata in PQ aggiunge uno step nel pannello Applied Steps a destra. La sequenza è:

1. Source — la sorgente iniziale.
2. Navigation — selezione del foglio/tabella specifica.
3. Changed Type — i tipi delle colonne.
4. ...altre trasformazioni che hai aggiunto (Filter, Remove, Rename, ecc.).

Click su uno step per vedere lo stato dei dati a quel punto. Ottimo per debug. Puoi rinominare gli step, eliminarli, riordinarli (con cautela: alcuni dipendono da quelli prima).

let
    Source = Csv.Document(File.Contents("C:\Dati\vendite.csv"), [Delimiter=";", Encoding=1252]),
    PromuoviHeader = Table.PromoteHeaders(Source, [PromoteAllScalars=true]),
    CambiaTipo = Table.TransformColumnTypes(PromuoviHeader, {
        {"Data", type date},
        {"Importo", type number},
        {"IdCliente", Int64.Type}
    }),
    FiltraAnno = Table.SelectRows(CambiaTipo, each [Data] >= #date(2024,1,1)),
    RimuoviColonneInutili = Table.RemoveColumns(FiltraAnno, {"NotaInterna", "Flag"}),
    RinominaColonne = Table.RenameColumns(RimuoviColonneInutili, {{"Importo", "Fatturato"}})
in
    RinominaColonne

Tre verità da assimilare subito:

1. Power Query è dichiarativo, non procedurale: non scrivi un loop "per ogni riga fai...". Descrivi cosa vuoi (filtra dove Data > X) e PQ lo applica vettorialmente.
2. Le query sono lazy: niente viene eseguito finché non fai Close & Apply o un'anteprima. PQ ottimizza la pipeline prima di eseguire (folding incluso).
3. Le query sono immutabili: ogni step prende il risultato del precedente e ne crea uno nuovo. Non modifichi mai "le righe" in-place.

Quando la sorgente è un DB (o un servizio "intelligente" come SharePoint, Dataverse), PQ cerca di tradurre i tuoi step in una query nativa della sorgente (SQL, OData, ecc.) e di eseguirla lì. Si chiama query folding.

Vantaggi del folding:

• Dati filtrati lato sorgente → meno traffico → refresh più veloce.
• Indici/ottimizzazioni della sorgente sfruttati.
• Stessa velocità anche con dataset enormi.

Per verificare se uno step "folda":

• Right-click sullo step → "View Native Query". Se appare la SQL, folda. Se è grigio, no.

Cose che rompono il folding:

• Custom column con formule complesse.
• Merge con tabelle non-foldable.
• Trasformazioni "esoteriche" (es. Table.Buffer, certi List.Generate).

Power Query memorizza lo schema rilevato la prima volta. Se la sorgente cambia (colonna rinominata, nuova colonna), può succedere:

• Colonna rinominata: lo step "Changed Type" o "Renamed Columns" fallisce perché il nome vecchio non esiste più → errore al refresh.
• Colonna nuova: PQ non la include automaticamente; va aggiunta a mano negli step.
• Tipo cambiato: se cambia da numero a testo, lo step "Changed Type" può generare errori in alcune righe.