Gestire la migrazione da Synapse a Databricks

Azure Synapse ha rappresentato una base affidabile per l'analisi SQL su larga scala e i team che l'hanno adottata hanno fatto una scelta sensata all'epoca. Tuttavia, una piattaforma progettata principalmente attorno a un data warehouse non è strutturata per gestire l'intera gamma di attività che oggi i team di dati sono chiamati a svolgere. Colmare queste lacune comporta solitamente l'aggiunta di ulteriori servizi, integrazioni e costi operativi, che si accumulano nel tempo.

La migrazione a Databricks è un modo per affrontare questo problema. In questo blog spieghiamo come approcciare la migrazione da Synapse e cosa tenere a mente durante la sua esecuzione.

Cosa sblocca la migrazione da Synapse

Tra i progetti di migrazione da Synapse che seguiamo con i nostri clienti, emergono costantemente tre fattori di business:

1. Patrimonio dati unificato. Con la crescita delle piattaforme dati, aumenta anche il numero di servizi coinvolti. Ad esempio, i pool di Synapse Analytics gestiscono un set di carichi di lavoro, i pool Spark un altro e il SQL serverless fornisce accesso ad hoc. Azure Data Factory spesso affianca questi strumenti per orchestrare il tutto. Molte organizzazioni hanno anche carichi di lavoro SSIS legacy che devono ancora essere supportati. Nessuno di questi componenti è problematico se preso singolarmente. Tuttavia, la sfida sorge quando vengono introdotti ulteriori servizi, poiché ciò aggiunge un altro livello di governance, monitoraggio, gestione dei permessi e costi operativi.
   Databricks affronta questo problema unificando data engineering, analytics, machine learning e governance su un'unica piattaforma. Invece di spostarsi tra servizi con modelli operativi diversi, i team possono lavorare sulla stessa architettura e sullo stesso framework di governance sottostanti. Il risultato è una minore complessità, un numero inferiore di punti di integrazione e una piattaforma più facile da gestire su larga scala.
2. Pronti per il futuro. L'attenzione dei moderni team di dati si è ormai spostata sul supporto a modelli di machine learning, pipeline di dati in tempo reale e applicazioni basate sull'IA. Tutti questi carichi di lavoro dipendono dagli stessi dati sottostanti. La sfida è che le architetture tradizionali incentrate sul data warehouse non sono state progettate per questo livello di convergenza e miravano principalmente a soddisfare le esigenze di BI. Con l'ampliarsi dei requisiti, le organizzazioni si trovano spesso ad aggiungere altri servizi e strumenti specializzati per colmare le lacune di funzionalità.
   Databricks è nato per questa convergenza, unificando dati, analytics e IA su un'unica piattaforma. Con Unity Catalog che offre una governance coerente su dati, notebook e asset di IA/ML, e Unity AI Gateway che estende tali controlli a modelli, agenti e applicazioni di IA, le organizzazioni possono adottare nuovi carichi di lavoro di IA senza aggiungere nuovi silos di governance.
3. Efficienza operativa. Sebbene la maggior parte dei business case di migrazione parta dai costi di licenza, raramente è da lì che derivano i risparmi maggiori. L'impatto più significativo deriva spesso dalla riduzione del numero di sistemi che i team devono gestire e supportare. Meno servizi significano meno integrazioni, meno passaggi di consegne tra strumenti e meno potenziali problemi.

Le organizzazioni che hanno già effettuato il passaggio stanno ottenendo risultati tangibili. Ad esempio, Casey's, la terza catena di convenience store negli Stati Uniti, ha migrato il proprio ambiente di analytics da Synapse a Databricks Lakehouse (precedentemente Databricks SQL), riducendo i tempi di distribuzione dei dati operativi da otto a quattro ore. Un altro esempio è Italgas, che ha semplificato la propria architettura eliminando sia Synapse sia Azure Analysis Services. L'azienda ha registrato una riduzione del 73% dei costi dei carichi di lavoro, distribuendo sia Power BI sia analytics basate sull'IA direttamente da Databricks.

Sebbene i dettagli varino da un'organizzazione all'altra, il modello rimane coerente: architetture più semplici, distribuzione dei dati più rapida e una piattaforma più allineata alle esigenze dei moderni team di dati.

Capire cosa si sta effettivamente migrando

Un aspetto che spesso coglie di sorpresa i team all'inizio di una migrazione da Synapse è la portata di ciò che stanno trasferendo. Sebbene Azure Synapse sia spesso considerata un'unica piattaforma, in pratica comprende una serie di servizi distinti che operano sotto lo stesso marchio, ognuno dei quali può richiedere strategie di migrazione diverse e presenta un livello di complessità differente.

La maggior parte delle migrazioni concentra la maggior parte degli sforzi sui Dedicated SQL Pool, dove logica di business, stored procedure, strategie di distribuzione, decisioni di indicizzazione e ottimizzazioni delle prestazioni si sono accumulate nel corso degli anni. Ma la complessità raramente si ferma al SQL. La stessa migrazione deve solitamente tenere conto dell'orchestrazione (Azure Data Factory e Synapse Pipelines), dei permessi e della governance (permessi SQL più Microsoft Purview, con la lineage spesso ricostruita manualmente), e della connettività BI e di terze parti (modelli semantici, report e strumenti a valle collegati direttamente agli endpoint Synapse). Questa è la parte del patrimonio che richiede il maggior lavoro di riprogettazione, test e convalida, ed è quella che più probabilmente viene sottovalutata.

I Serverless SQL Pool sono generalmente più semplici, perché forniscono principalmente un livello di query sui file in un data lake. In questo caso, la migrazione riguarda per lo più il ripristino di viste, tabelle esterne e pattern di accesso, piuttosto che la riprogettazione di carichi di lavoro complessi. I Spark Pool sono il componente più semplice da trasferire, poiché sia Synapse Spark sia Databricks sono basati su Apache Spark e i notebook possono spesso essere migrati con pochissime modifiche.

Il punto cruciale è che questi componenti si muovono a velocità diverse, coinvolgono stakeholder differenti e presentano rischi diversi. Le organizzazioni che affrontano la migrazione come un unico flusso di lavoro con un'unica tempistica spesso sottovalutano sia l'impegno sia la complessità. È così che le scadenze iniziano a slittare e i programmi di migrazione cominciano a espandersi oltre la loro portata originale. Per migrare con successo, i team dovrebbero strutturare il percorso di migrazione.

Come strutturare la migrazione

Una migrazione da Synapse a Databricks non è un singolo flusso di lavoro. Si tratta di spostare tre diversi modelli di calcolo, consolidare la governance, modernizzare l'orchestrazione e rielaborare anni di logica T-SQL accumulata. I team che gestiscono al meglio questo processo lo trattano come un programma strutturato piuttosto che come un progetto tecnico con un approccio a fasi.

Discovery. Ogni migrazione inizia con la comprensione di ciò che è effettivamente in esecuzione. Lakebridge Profiler scansiona il patrimonio Synapse e raccoglie metadati su configurazione, utilizzo delle risorse, pattern di query e baseline prestazionali. L'output viene utilizzato per creare un business case sul TCO.

Assessment. Una volta completato l'inventario, il passo successivo consiste nel comprendere la complessità. Lakebridge Analyzer valuta la codebase T-SQL, classificando ogni oggetto in base alla complessità, segnalando i costrutti non supportati e mappando le dipendenze. L'output può essere utilizzato per valutare la tempistica di migrazione e gli sforzi associati, oltre a definire la priorità delle migrazioni degli asset. Inizia con i carichi di lavoro a bassa e media complessità come obiettivi più facili da raggiungere, e pianifica in seguito l'impegno per i casi d'uso più critici.

Design. Una volta ottenuta visibilità sul patrimonio dati, l'attenzione si sposta sull'architettura e sul design. La prima scelta riguarda l'approccio: lift-and-shift, modernizzazione o ibrido. Per la maggior parte delle migrazioni da Synapse, l'approccio ibrido è la risposta giusta. Gli strumenti automatizzati gestiscono la maggior parte della conversione del codice per abbandonare Synapse nei tempi previsti, mentre la modernizzazione avviene in modo incrementale una volta che i carichi di lavoro sono in esecuzione su Databricks.

La seconda decisione riguarda la sequenza temporale. Un approccio BI-first tende a generare slancio più rapidamente rispetto a iniziare con l'ETL. Utilizzando Lakehouse Federation, puoi esporre i dati di Synapse tramite Unity Catalog prima che le pipeline sottostanti siano state spostate; un modo pratico per iniziare consiste nel caricare prima su Databricks i dati rivolti al business e arricchiti (i tuoi data mart), per poi metterli direttamente a disposizione degli utenti aziendali con Genie per l'analisi in linguaggio naturale. Gli stakeholder aziendali vedono progressi e valore fin da subito, mentre team di engineering modernizzano l'ETL sottostante più complesso. Leggi il nostro post del blog per definire l'approccio di migrazione più adatto a te.

Pilot. Prima di passare alla scalabilità, la strategia di migrazione deve essere convalidata end-to-end su un carico di lavoro reale. Scegli un caso d'uso pilota, migralo dall'ingestione fino al consumo e portalo in produzione. Un progetto pilota convalida l'architettura, il modello di governance, le procedure di test e gli strumenti rispetto a condizioni reali, producendo asset riutilizzabili per le fasi successive.

Migrazione a ondate. Per la fase di scalabilità, si raccomanda una migrazione a ondate. Ogni ondata è progettata per offrire un vantaggio di business visibile e stabilisce un ciclo di feedback con gli utenti finali.

L'esecuzione si articola solitamente in quattro flussi di lavoro paralleli: ingestione (spostamento dei carichi di lavoro ADF e Synapse Pipeline su Lakeflow Connect), trasformazione (migrazione delle procedure T-SQL e della logica di business su Databricks), orchestrazione (spostamento di pianificazioni e dipendenze su Databricks Workflows) e consumo (reindirizzamento degli strumenti di BI e dei modelli semantici verso i Databricks SQL Warehouses). L'esecuzione in parallelo consente ai team di generare valore rapidamente e di dismettere Synapse secondo tempistiche prevedibili.

Databricks supporta le migrazioni da Synapse da molteplici punti di vista: consulenza e implementazione da parte del nostro team di Forward Deployed Engineering, partner Brickbuilder certificati e acceleratori come Lakebridge che automatizzano le operazioni più complesse. L'obiettivo non è solo completare la migrazione, ma anche sviluppare le competenze e il modello operativo necessari al team per gestire la piattaforma a lungo, anche dopo la conclusione del progetto.

Ingestione dei dati

Prima di convertire il codice SQL, i dati devono essere inseriti nel lakehouse. Databricks offre diverse opzioni a seconda dei sistemi di origine e dei requisiti operativi.

Per molte sorgenti aziendali comuni, Lakeflow Connect offre un'esperienza di ingestione gestita con connettori integrati e gestione automatizzata delle pipeline. Allo stesso tempo, Databricks si basa su formati di archiviazione aperti, consentendo alle organizzazioni di utilizzare un'ampia gamma di strumenti di ingestione di terze parti. Soluzioni come Fivetran, Airbyte e altre piattaforme ETL/ELT possono inserire dati direttamente in Delta Lake, consentendo ai clienti di integrarsi con gli ecosistemi di integrazione dei dati esistenti anziché essere vincolati a un singolo framework di ingestione.

La conversione del codice nella pratica

Una volta che i dati sono disponibili nel lakehouse, l'impegno di migrazione si sposta sulla conversione del codice, che in genere rappresenta la fase più complessa del processo. Sebbene gli strumenti automatizzati gestiscano la maggior parte della traduzione (solitamente l'80-90%), lo sforzo rimanente viene dedicato al perfezionamento della logica procedurale e alla risoluzione di pattern che non possono essere tradotti automaticamente.

Di seguito sono riportate alcune differenze a cui prestare attenzione nella sintassi di Synapse e Databricks.

Rimozione delle direttive fisiche

Il pattern di conversione più comune è la rimozione delle direttive di ottimizzazione fisica. I Dedicated SQL Pools si affidano fortemente a costrutti come la distribuzione HASH, la distribuzione ROUND_ROBIN, la distribuzione REPLICATE e gli indici columnstore clusterizzati. Questi elementi sono fondamentali per l'ottimizzazione delle prestazioni di Synapse, ma non hanno un equivalente diretto in Databricks, pertanto vengono solitamente omessi durante la migrazione.

Databricks si affida invece all'ottimizzazione dello storage e a Liquid Clustering per migliorare le prestazioni delle query. La prima viene gestita automaticamente tramite Predictive Optimization, che esegue continuamente operazioni di manutenzione come la compattazione dei file, la raccolta delle statistiche e il comando VACUUM per le tabelle Delta. Il secondo è fornito da Liquid Clustering, che organizza i dati all'interno delle tabelle Delta utilizzando una o più colonne di clustering per migliorare le prestazioni delle query. La selezione delle colonne di clustering ottimali, tuttavia, dipende dalla comprensione di come vengono interrogate le tabelle, un compito spesso difficile nella pratica e che cambia frequentemente con l'evoluzione dei carichi di lavoro. Per ridurre questo carico operativo, Databricks ha introdotto CLUSTER BY AUTO, che identifica automaticamente e perfeziona continuamente le colonne di clustering in base ai pattern di accesso alle query osservati. Insieme, queste funzionalità riducono significativamente la quantità di ottimizzazione fisica manuale richiesta rispetto ai Dedicated SQL Pools.

Le decisioni di progettazione fisica che richiedevano un notevole sforzo ingegneristico in Synapse vengono semplicemente abbandonate. La piattaforma gestisce in modo autonomo ciò che prima richiedeva un intervento manuale.

Rimappatura delle funzioni

La maggior parte delle funzioni T-SQL comunemente utilizzate ha un equivalente diretto in Databricks e Lakebridge gestisce automaticamente la stragrande maggioranza delle mappature.

La fonte di problemi più comune non è la mappatura delle funzioni in sé, ma le differenze di comportamento che influenzano i risultati in modo impercettibile. Il confronto tra stringhe ne è un ottimo esempio. I Dedicated SQL Pools di Synapse operano solitamente con collation case-insensitive, mentre Databricks SQL è case-sensitive per impostazione predefinita. La logica che si affida implicitamente a corrispondenze non sensibili alle maiuscole/minuscole potrebbe restituire risultati diversi dopo la migrazione. Ove necessario, i confronti dovrebbero essere resi espliciti utilizzando LOWER() o UPPER() su entrambi i lati. La conversione della sintassi è solitamente semplice; le differenze semantiche richiedono maggiore attenzione.

Stored procedure: prima la migrazione, poi l'ottimizzazione

Grazie al supporto nativo delle stored procedure in Databricks, la maggior parte delle procedure di Synapse può essere migrata mantenendo intatta la struttura generale. Parametri, variabili, logica condizionale e operazioni DML sono tutti supportati.

La procedura in sé è raramente il problema. La complessità risiede al suo interno: cursori, elaborazione riga per riga, SQL dinamico e ottimizzazioni delle prestazioni specifiche di Synapse. Questi pattern richiedono capacità di valutazione, non una semplice traduzione.

SCD Type 2: preservare la cronologia con Delta Lake

Le Slowly Changing Dimension (SCD) rappresentano una delle aree in cui le implementazioni di Synapse variano maggiormente. Molte organizzazioni hanno accumulato nel corso degli anni stored procedure personalizzate e logiche di merge. L'obiettivo della migrazione non è riprodurre esattamente quell'implementazione, ma preservare il requisito aziendale: mantenere le versioni storiche dei record delle dimensioni mantenendo al contempo interrogabile lo stato corrente.

Un approccio comune in Databricks prevede due passaggi. Innanzitutto, impostare come scaduti i record che sono cambiati. Successivamente, inserire le nuove versioni.

Le transazioni ACID di Delta Lake rendono questo pattern sicuro anche quando sono coinvolte più operazioni.

Gestione degli errori

Molte stored procedure di Synapse si affidano a blocchi TRY...CATCH per acquisire gli errori o scrivere record di audit. Databricks SQL fornisce equivalenti nativi tramite gestori delle condizioni, consentendo alla maggior parte dei pattern esistenti di rimanere basati su SQL.

Gli scenari semplici, come la registrazione dei log di audit e i fallimenti controllati, si traducono solitamente in modo diretto. I flussi di lavoro più complessi potrebbero richiedere una progettazione aggiuntiva, in particolare quando è coinvolto il coordinamento a valle tramite Databricks Workflows.

Cosa insegna l'esperienza sul campo

Alcune lezioni emergono costantemente in tutte le migrazioni da Synapse, indipendentemente dalle dimensioni dell'organizzazione o dalla complessità dell'infrastruttura.

Inizia con la valutazione, non con la conversione. Esegui Lakebridge Profiler and Analyzer prima di scrivere una singola riga di codice convertito. Definisci chiaramente l'utilizzo effettivo, l'ambito, la complessità e le dipendenze, e usa questi dati per ridurre l'ambito dove possibile.

Automatizza con decisione. Lakebridge gestisce l'80–90% della conversione del codice. Concentra il tempo del team di ingegneria sul 10–20% che richiede il giudizio umano: cursori, SQL dinamico, gestione complessa degli errori.

Non sottovalutare mai la convalida. In pratica, la convalida spesso richiede più impegno rispetto alla migrazione stessa. L'approccio più efficace consiste nell'eseguire la riconciliazione dopo ogni ondata di migrazione, confrontando il numero di righe, le aggregazioni, i confronti dei record basati su hash e i controlli basati sulla tolleranza per i valori in cui un'uguaglianza esatta non è appropriata. Lakebridge Reconcile supporta questo processo in tutte queste dimensioni. Per i carichi di lavoro critici per il business, l'esecuzione di entrambi gli ambienti in parallelo prima del passaggio finale consente ai team di confrontare i risultati affiancati, mentre gli utenti continuano a lavorare con i report familiari.

Allontanati dal modo di pensare tipico di Synapse. Un buon esempio è la progettazione delle tabelle. I team tentano spesso di mappare le chiavi di distribuzione HASH di Synapse direttamente sulle colonne di partizione di Delta Lake. Nella maggior parte dei casi, questo introduce complessità non necessarie e prestazioni scarse. I valori ad alta cardinalità, come gli ID cliente o gli ID ordine, raramente sono adatti come chiavi di partizione e spesso vengono gestiti meglio tramite il liquid clustering e le funzionalità di ottimizzazione automatica di Databricks, come la manutenzione predittiva.

Non ricreare ciò che ora viene gestito dalla piattaforma. Le migrazioni offrono l'opportunità di semplificare le architetture anziché riprodurle esattamente. Delta Lake, l'ottimizzazione automatica e i moderni pattern di lakehouse eliminano molte delle tecniche di ottimizzazione manuale che erano necessarie nei tradizionali ambienti di data warehouse. Trasferire ogni decisione di ottimizzazione storica in Databricks spesso conserva i vecchi vincoli senza preservare i motivi per cui tali vincoli esistevano.

Pianifica l'operatività. Le tabelle Delta accumulano naturalmente file di piccole dimensioni man mano che i carichi di lavoro incrementali vengono eseguiti nel tempo. Senza processi di compattazione e manutenzione, le prestazioni possono degradare gradualmente. I team che provengono da piattaforme di data warehouse tradizionali sono spesso sorpresi dal fatto che l'ottimizzazione dello storage diventi parte del modello operativo continuo. Non è difficile da gestire, ma deve essere pianificato fin dall'inizio.

Pianifica la gestione del cambiamento. La maggior parte dei team Synapse non conosce Databricks e investire poco nell'abilitazione è uno dei motivi più comuni per cui i progetti non raggiungono gli obiettivi di adozione. Affronta il piano di abilitazione con la stessa serietà del piano tecnico.

Evita di dismettere Synapse troppo presto. La maggior parte delle migrazioni di successo mantiene disponibile l'ambiente legacy per un periodo successivo al trasferimento dei carichi di lavoro di produzione. Le risorse di calcolo possono essere messe in pausa per ridurre al minimo i costi, preservando al contempo un'opzione di rollback in caso di problemi imprevisti. Ancora più importante, mantenere questa rete di sicurezza offre sicurezza agli stakeholder aziendali mentre la nuova piattaforma dimostra il suo valore nell'uso reale.

La migrazione da Synapse a Databricks raramente è solo un progetto tecnologico. Fondamentalmente, comporta la semplificazione di una piattaforma che è diventata sempre più complessa nel tempo, stabilendo al contempo una base in grado di supportare la prossima generazione di prodotti di analisi, AI e dati. Sebbene il lavoro tecnico sia importante, le organizzazioni che traggono il massimo vantaggio da queste migrazioni sono quelle che sfruttano l'opportunità per semplificare la propria architettura, eliminare le complessità non necessarie e modernizzare contemporaneamente le proprie pratiche operative. Il vantaggio maggiore è quello di ottenere una piattaforma dati più semplice da gestire, più facile da estendere e meglio allineata con la direzione futura dell'organizzazione.

Cosa fare dopo

Se sei all'inizio di una migrazione da Synapse:

• Esegui Lakebridge Profiler and Analyzer sul tuo ambiente. Ottieni i dati prima di definire l'ambito del lavoro.
• Leggi il blog Migration Strategy: Lessons Learned e l'eBook Transforming Legacy Data Warehouses.
• Se desideri un aiuto pratico, il Databricks FDE Team e i partner di migrazione certificati offrono migrazioni Synapse end-to-end.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale