Navegando por uma migração do Synapse para o Databricks

O Azure Synapse tem servido como uma base confiável para análise SQL em escala, e as equipes que o adotaram fizeram uma escolha sensata na época. No entanto, uma plataforma projetada principalmente em torno de um data warehouse não foi criada para atender a toda a gama de demandas que se espera que as equipes de dados entreguem hoje em dia. Preencher essas lacunas geralmente envolve adicionar mais serviços, integrações e sobrecarga operacional, o que se acumula com o tempo.

Migrar para o Databricks é uma maneira de resolver esse problema. Neste blog, abordamos como estruturar a migração do Synapse e o que ter em mente ao executá-la.

O que a migração do Synapse desbloqueia

Nos projetos de migração do Synapse que acompanhamos com nossos clientes, três motivadores de negócios surgem de forma consistente:

1. Ambiente de dados unificado. À medida que as plataformas de dados crescem, o número de serviços envolvidos também aumenta. Por exemplo, os pools do Synapse Analytics lidam com um conjunto de cargas de trabalho, os pools do Spark lidam com outro e o SQL sem servidor (serverless) fornece acesso ad hoc. O Azure Data Factory geralmente funciona em conjunto com eles para orquestrar tudo. Muitas organizações também têm cargas de trabalho legadas do SSIS que ainda precisam de suporte. Nenhum desses componentes é problemático isoladamente. No entanto, o desafio surge quando serviços adicionais são introduzidos, pois isso adiciona outra camada de governança, monitoramento, gerenciamento de permissões e sobrecarga operacional.
   O Databricks resolve esse problema unificando a engenharia de dados, análise, machine learning e governança em uma única plataforma. Em vez de alternar entre serviços com diferentes modelos operacionais, as equipes podem trabalhar na mesma arquitetura subjacente e estrutura de governança. O resultado é a redução da complexidade, menos pontos de integração e uma plataforma mais fácil de operar em escala.
2. Preparação para o futuro. O foco das equipes de dados modernas agora mudou para o suporte a modelos de machine learning, pipelines de dados em tempo real e aplicativos baseados em AI. Todas essas cargas de trabalho dependem dos mesmos dados subjacentes. O desafio é que as arquiteturas tradicionais, centradas em data warehouses, não foram projetadas para esse nível de convergência e visavam principalmente atender às necessidades de BI. À medida que os requisitos se expandem, as organizações muitas vezes se veem adicionando mais serviços e ferramentas especializadas para preencher lacunas de recursos.
   O Databricks foi criado para essa convergência, unificando dados, análise e AI em uma única plataforma. Com o Unity Catalog fornecendo governança consistente em dados, notebooks e ativos de AI/ML, e o Unity AI Gateway estendendo esses controles para modelos, agentes e aplicativos de AI, as organizações podem adotar novas cargas de trabalho de AI sem adicionar novos silos de governança.
3. Eficiência operacional. Embora a maioria dos casos de negócios de migração comece com custos de licenciamento, raramente é daí que vêm as maiores economias. O maior impacto geralmente vem da redução do número de sistemas que as equipes precisam operar e dar suporte. Menos serviços significam menos integrações, menos transferências entre ferramentas e menos problemas em potencial.

As organizações que já fizeram a transição estão colhendo resultados tangíveis. Por exemplo, a Casey's, a terceira maior rede de lojas de conveniência dos Estados Unidos, migrou seu ambiente de análise do Synapse para o Databricks Lakehouse (antigo Databricks SQL), reduzindo o tempo de entrega de dados operacionais de oito para quatro horas. Outro exemplo é a Italgas, que simplificou sua arquitetura removendo tanto o Synapse quanto o Azure Analysis Services. A empresa relatou uma redução de 73% nos custos de carga de trabalho, ao mesmo tempo em que atende tanto ao Power BI quanto a análises baseadas em AI diretamente do Databricks.

Embora os detalhes variem de organização para organização, o padrão permanece consistente: arquiteturas mais simples, entrega de dados mais rápida e uma plataforma mais alinhada com as demandas impostas às equipes de dados modernas.

Entendendo o que você realmente está migrando

Uma coisa que costuma pegar as equipes de surpresa no início de uma migração do Synapse é o escopo do que estão movendo. Embora o Azure Synapse seja frequentemente considerado uma única plataforma, na prática ele compreende uma variedade de serviços distintos operando sob uma mesma marca, e cada um deles pode exigir diferentes estratégias de migração e apresentar um nível diferente de complexidade.

A maioria das migrações consome a maior parte do esforço nos Dedicated SQL Pools, onde a lógica de negócios, stored procedures, estratégias de distribuição, decisões de indexação e otimizações de desempenho se acumularam ao longo dos anos. Mas a complexidade raramente para no SQL. A mesma migração geralmente precisa dar conta da orquestração (Azure Data Factory e Synapse Pipelines), permissões e governança (permissões SQL mais Microsoft Purview, com a linhagem de dados frequentemente conectada de forma manual) e conectividade com BI e terceiros (modelos semânticos, relatórios e ferramentas downstream conectadas diretamente aos endpoints do Synapse). Esta é a parte do ambiente que exige mais redesenho, testes e validação — e a parte com maior probabilidade de ser subestimada.

Os Serverless SQL Pools geralmente são mais simples, pois fornecem principalmente uma camada de consulta sobre arquivos em um data lake. A migração aqui consiste basicamente em restabelecer views, tabelas externas e padrões de acesso, em vez de redesenhar cargas de trabalho complexas. Os Spark Pools são o componente mais simples de mover, já que o Synapse Spark e o Databricks são ambos baseados no Apache Spark, e os notebooks geralmente podem ser migrados com pouquíssimas alterações.

O ponto importante é que esses componentes se movem em velocidades diferentes, envolvem diferentes partes interessadas e apresentam riscos distintos. As organizações que abordam a migração como um único fluxo de trabalho com um único cronograma costumam subestimar tanto o esforço quanto a complexidade. É aí que os prazos começam a estourar e os programas de migração começam a se expandir além do escopo original. Para migrar com sucesso, as equipes devem estruturar a jornada de migração.

Como estruturar a migração

Uma migração do Synapse para o Databricks não é um único fluxo de trabalho. Você está movendo três modelos de computação diferentes, consolidando a governança, modernizando a orquestração e retrabalhando anos de lógica T-SQL acumulada. As equipes que lidam bem com isso tratam o processo como um programa estruturado, em vez de um projeto técnico com abordagem em fases.

Descoberta (Discovery). Toda migração começa com a compreensão do que realmente está em execução. O Lakebridge Profiler varre o ambiente do Synapse e coleta metadados sobre configuração, utilização de recursos, padrões de consulta e baselines de desempenho. O resultado é usado para criar um caso de TCO.

Avaliação (Assessment). Uma vez feito o inventário, o próximo passo é entender a complexidade. O Lakebridge Analyzer avalia a base de código T-SQL, classificando cada objeto por complexidade, sinalizando construções não suportadas e mapeando dependências. O resultado pode ser usado para avaliar o cronograma de migração e os esforços associados, bem como para definir a prioridade das migrações de ativos. Comece com as cargas de trabalho de baixa e média complexidade como metas fáceis de alcançar (low-hanging fruits) e planeje o esforço posterior para os casos de uso mais críticos.

Design. Com a visibilidade do ambiente, a atenção se volta para a arquitetura e o design. A primeira decisão é a abordagem: lift-and-shift, modernização ou híbrida. Para a maioria das migrações do Synapse, a híbrida é a resposta certa. Ferramentas automatizadas lidam com a maior parte da conversão de código para sair do Synapse dentro do prazo, enquanto a modernização acontece de forma incremental assim que as cargas de trabalho estiverem em execução no Databricks.

A segunda decisão é o sequenciamento. Uma abordagem focada primeiro em BI (BI-first) tende a gerar tração mais rapidamente do que começar pelo ETL. Usando o Lakehouse Federation, você pode expor dados do Synapse por meio do Unity Catalog antes que os pipelines subjacentes tenham sido movidos — e uma maneira prática de começar é carregar primeiro os dados enriquecidos voltados para os negócios (seus data marts) no Databricks e, em seguida, disponibilizá-los diretamente para os usuários de negócios com o Genie para análises em linguagem natural. As partes interessadas de negócios veem o progresso e o valor logo no início, enquanto as equipes de engenharia modernizam o ETL mais complexo por trás disso. Leia nossa publicação no blog para definir a abordagem de migração certa para você.

Piloto. Antes de escalar, a estratégia de migração precisa ser validada de ponta a ponta em uma carga de trabalho real. Escolha um caso de uso de destaque (lighthouse), migre-o desde a ingestão até o consumo e faça a transição para a produção. Um piloto valida a arquitetura, o modelo de governança, os procedimentos de teste e as ferramentas em condições do mundo real, além de gerar ativos reutilizáveis para as próximas etapas.

Migração em ondas. Para a fase de escala, recomenda-se a migração em ondas. Cada onda é projetada para entregar um ganho de negócios visível e estabelece o ciclo de feedback com os usuários finais.

A execução geralmente ocorre em quatro fluxos de trabalho paralelos: ingestão (movimentação de cargas de trabalho do ADF e do Synapse Pipeline para o Lakeflow Connect), transformação (migração de procedimentos T-SQL e lógica de negócios para o Databricks), orquestração (movimentação de cronogramas e dependências para o Databricks Workflows) e consumo (redirecionamento de ferramentas de BI e modelos semânticos para o Databricks SQL Warehouses). Executá-los em paralelo permite que as equipes entreguem valor rapidamente e desativem o Synapse em um cronograma previsível.

O Databricks apoia migrações do Synapse sob vários aspectos: consultoria e entrega de nossa equipe de Forward Deployed Engineering, parceiros Brickbuilder certificados e aceleradores como o Lakebridge, que automatizam o trabalho pesado. O objetivo não é apenas concluir a migração, mas desenvolver as habilidades e o modelo operacional de que a equipe precisa para sustentar a plataforma muito depois do término do projeto.

Ingestão de dados

Antes de converter o código SQL, os dados devem primeiro ser ingeridos no lakehouse. O Databricks oferece várias opções, dependendo dos sistemas de origem e dos requisitos operacionais.

Para muitas origens corporativas comuns, o Lakeflow Connect oferece uma experiência de ingestão gerenciada com conectores integrados e gerenciamento automatizado de pipelines. Ao mesmo tempo, o Databricks é baseado em formatos de armazenamento abertos, permitindo que as organizações usem uma ampla variedade de ferramentas de ingestão de terceiros. Soluções como Fivetran, Airbyte e outras plataformas de ETL/ELT podem ingerir dados diretamente no Delta Lake, permitindo que os clientes se integrem aos ecossistemas de integração de dados existentes em vez de ficarem presos a um único framework de ingestão.

Conversão de código na prática

Com os dados disponíveis no lakehouse, o esforço de migração se concentra na conversão de código, que geralmente é a fase mais complexa da migração. Embora as ferramentas automatizadas lidem com a maior parte da tradução, normalmente cerca de 80% a 90%, o esforço restante é dedicado ao refinamento da lógica procedural e à resolução de padrões que não podem ser traduzidos automaticamente.

Abaixo estão algumas diferenças que você deve observar nas sintaxes do Synapse e do Databricks.

Remoção de diretivas físicas

O padrão de conversão mais comum é a remoção de diretivas de otimização física. Os Dedicated SQL Pools dependem muito de estruturas como distribuição HASH, distribuição ROUND_ROBIN, distribuição REPLICATE e índices columnstore clusterizados. Eles são fundamentais para o ajuste de desempenho do Synapse, mas não têm equivalente direto no Databricks, por isso costumam ser omitidos durante a migração.

Em vez disso, o Databricks conta com otimização de armazenamento e Liquid Clustering para melhorar o desempenho das consultas. O primeiro é gerenciado automaticamente por meio do recurso Predictive Optimization, que realiza continuamente operações de manutenção, como compactação de arquivos, coleta de estatísticas e VACUUM para tabelas Delta. O segundo é fornecido pelo Liquid Clustering, que organiza os dados nas tabelas Delta usando uma ou mais colunas de clusterização para melhorar o desempenho das consultas. No entanto, a seleção das colunas de clusterização ideais depende da compreensão de como os dados são consultados, uma tarefa que costuma ser difícil na prática e muda frequentemente à medida que as cargas de trabalho evoluem. Para reduzir essa carga operacional, o Databricks introduziu o CLUSTER BY AUTO, que identifica automaticamente e refina continuamente as colunas de clusterização com base nos padrões de acesso a consultas observados. Juntos, esses recursos reduzem significativamente a quantidade de ajuste físico manual necessário em comparação com os Dedicated SQL Pools.

As decisões de design físico que consumiam um esforço significativo de engenharia no Synapse são simplesmente descartadas. A plataforma cuida do que antes era manual.

Remapeamento de funções

A maioria das funções T-SQL comumente usadas tem equivalentes diretos no Databricks, e o Lakebridge lida com a grande maioria dos mapeamentos de forma automática.

A origem mais comum de problemas não são os mapeamentos de funções em si, mas as diferenças comportamentais que afetam os resultados de maneiras sutis. A comparação de strings é um bom exemplo. Os Dedicated SQL Pools do Synapse normalmente operam com agrupamentos (collations) insensíveis a maiúsculas e minúsculas (case-insensitive), enquanto o Databricks SQL é sensível a maiúsculas e minúsculas (case-sensitive) por padrão. A lógica que depende implicitamente de correspondências insensíveis a maiúsculas e minúsculas pode retornar resultados diferentes após a migração. Onde for necessário, as comparações devem ser feitas de forma explícita usando LOWER() ou UPPER() em ambos os lados. A conversão de sintaxe geralmente é simples; as diferenças semânticas exigem mais cuidado.

Stored Procedures: migrar primeiro, otimizar depois

Com o suporte nativo a stored procedures no Databricks, a maioria dos procedimentos do Synapse pode ser migrada com sua estrutura geral intacta. Parâmetros, variáveis, lógica condicional e operações DML são todos suportados.

O procedimento em si raramente é o problema. A complexidade está dentro dele: cursores, processamento linha por linha, SQL dinâmico e otimizações de desempenho específicas do Synapse. Esses padrões exigem discernimento, não apenas tradução.

SCD Tipo 2: preservando o histórico com o Delta Lake

As Slowly Changing Dimensions (dimensões de alteração lenta) são uma das áreas em que as implementações do Synapse mais variam. Muitas organizações acumularam stored procedures personalizadas e lógica de merge ao longo dos anos. O objetivo da migração não é reproduzir essa implementação exatamente, mas preservar o requisito de negócios: manter as versões históricas dos registros de dimensão e, ao mesmo tempo, manter o estado atual consultável.

Uma abordagem comum do Databricks usa duas etapas. Primeiro, expirar os registros que foram alterados. Depois, inserir as novas versões.

As transações ACID do Delta Lake tornam esse padrão seguro, mesmo quando várias operações estão envolvidas.

Tratamento de erros

Muitas stored procedures do Synapse dependem de blocos TRY...CATCH para capturar falhas ou gravar registros de auditoria. O Databricks SQL oferece equivalentes nativos por meio de manipuladores de condições, de modo que a maioria dos padrões existentes pode continuar baseada em SQL.

Cenários simples, como log de auditoria e falhas controladas, normalmente são traduzidos diretamente. Fluxos de trabalho mais complexos podem exigir design adicional, especialmente quando há coordenação downstream por meio do Databricks Workflows envolvida.

O que a experiência prática ensina

Algumas lições surgem de forma consistente nas migrações do Synapse, independentemente do tamanho da organização ou da complexidade do ambiente.

Comece com a avaliação, não com a conversão. Execute o Lakebridge Profiler and Analyzer antes de escrever uma única linha de código convertido. Tenha clareza sobre o uso real, escopo, complexidade e dependências — e use esses dados para reduzir o escopo onde for possível.

Automatize agressivamente. O Lakebridge lida com 80% a 90% da conversão de código. Concentre o tempo de engenharia nos 10% a 20% que exigem julgamento humano — cursores, SQL dinâmico e tratamento de erros complexo.

Nunca subestime a validação. Na prática, a validação geralmente consome mais esforço do que a própria migração. A abordagem mais eficaz é executar a reconciliação após cada onda de migração, comparando a contagem de linhas, agregações, comparações de registros baseadas em hash e verificações baseadas em tolerância para valores em que a igualdade exata não é apropriada. O Lakebridge Reconcile oferece suporte para isso em todas essas dimensões. Para cargas de trabalho críticas para os negócios, executar ambos os ambientes em paralelo antes da transição final permite que as equipes comparem os resultados lado a lado enquanto os usuários continuam trabalhando com relatórios familiares.

Evite o pensamento moldado pelo Synapse. Um bom exemplo é o design de tabelas. As equipes frequentemente tentam mapear as chaves de distribuição HASH do Synapse diretamente para as colunas de partição do Delta Lake. Na maioria dos casos, isso introduz complexidade desnecessária e características de baixo desempenho. Valores de alta cardinalidade, como IDs de clientes ou IDs de pedidos, raramente são chaves de partição adequadas e geralmente são melhor gerenciados por meio de liquid clustering e dos recursos de otimização automatizados do Databricks, como a manutenção preditiva.

Não recrie o que a plataforma agora gerencia. As migrações criam uma oportunidade para simplificar as arquiteturas em vez de reproduzi-las exatamente. O Delta Lake, a otimização automatizada e os padrões modernos de lakehouse eliminam muitas das técnicas de ajuste manual que eram necessárias em ambientes de data warehouse tradicionais. Levar cada decisão histórica de otimização para o Databricks muitas vezes preserva restrições antigas sem preservar os motivos pelos quais essas restrições existiam.

Prepare a prontidão operacional. As tabelas Delta acumulam naturalmente arquivos pequenos à medida que as cargas de trabalho incrementais são executadas ao longo do tempo. Sem processos de compactação e manutenção, o desempenho pode se degradar gradualmente. As equipes vindas de plataformas tradicionais de data warehouse geralmente se surpreendem com o fato de a otimização de armazenamento se tornar parte do modelo operacional contínuo. Não é difícil de gerenciar, mas precisa ser planejado desde o início.

Planeje a gestão de mudanças. A maioria das equipes do Synapse é nova no Databricks, e o subinvestimento em capacitação é um dos motivos mais comuns para os projetos não atingirem as metas de adoção. Trabalhe no plano de capacitação com a mesma seriedade que no plano técnico.

Evite a desativação precoce do Synapse. A maioria das migrações bem-sucedidas mantém o ambiente legado disponível por um período após a migração das cargas de trabalho de produção. Os recursos de computação podem ser pausados para minimizar os custos, mantendo uma opção de rollback caso surjam problemas inesperados. Mais importante ainda, manter essa rede de segurança dá confiança às partes interessadas do negócio enquanto a nova plataforma se comprova no uso real.

Migrar do Synapse para o Databricks raramente é apenas um projeto de tecnologia. Em sua essência, envolve simplificar uma plataforma que se tornou cada vez mais complexa ao longo do tempo, ao mesmo tempo em que estabelece uma base que pode dar suporte à próxima geração de produtos de análise, AI e dados. Embora o trabalho técnico seja importante, as organizações que mais se beneficiam dessas migrações são aquelas que aproveitam a oportunidade para simplificar sua arquitetura, eliminar a complexidade desnecessária e modernizar suas práticas operacionais simultaneamente. O maior benefício é acabar com uma plataforma de dados mais simples de operar, mais fácil de estender e melhor alinhada com a direção futura da organização.

O que fazer a seguir

Se você está no início de uma migração do Synapse:

• Execute o Lakebridge Profiler and Analyzer no seu ambiente. Obtenha os dados antes de definir o escopo do trabalho.
• Leia o blog Migration Strategy: Lessons Learned e o eBook Transforming Legacy Data Warehouses.
• Se precisar de ajuda prática, a Databricks FDE Team e os parceiros de migração certificados realizam migrações do Synapse de ponta a ponta.

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