Databricks ha pubblicato un playbook di campo per la migrazione da Azure Synapse. È materiale di parte, ovviamente, ma la parte tecnica è sufficientemente specifica da essere utile anche a chi la migrazione non l’ha ancora decisa: chiarisce dove si nasconde il lavoro vero.
Non stai migrando una piattaforma, ne stai migrando tre
Il primo errore è di scoping. Synapse è un brand, non un prodotto: sotto ci sono Dedicated SQL Pools, Serverless SQL Pools e Spark Pools, spesso con Azure Data Factory a orchestrare e talvolta workload SSIS legacy da sostenere. I tre componenti si muovono a velocità diverse. Gli Spark Pools sono i più semplici, perché entrambe le piattaforme poggiano su Apache Spark e i notebook migrano quasi invariati. I Serverless SQL Pools sono un query layer sui file: si tratta di ricostruire view, external table e access pattern. I Dedicated SQL Pools sono dove si concentra l’effort, perché lì ci sono anni di stored procedure, strategie di distribuzione e ottimizzazioni.
Trattare tutto come un unico workstream con una sola timeline è il modo più rapido per far slittare le date. Il playbook propone invece un programma per fasi — Discovery, Assessment, Design, Pilot, migrazione a ondate — con quattro workstream paralleli in esecuzione: ingestion, transformation, orchestration e consumption.
La conversione del codice: cosa cade e cosa resta
Il pattern più comune è la rimozione delle direttive fisiche. HASH, ROUND_ROBIN, REPLICATE, clustered columnstore index: in Databricks non hanno equivalente diretto e semplicemente spariscono, sostituite da Predictive Optimization e Liquid Clustering (con CLUSTER BY AUTO che aggiusta le clustering column osservando i query pattern). Le funzioni T-SQL si rimappano quasi tutte in automatico: GETDATE() diventa CURRENT_TIMESTAMP(), ISNULL diventa COALESCE, LEN diventa LENGTH.
Il rischio non è la sintassi, sono le differenze semantiche. Esempio citato e non ovvio: i Dedicated SQL Pools lavorano tipicamente con collation case-insensitive, mentre Databricks SQL è case-sensitive di default. Logica che si appoggiava implicitamente al confronto case-insensitive restituisce risultati diversi dopo la migrazione, e non lo scopri da un errore ma da un numero sbagliato.
Sul tooling: Lakebridge — Profiler, Analyzer, Reconcile — copre secondo Databricks l’80–90% della conversione, lasciando cursori, dynamic SQL ed error handling complesso al giudizio umano.
Le lezioni che valgono anche fuori da Databricks
Tre consigli sono trasferibili a qualsiasi migrazione. Primo: la validazione consuma più effort della migrazione stessa, quindi riconciliazione dopo ogni ondata (row count, aggregazioni, confronti hash-based, check con tolleranza). Secondo: non mappare le distribution key di Synapse sulle partition column di Delta — valori ad alta cardinalità come customer ID sono partition key pessime. Terzo: non spegnere Synapse troppo presto; tenere l’ambiente legacy con il compute in pausa costa poco e vale come rollback.
Sui numeri, il post cita due referenze: Casey’s ha ridotto i tempi di delivery dei dati operativi da otto a quattro ore; Italgas ha rimosso Synapse e Azure Analysis Services dichiarando una riduzione del 73% sui costi di workload.
In sintesi
- Synapse sono tre compute model distinti: pianificarli come un unico workstream sottostima effort e rischio.
- La sintassi si converte in automatico (80–90% con Lakebridge); le differenze semantiche, come le collation case-insensitive, no.
- Validazione e riconciliazione dopo ogni ondata pesano più della conversione; tenere Synapse in stand-by è la rete di sicurezza.
Hai qualcosa da aggiungere? Unisciti alla discussione.