Framework de decisão para migração de ETL para o Databricks

Sua equipe tem centenas de stored procedures, alguns agendadores, permissões espalhadas por funções e esquemas, e o prazo de renovação do cloud data warehouse se aproximando. Ninguém entra em acordo sobre o que migrar primeiro. Alguns querem reescrever tudo em PySpark. Outros querem mover o SQL como está e dar o trabalho por encerrado. Perdidos na conversa estão: os metadados, a linhagem e as permissões que se movem com o código, além da oportunidade de consolidá-los no caminho.

Nenhum dos extremos funciona. As equipes que têm sucesso na migração de data warehouse analisam cada carga de trabalho individualmente e escolhem a ferramenta certa para a tarefa. Este post sugere uma estrutura de decisão para a seleção: quando usar Lakehouse (Databricks SQL), Spark Declarative Pipelines ou PySpark, e como dividir o trabalho em fases para que você entregue resultados em vez de travar em um plano.

Três caminhos, uma migração

No Databricks, você pode migrar pipelines de ETL de três maneiras principais, que costumam ser usadas juntas.

Lakehouse (Databricks SQL)

Este é o caminho mais direto para equipes focadas em SQL. Ele abrange um espectro que vai do simples ao complexo. Ele é executado em SQL warehouses, que são acelerados por Photon por padrão e totalmente compatíveis com ANSI e Spark SQL (%sql). Escolha Serverless para cargas de trabalho variáveis ou imprevisíveis (inicialização rápida, dimensionamento até zero, pagamento por segundo). Escolha Classic para cargas de trabalho estáveis ou quando você precisar de controles específicos de rede ou de custos.

Uma tarefa SQL simples:

Quando a lógica exige controle de fluxo (condicionais), loops, variáveis, tratamento de erros ou execução baseada em parâmetros, as stored procedures oferecem essa camada procedural. Elas são governadas por meio do Unity Catalog e podem ser chamadas a partir de Workflows com parâmetros.

A regra geral: se o seu código legado for uma única instrução SQL, migre-o como uma tarefa SQL. Se ele tiver lógica procedural (variáveis, loops, parâmetros, tratamento de erros), encapsule-o em uma stored procedure, governada pelo Unity Catalog e que possa ser chamada a partir de Workflows. Não encapsule um SQL simples em uma procedure apenas porque o sistema original exigia isso.

Spark Declarative Pipelines (SDP)

Que faz parte do Lakeflow, adota uma abordagem diferente. Você declara o que seu pipeline deve produzir e o mecanismo gerencia a ordem de execução, as tentativas e o dimensionamento. Você conta com restrições integradas de qualidade de dados, resolução automática de dependências e lote e streaming unificados na mesma definição.

Por baixo dos panos, o Enzyme decide quando atualizar incrementalmente ou recalcular totalmente as tabelas derivadas. O escalonamento automático ajusta a capacidade de acordo com as mudanças no volume de dados, sem a necessidade de ajuste manual. Empresas como a Block contam com esse modelo declarativo para simplificar a orquestração de pipelines à medida que o uso cresce.

Notebooks PySpark e Spark SQL

Que oferecem controle total. Eles são executados em clusters de trabalho e lidam com as cargas de trabalho que não se adaptam a um SQL Warehouse ou a um pipeline declarativo.

Opte pelo PySpark quando a carga de trabalho exigir lógica de negócios complexa, engenharia de recursos de ML, integrações de API ou validação personalizada. O exemplo abaixo pontua transações com um modelo registrado no Unity Catalog:

Opte pelo Spark SQL em um notebook quando a linguagem ainda for SQL, mas a carga de trabalho puder exceder a capacidade do SQL Warehouse: tabelas muito grandes, shuffles intensos, ETL em lote de longa execução em que você deseja controle explícito sobre particionamento, broadcast joins ou cache.

Habilite o Photon no cluster de trabalho para tarefas de SQL ou DataFrame limitadas por computação: grandes junções, agregações, funções de janela, varreduras em grandes tabelas colunares. O Photon é um mecanismo nativo e vetorizado que acelera esses padrões sem alterações de código, incluindo UDFs do Pandas (baseadas em Arrow). Ignore o Photon quando as UDFs do Python baseadas em linhas dominarem, os conjuntos de dados forem pequenos ou a tarefa for puramente de I/O.

Os notebooks também se encaixam bem em pipelines híbridos: ingestão no SDP, enriquecimento em uma tarefa de notebook.

Matriz de decisão

A tabela abaixo é um ponto de partida para as conversas da equipe, não uma regra rígida.

Grade de decisão rápida

Encontre sua equipe na coluna e a complexidade da sua carga de trabalho na linha. A célula pode sugerir por onde começar.

Quatro fases em vez de uma abordagem big-bang

Em vez de decidir "qual abordagem usar para tudo", decida "o que fazer a seguir" em cada fase.

Fase 1 — Avaliar. Colete métricas do seu data warehouse legado: tempo de CPU, tempo de execução, frequência, tabelas de origem e destino. Classifique as cargas de trabalho por complexidade. Use ferramentas de migração, quando possível, para criar um inventário pontuado por valor versus dificuldade. Onde você encontra esses dados depende da origem. No Teradata, consulte DBC.QryLog. No SQL Server, use sys.dm_exec_query_stats. No Oracle, relatórios AWR. No Snowflake, QUERY_HISTORY. Os detalhes podem variar. Se você já tiver uma ferramenta de integração instalada, poderá aproveitar seus metadados para identificar relações entre tabelas ou contar com um LLM para ajudar a criar essa linhagem. O resultado é um mapa, não um plano de reescrita. O objetivo continua o mesmo: classificar as cargas de trabalho por consumo de recursos e nível de dependência para que você saiba por onde começar. Bem feita, essa avaliação leva dias usando ferramentas de migração, não semanas de script manual.

Fase 2 — Vitórias rápidas. Escolha cargas de trabalho que combinem baixo risco de migração com casos de uso de alta visibilidade para o negócio. Isso pode significar começar com jobs SQL pesados que são fáceis de converter, ou com pipelines de relatórios que colocam a nova plataforma diante das partes interessadas logo no início. Instruções simples se tornarão tarefas SQL em Workflows. A lógica procedural se torna stored procedures. Use transpiladores e conversão assistida por AI para a tradução inicial. Execute ambos os sistemas lado a lado e compare contagens de linhas, checksums e registros de amostra. O objetivo é criar confiança, tanto técnica quanto organizacional.

A Walgreens, por exemplo, desativou o Teradata on-premises em uma migração em fases e agora processa cerca de 40.000 eventos de dados por segundo no lakehouse, impulsionando a otimização da cadeia de suprimentos em quase 9.000 lojas.

Fase 3 — Modernizar. Agora, redesenhe os pipelines que valem a pena modernizar. Candidatos: fluxos onde restrições de qualidade de dados e linhagem reduzem verificações manuais, jobs em lote que se beneficiam de streaming tables e CDC, pipelines onde views materializadas reduzem a complexidade, e os metadados, permissões e auditoria que antes viviam em ferramentas separadas, agora consolidados sob o Unity Catalog. Um padrão comum é manter o procedimento legado como fallback enquanto o novo pipeline é executado em paralelo até passar na validação. Pipelines modernizados geralmente reduzem as janelas de lote de horas para minutos e eliminam a necessidade de ferramentas de DQ separadas.

Fase 4 — Otimizar. Consolide pipelines de ETL redundantes que só existiam para contornar as limitações do DW antigo. Mova pontos críticos complexos para o PySpark quando isso simplificar a lógica. Reavalie os limites entre lote (batch) e streaming agora que você tem um mecanismo unificado. É aqui que a migração se paga: a plataforma legada é desativada, os pipelines redundantes desaparecem e a arquitetura roda em um único sistema em vez de dois.

Onde as ferramentas de migração e a AI se encaixam

As ferramentas de migração automatizam o trabalho mecânico, mas não substituem as decisões de arquitetura. Três papéis típicos:

• Perfilamento e avaliação. Descubra stored procedures, scripts SQL e jobs de ETL. Mapeie dependências. O Lakebridge vem com um componente Analyzer que varre plataformas de data warehouse legadas e cria um inventário de objetos, padrões de uso e complexidade.
• Conversão de código. Traduza SQL e ETL do Teradata, Oracle, SQL Server, DataStage, Informatica e SSIS em pipelines declarativos ou do Lakehouse. O Converter do Lakebridge lida com stored procedures e fluxos de ETL, com orientações públicas citando até 80% de automação e cronogramas de projeto cerca de 2 vezes mais rápidos.
• Validação. Compare resultados entre sistemas com verificações automatizadas em schemas, contagens de linhas e agregações. O Lakebridge inclui um validator. A metodologia de migração da Databricks trata a reconciliação como uma fase de primeira classe, não como uma reflexão tardia.

Uma abordagem pragmática: deixe que as ferramentas cubram de 60% a 80% da conversão inicial e reserve o tempo dos engenheiros para os padrões que você realmente deseja modernizar. Isso evita uma migração direta (one-to-one) de débitos técnicos.

O que é removido

Migrações bem-sucedidas desativam sistemas ativamente, não apenas convertem código: servidores de agendamento (schedulers) autônomos, frameworks de DQ personalizados, ferramentas separadas de linhagem e metadados, compiladores de stored procedures específicos de fornecedores e estruturas de validação manuais. A migração não estará concluída até que esses sistemas sejam desligados e as cobranças parem.

Três antipadrões que travam as migrações

• Escolher um único caminho para tudo sem considerar as habilidades da equipe, o perfil de risco e o tipo de carga de trabalho. A equipe focada apenas em SQL perde oportunidades de modernização. A equipe focada apenas em PySpark reescreve SQL simples sem necessidade.
• Medir apenas o "percentual migrado" ignorando a duração da execução em paralelo, o tempo de validação e a desativação real dos sistemas legados. Cinquenta por cento migrado não significa nada se a antiga plataforma de data warehouse ainda estiver funcionando com custo total.
• Recriar agendadores (schedulers) antigos e camadas intermediárias no lakehouse em vez de usar workflows e pipelines declarativos. A migração é uma chance de simplificar a orquestração de pipelines. Aproveite-a.

Se o ETL de SQL continuar fragmentado entre mecanismos, camadas e ferramentas, a plataforma continuará fragmentada, mesmo que os dados estejam em formatos abertos.

Não existe uma única maneira correta de migrar pipelines de dados. O Lakehouse leva você até lá rapidamente: tarefas simples para lógica simples, stored procedures quando você precisa de controle procedural. O SDP oferece pipelines de ETL modernos com qualidade e linhagem integradas. Os Notebooks cuidam do resto, quer você use PySpark ou Spark SQL. Divida o trabalho em fases, comece com vitórias rápidas e use todos os aceleradores que puder.

Explore o Guia de Migração da Databricks para orientações técnicas passo a passo ou experimente você mesmo com a Edição Gratuita do Databricks.

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