Come Deutsche Börse ha creato uno strumento di intelligenza artificiale generativa per gestire la migrazione su larga scala di notebook Zeppelin a Databricks

In Deutsche Börse Group, la nostra piattaforma StatistiX fornisce circa il 95% di tutti i dati di Clearing e Trading all'interno del gruppo, abilitando l'analisi self-service per centinaia di utenti aziendali. Mantenere questi dati accessibili e utilizzabili è fondamentale per tutto ciò che facciamo.

Per anni, ciò ha significato notebook Zeppelin in esecuzione su Cloudera, con accesso ai sistemi dati HDFS e Oracle. La piattaforma ci ha servito bene, ma il panorama è cambiato. Cloudera sta dismettendo completamente Zeppelin nel 2027, i nostri carichi di lavoro di analisi si stanno spostando nel cloud e Databricks è stata selezionata come nostra nuova piattaforma di analisi unificata. Questa combinazione ha creato una sfida di migrazione che la maggior parte delle organizzazioni sottovaluta: oltre 2.000 utenti e un elevato volume di notebook, molti dei quali profondamente integrati nei flussi di lavoro aziendali quotidiani, tutti da spostare.

Riscrivere tutto manualmente richiederebbe anni. Quindi abbiamo deciso di costruire un percorso migliore su Databricks.

Il problema della migrazione dei notebook

Le migrazioni dell'infrastruttura ricevono molta attenzione. Le migrazioni dei notebook tendono a non riceverla, il che è un motivo importante per cui rallentano i team.

I nostri notebook Zeppelin non erano semplici script. Contenevano complessa logica SQL e Python, interpreti personalizzati, riferimenti Oracle e HDFS, visualizzazioni, widget e logica di pianificazione sviluppati nel corso degli anni. Ognuno rifletteva la conoscenza istituzionale dei team aziendali che facevano affidamento su di esso. La diversità nell'intero panorama dei notebook rendeva impraticabile un motore di riscrittura basato su regole, poiché la logica era semplicemente troppo eterogenea e troppo specifica per il business per essere gestita in modo affidabile da regole automatiche.

Questo vincolo ci ha portato a un'intuizione di progettazione più chiara: separare la struttura dalla logica e applicare lo strumento giusto a ciascuna. La conversione strutturale (mappatura del formato dei paragrafi di Zeppelin alle celle di Databricks, traduzione della sintassi dell'interprete, riformattazione dei metadati) è deterministica e automatizzabile, mentre la ricostruzione della logica non lo è. Fortunatamente, gli LLM sono ottimi in questa parte di conversione strutturale.

Costruire il convertitore su Databricks Apps

Con questo principio di progettazione in mano, abbiamo creato il Convertitore da Zeppelin a Notebook Databricks, un'app Databricks progettata specificamente per il nostro flusso di lavoro di migrazione.

L'app gestisce il lato strutturale della conversione: i paragrafi Zeppelin diventano celle Databricks, le mappature degli interpreti vengono applicate (%python, %sql, %pyspark e altri vengono tradotti nei loro equivalenti Databricks), e i metadati del notebook vengono riformattati in un JSON .ipynb valido. Il contenuto originale viene preservato esattamente. Non stiamo riscrivendo la logica in questa fase, solo preparandola per il passaggio successivo.

Quel passaggio successivo è Genie. Per ogni notebook caricato, l'app genera automaticamente un prompt consapevole del contesto che include dettagli specifici sul nostro ambiente Zeppelin. Pensate ai nostri interpreti personalizzati, alle origini dati e ai modelli di configurazione. Il prompt fornisce a Genie il contesto necessario per ricostruire accuratamente la logica in modo nativo per Databricks.

Il flusso di lavoro per un utente aziendale è semplice:

1. Esporta un notebook Zeppelin come JSON
2. Caricalo nell'app Databricks
3. Fai clic su Converti
4. Scarica il .ipynb convertito
5. Apri Databricks, carica il notebook, avvia Genie e incolla il prompt generato
6. Genie pone domande chiarificatrici e ricostruisce il notebook

L'app stessa è stata costruita con un frontend shadcn UI. Inizialmente, abbiamo creato un prototipo Streamlit, ma abbiamo ritenuto che shadcn ci offrisse un'interfaccia più professionale e scalabile. L'esperienza di sviluppo delle app Databricks ha reso semplice rilasciare rapidamente senza dover configurare infrastrutture separate.

Cosa abbiamo scelto di non automatizzare

Una delle decisioni di progettazione più importanti è stata determinare cosa lo strumento dovesse intenzionalmente lasciare intatto.

Il convertitore non riscrive la logica SQL, la logica Python, le visualizzazioni, i widget, i riferimenti Oracle e HDFS, la logica di pianificazione o il codice personalizzato specifico per il business. Tutto quel contenuto viene preservato nel notebook convertito, intatto, perché riscriverlo automaticamente introdurrebbe errori e minerebbe la fiducia nell'output. Questi sono esattamente gli elementi che variano maggiormente tra i notebook e che contengono la logica più critica per il business. Appartengono a Genie, che può interpretare il contesto, porre domande chiarificatrici e prendere decisioni che le regole non possono.

Questo approccio ibrido di automatizzazione della parte deterministica e delega della parte variabile ci consente di evitare la fragilità dei sistemi basati su regole e di sfruttare l'IA dove funziona davvero bene.

Il risultato: da ore a minuti

Combinando la conversione strutturale con la ricostruzione della logica assistita dall'IA, abbiamo ridotto la rielaborazione dei notebook da ore di lavoro manuale a 15-20 minuti per notebook, a seconda della complessità. Per una migrazione su larga scala di questa natura, che copre più domini aziendali, questo approccio trasforma quello che sarebbe stato un impegno dispendioso in termini di risorse e tempo in un flusso di lavoro scalabile e ripetibile che richiederà molto meno tempo.

Il guadagno di velocità cambia anche la natura del lavoro. Gli utenti aziendali non necessitano di una profonda competenza Databricks per migrare i propri notebook. Seguono una breve sequenza di passaggi, ottengono un prompt e lasciano che Genie si occupi della ricostruzione. Lo strumento è sufficientemente accessibile da far sì che la migrazione non richieda un team di ingegneri dedicato.

Cosa abbiamo imparato

Alcuni principi sono emersi da questo progetto che porteremmo in qualsiasi sforzo simile.

• Evita l'eccessiva ingegnerizzazione. Il nostro primo tentativo ha utilizzato un'architettura agentica più complessa che ha aggiunto overhead senza risolvere il problema principale. Un'interfaccia utente semplice e un backend pulito si sono rivelati esattamente sufficienti.
• La riscrittura basata su regole non scala per contenuti eterogenei. La diversità della logica tra i nostri notebook rendeva le regole impraticabili. Gli LLM sono essenziali per gestire questa variabilità e la chiave è progettare in modo ponderato il passaggio tra automazione e IA.
• Il contesto fa la differenza tra un buon prompt e uno eccellente. I prompt Genie generici producono risultati generici. Investire in un prompt che codifica la conoscenza del nostro ambiente specifico – interpreti, origini dati, modelli di configurazione – è ciò che ha reso l'output effettivamente utilizzabile.
• Coinvolgi il tuo team di piattaforma in anticipo. La nostra collaborazione con il team Databricks durante la creazione ci ha aiutato a rimanere allineati ed evitare rilavorazioni.

Prossimi passi

Sebbene lo sviluppo iniziale del nostro strumento di conversione sia completo, stiamo ora procedendo con test su larga scala nel mondo reale. Le nostre priorità immediate includono la finalizzazione delle definizioni dei prompt per migliorare l'accuratezza, la validazione dello strumento con notebook di diverse entità aziendali e IT, e la preparazione all'onboarding degli utenti.

L'implicazione più ampia è ciò che ci entusiasma di più. Questo progetto ha dimostrato che la migrazione assistita dall'IA non è una capacità futura, è disponibile ora! Combinando le app Databricks con l'IA generativa, abbiamo creato un flusso di lavoro ripetibile che trasforma uno dei problemi più difficili della trasformazione cloud in un processo rapido e scalabile.

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