Como a Deutsche Börse criou uma ferramenta de IA generativa para lidar com a migração em larga escala de notebooks Zeppelin para Databricks

Na Deutsche Börse Group, nossa plataforma StatistiX fornece aproximadamente 95% de todos os dados de Clearing e Trading em todo o grupo, permitindo análises self-service para centenas de usuários de negócios. Manter esses dados acessíveis e acionáveis é central para tudo o que fazemos.

Por anos, isso significou notebooks Zeppelin rodando em Cloudera, com acesso aos sistemas de dados HDFS e Oracle. A plataforma nos serviu bem, mas o cenário mudou. A Cloudera está desativando completamente o Zeppelin em 2027, nossas cargas de trabalho de análise estão migrando para a nuvem e a Databricks foi selecionada como nossa nova plataforma unificada de análise. Essa combinação criou um desafio de migração que a maioria das organizações subestima: mais de 2.000 usuários e um grande volume de notebooks, muitos deles profundamente integrados aos fluxos de trabalho diários do negócio, todos precisando ser movidos.

Reescrever tudo manualmente levaria anos. Então, decidimos construir um caminho melhor na Databricks.

O problema da migração de notebooks

As migrações de infraestrutura recebem muita atenção. As migrações de notebooks geralmente não recebem, o que é um grande motivo pelo qual elas atrasam as equipes.

Nossos notebooks Zeppelin não eram scripts simples. Eles continham lógica SQL e Python complexa, interpretadores personalizados, referências Oracle e HDFS, visualizações, widgets e lógica de agendamento desenvolvidos ao longo dos anos. Cada um refletia o conhecimento institucional das equipes de negócios que dependiam dele. A diversidade em todo o cenário de notebooks tornou um motor de reescrita baseado em regras impraticável, pois a lógica era simplesmente muito heterogênea e específica do negócio para que regras automatizadas a manipulassem de forma confiável.

Essa restrição nos levou a uma ideia de design mais clara: separar a estrutura da lógica e aplicar a ferramenta certa a cada uma. A conversão estrutural (mapear o formato de parágrafo do Zeppelin para células Databricks, traduzir a sintaxe do interpretador, reformatar metadados) é determinística e automatizável, enquanto a reconstrução da lógica não é. Felizmente, os LLMs são ótimos nessa parte da conversão estrutural.

Construindo o conversor em Databricks Apps

Com esse princípio de design em mãos, construímos o Conversor de Notebooks Zeppelin para Databricks, um Databricks App projetado especificamente para nosso fluxo de trabalho de migração.

O aplicativo lida com o lado estrutural da conversão: parágrafos Zeppelin se tornam células Databricks, mapeamentos de interpretadores são aplicados (%python, %sql, %pyspark e outros são traduzidos para seus equivalentes Databricks), e metadados do notebook são reformulados em JSON .ipynb válido. O conteúdo original é preservado exatamente. Não estamos reescrevendo a lógica nesta fase, apenas preparando-a para a próxima etapa.

Essa próxima etapa é o Genie. Para cada notebook carregado, o aplicativo gera automaticamente um prompt sensível ao contexto que inclui detalhes específicos sobre nosso ambiente Zeppelin. Pense em nossos interpretadores personalizados, fontes de dados e padrões de configuração. O prompt dá ao Genie o contexto necessário para reconstruir a lógica com precisão de uma forma nativa do Databricks.

O fluxo de trabalho para um usuário de negócios é simples:

1. Exporte um notebook Zeppelin como JSON
2. Carregue-o no Databricks App
3. Clique em Converter
4. Baixe o .ipynb convertido
5. Abra o Databricks, carregue o notebook, inicie o Genie e cole o prompt gerado
6. Genie faz perguntas esclarecedoras e reconstrói o notebook

O aplicativo em si foi construído com um frontend shadcn UI. Originalmente, construímos um protótipo Streamlit, mas sentimos que o shadcn nos deu uma interface mais profissional e escalável. A experiência de desenvolvimento do Databricks Apps tornou simples o lançamento rápido sem a necessidade de configurar infraestrutura separada.

O que escolhemos não automatizar

Uma das decisões de design mais importantes foi determinar o que a ferramenta deveria intencionalmente deixar de fora.

O conversor não reescreve lógica SQL, lógica Python, visualizações, widgets, referências Oracle e HDFS, lógica de agendamento ou código personalizado específico do negócio. Todo esse conteúdo é preservado no notebook convertido, intocado, porque reescrevê-lo automaticamente introduziria erros e minaria a confiança no resultado. Esses são exatamente os elementos que mais variam entre os notebooks e que carregam a lógica mais crítica para o negócio. Eles pertencem ao Genie, que pode interpretar o contexto, fazer perguntas esclarecedoras e tomar decisões que as regras não podem.

Essa abordagem híbrida de automatizar a parte determinística e delegar a parte variável nos permite evitar a fragilidade dos sistemas baseados em regras e alavancar a IA onde ela realmente tem um bom desempenho.

O resultado: de horas para minutos

Ao combinar a conversão estrutural com a reconstrução de lógica assistida por IA, reduzimos a reexecução de notebooks de horas de esforço manual para 15 a 20 minutos por notebook, dependendo da complexidade. Para uma migração em larga escala dessa natureza, abrangendo múltiplos domínios de negócios, essa abordagem transforma o que teria sido uma tarefa demorada e intensiva em recursos em um fluxo de trabalho escalável e repetível que levará muito menos tempo.

O ganho de velocidade também muda a natureza do trabalho. Os usuários de negócios não precisam de conhecimento profundo de Databricks para migrar seus próprios notebooks. Eles seguem uma curta sequência de etapas, obtêm um prompt e deixam o Genie fazer a reconstrução. A ferramenta é acessível o suficiente para que a migração não exija uma equipe de engenharia dedicada.

O que aprendemos

Alguns princípios emergiram deste projeto que levaríamos para qualquer esforço semelhante.

• Evite a complexidade excessiva. Nossa primeira tentativa usou uma arquitetura agentica mais complexa que adicionou sobrecarga sem resolver o problema principal. Uma interface simples e um backend limpo se mostraram exatamente suficientes.
• A reescrita baseada em regras não escala para conteúdo heterogêneo. A diversidade de lógica em nossos notebooks tornou as regras impraticáveis. LLMs são essenciais para lidar com essa variabilidade e a chave é projetar a transição entre automação e IA de forma atenciosa.
• O contexto é a diferença entre um bom prompt e um ótimo. Prompts Genie genéricos produzem resultados genéricos. Investir em um prompt que codifique o conhecimento de nosso ambiente específico – interpretadores, fontes de dados, padrões de configuração – é o que tornou o resultado realmente utilizável.
• Envolva sua equipe de plataforma desde o início. Nossa colaboração com a equipe Databricks durante a construção nos ajudou a manter o alinhamento e evitar retrabalho.

Próximos passos

Embora o desenvolvimento inicial de nossa ferramenta de conversão esteja completo, agora estamos prosseguindo com testes em larga escala e no mundo real. Nossas prioridades imediatas incluem finalizar as definições de prompt para melhorar a precisão, validar a ferramenta com notebooks de várias entidades de negócios e TI, e preparar a integração dos usuários.

A implicação mais ampla é o que mais nos entusiasma. Este projeto demonstrou que a migração assistida por IA não é uma capacidade futura, está disponível agora! Ao combinar Databricks Apps com IA generativa, construímos um fluxo de trabalho repetível que transforma um dos problemas mais difíceis da transformação para a nuvem em um processo rápido e escalável.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original