L’ottimizzazione in Azure Synapse Analytics richiede di bilanciare due leve opposte: le performance (throughput, latenza delle query) e i costi (compute a consumo o riservato, storage). A livello associate devi saper scegliere il servizio e la configurazione giusti per lo scenario, non limitarti ad applicare ricette.

Dedicated SQL pool

Il dedicated SQL pool factura in base al livello di DWU (Data Warehouse Units), che scala compute e memoria in modo lineare. Le leve principali:

  • Scaling DWU: aumenta le DWU per finestre di carico intense (ETL notturni, refresh massivi) e riducile quando il carico è basso. È un’operazione online ma comporta un breve stacco delle connessioni; pianificala fuori dai picchi.
  • Pause/Resume: mettere in pause il pool azzera il costo di compute (paghi solo lo storage). È la leva di risparmio più forte per ambienti dev/test o warehouse usati solo in orari di ufficio. Lo storage resta persistente.
  • Result set caching: memorizza il risultato di query ripetitive; ideale per dashboard con query identiche. La cache si invalida quando i dati sottostanti cambiano.
  • Materialized view: pre-calcola aggregazioni e join costosi. Utile quando molte query condividono la stessa aggregazione pesante; l’optimizer le usa in automatico anche se la query interroga le tabelle base.
  • Statistiche aggiornate: statistiche obsolete portano l’optimizer a stime di cardinalità errate e piani lenti. Tienile aggiornate (CREATE/UPDATE STATISTICS), specialmente dopo grandi caricamenti.

Eliminare il data movement

In un’architettura MPP il nemico numero uno è il data movement (operazioni ShuffleMove/BroadcastMove). Per ridurlo:

  • Scegli la distribution corretta: HASH sulla colonna di join per le tabelle fact grandi, così le righe che si joinano stanno sullo stesso distribution.
  • Usa REPLICATE per le tabelle di dimensione piccole (< 2 GB), evitando il broadcast a runtime.
  • Allinea la colonna di hash tra fact e dimensioni frequentemente joinate.

Apache Spark pool

Sui Spark pool il costo è per vCore-ora dei nodi attivi:

  • Autoscale + auto-pause: attiva l’autoscale per adattare il numero di nodi al carico e imposta l’auto-pause (es. 15 min di inattività) per non pagare cluster idle.
  • Node size: dimensiona i nodi sul profilo del job. Job memory-intensive traggono beneficio da nodi con più RAM; evita di sovradimensionare per job leggeri.
  • Caching: usa cache()/persist() su DataFrame riutilizzati più volte nella stessa sessione per evitare ricalcoli, liberando poi la memoria.

Storage e small files

Sul data lake (ADLS Gen2):

  • Tiering: sposta i dati freddi/di archivio sui tier Cool o Archive con lifecycle policy; tieni Hot solo i dati query-attivi.
  • Compattazione degli small files: molti file piccoli degradano le performance di lettura (overhead di apertura). Compatta in file più grandi (target 128 MB–1 GB), preferendo formati colonnari come Parquet/Delta con OPTIMIZE su Delta.

Serverless vs dedicated

  • Serverless SQL pool: nessuna infrastruttura da gestire, si paga per TB elaborati dalle query. Ideale per esplorazione ad-hoc, carichi sporadici o imprevedibili direttamente sul lake.
  • Dedicated SQL pool: capacità riservata, prevedibile, con caching e materialized view; conviene per carichi costanti e ad alta concorrenza su un data warehouse strutturato.

La regola: carico costante e prevedibile → dedicated; carico intermittente o esplorativo → serverless.

Trappole tipiche d’esame

  • Warehouse usato solo di giorno, costo elevato di notte → metti il dedicated SQL pool in pause (non basta scalare le DWU: in pausa il compute non factura affatto).
  • Query di dashboard identiche ripetute, vuoi ridurre latenza e costo compute → abilita result set caching (per aggregazioni pesanti condivise, valuta le materialized view).
  • Job Spark sporadici che lasciano il cluster acceso → configura auto-pause con autoscale, non tenere il pool sempre attivo.
  • Query lente con molto data movement su join fact/dimension → riprogetta le distribution (HASH sulla chiave di join, REPLICATE per dimensioni piccole), non aumentare solo le DWU.
  • Esplorazione occasionale di file Parquet sul lake, non vuoi pagare compute fisso → usa il serverless SQL pool (pay-per-TB), non provisionare un dedicated pool.
  • Piani di esecuzione peggiorati dopo un grande load → aggiorna le statistiche: DWU sovra/sottodimensionate o statistiche stale sono la causa più comune di regressioni.