Guia de migração do Databricks para o Snowflake¶
Estrutura de migração do Snowflake¶

Uma migração típica do Databricks para o Snowflake pode ser dividida em cinco etapas principais:
Planejamento e design são etapas muitas vezes negligenciadas no processo de migração. O principal motivo é que as empresas geralmente querem mostrar progresso rapidamente, mesmo que não tenham compreendido totalmente o escopo do projeto. Por isso, esta fase é crucial para entender e priorizar o projeto de migração.
Ambiente e segurança: com um plano, um cronograma claro, uma matriz RACI e a aprovação de todas as partes interessadas, é hora de passar para o modo de execução. Configurar os ambientes e as medidas de segurança necessárias para iniciar a migração é muito importante antes de começar a fase de migração, visto que há muitas partes envolvidas, e será mais impactante para o projeto de migração se toda a sua configuração estiver pronta antes de prosseguir.
O processo de conversão do código do banco de dados envolve a extração do código diretamente do catálogo do banco de dados dos sistemas de origem, como definições de tabelas, exibições, procedimentos armazenados e funções. Depois da extração, você migra todo esse código para linguagens de definição de dados (DDLs) equivalentes no Snowflake. Esta etapa também inclui a migração de scripts de linguagem de manipulação de dados (DML), que podem ser utilizados por analistas de negócios para criar relatórios ou painéis. Todo esse código precisa ser migrado e ajustado para funcionar no Snowflake. Os ajustes podem variar de mudanças simples, como convenções de nomenclatura e mapeamentos de tipos de dados, a diferenças mais complexas em sintaxe, semântica da plataforma e outros fatores. Para auxiliar nesse processo, o Snowflake oferece uma solução poderosa chamada SnowConvert AI, que automatiza grande parte do processo de conversão do código do banco de dados.
Migração de dados: a migração de dados envolve a transferência de dados entre diferentes sistemas de armazenamento, formatos ou sistemas de computador. No contexto de uma migração do Databricks para o Snowflake, ela se refere especificamente à movimentação de dados do seu ambiente Databricks para o seu novo ambiente Snowflake.
Há dois tipos principais discutidos neste guia:
Migração histórica de dados: tirar um instantâneo dos seus dados do Databricks em um ponto específico no tempo e transferi-lo para o Snowflake. Isso geralmente é feito como uma transferência inicial em massa.
Migração incremental de dados: mover dados novos ou alterados do Databricks para o Snowflake de maneira contínua após a migração histórica inicial. Isso garante que seu ambiente Snowflake permaneça atualizado com seus sistemas de origem.
Ingestão de dados: depois de você migrar os dados históricos, a próxima etapa é migrar o processo de ingestão de dados, apresentando dados em tempo real de várias fontes. Normalmente, esse processo segue um modelo de extração, transformação e carregamento (ETL) ou extração, carregamento e transformação (ELT), dependendo de quando e onde a transformação de dados ocorre antes de ficar disponível para os usuários de negócios.
Relatórios e análises, agora que o banco de dados tem dados históricos e pipelines ativos que importam continuamente novos dados, a próxima etapa é extrair valor desses dados por meio de BI. É possível fazer os relatórios usando ferramentas BI padrão ou consultas personalizadas. Em ambos os casos, o SQL enviado para o banco de dados pode precisar ser ajustado para atender aos requisitos do Snowflake. Esses ajustes podem variar de simples alterações de nome (comuns durante a migração) a diferenças de sintaxe e semânticas mais complexas. Tudo isso precisa ser identificado e abordado.
Validação e testes de dados: o objetivo é ter a maior limpeza de dados possível antes de entrar nesta fase. Cada organização tem suas próprias metodologias e requisitos de teste para mover dados para produção. Eles devem ficar totalmente compreendidos desde o início do projeto.
Implantação: nesta etapa, os dados são validados, um sistema equivalente é configurado, todos os ETLs foram migrados e os relatórios foram verificados. Tudo pronto para entrar em produção? Espere um pouco; ainda há algumas considerações críticas antes da promoção final para produção. Primeiro, seu aplicativo legado pode consistir em vários componentes ou serviços. O ideal é migrar esses aplicativos um por um (embora a migração paralela seja possível) e promovê-los para produção na mesma ordem. Durante esse processo, certifique-se de que sua estratégia de transição esteja em vigor para que os usuários comerciais não tenham que consultar o Snowflake e o sistema legado. A sincronização de dados para aplicativos que ainda não foram migrados deve ocorrer em segundo plano por meio do mecanismo de transição. Se isso não for feito, os usuários empresariais terão que trabalhar em um ambiente híbrido e devem entender as implicações dessa configuração.
Otimizar e executar: após a migração de um sistema para o Snowflake, ele entra no modo de manutenção normal. Todos os sistemas de software são organismos vivos que exigem manutenção contínua. Essa fase, após a migração, é chamada de otimização e execução e não faz parte da migração em si.
¶
Fases principais¶
Uma migração típica do Databricks para o Snowflake pode ser dividida em várias fases principais, cada uma com objetivos e considerações distintos. Seguir essas fases ajudará a garantir uma transição estruturada e bem-sucedida.
Fase 1: Planejamento e projeto¶
Esta fase inicial é crucial para uma migração bem-sucedida. Ela estabelece as bases definindo o escopo, os objetivos e os requisitos do seu projeto. Envolve uma compreensão profunda do seu ambiente Databricks atual e uma visão clara do estado futuro no Snowflake.
Suas etapas práticas:¶
Realize uma avaliação completa do seu ambiente Databricks: isso envolve mais do que apenas um inventário técnico; é um exercício estratégico para identificar «dívidas técnicas» e descobrir oportunidades para modernizar e simplificar o ambiente de dados.
Inventário de ativos de dados existentes: identifique e documente meticulosamente todos os ativos do Databricks, incluindo bancos de dados, tabelas (especialmente tabelas Delta Lake), exibições, notebooks (categorizados por linguagem: Python, Scala, SQL), trabalhos, fluxos de trabalho, funções definidas pelo usuário (UDFs) e integrações externas.
Analise as cargas de trabalho de consultas: utilize as ferramentas de monitoramento e os logs do Databricks para identificar consultas executadas com frequência e que consomem muitos recursos. Essas consultas serão cruciais para a validação de desempenho pós-migração.
Categorize ativos de dados: faça a distinção entre dados de produção e não produção, identifique objetos ativos e obsoletos e aponte todos os ativos redundantes que possam ser excluídos da migração. Isso reduz significativamente o volume de dados e código a serem migrados, economizando esforço, tempo e custos.
Avalie requisitos de segurança e conformidade: identifique dados confidenciais, obrigações regulatórias (por exemplo, GDPR, HIPAA) e vulnerabilidades potenciais no ambiente Databricks existente. Essas informações são cruciais para projetar uma configuração de segurança robusta no Snowflake.
Defina métricas de sucesso e objetivos de migração claros: ignorar a definição precisa desses objetivos pode levar a mudanças constantes de metas e ao fracasso do projeto.
Articule os fatores estratégicos: defina claramente os fatores que impulsionam os negócios (por exemplo, redução de custos, melhoria do desempenho de BI, operações simplificadas, governança aprimorada) e os objetivos técnicos para a migração para o Snowflake.
Estabeleça métricas de sucesso mensuráveis: defina métricas quantificáveis para acompanhar o progresso e demonstrar ROI, como melhorias no desempenho de consultas (por exemplo, latência média de consulta reduzida em X%), economia de custos demonstrável (por exemplo, redução de Y% nos gastos mensais com nuvem), uma diminuição mensurável em incidentes operacionais, aumento nos índices de satisfação do usuário e precisão de dados verificada.
Escolha sua abordagem de migração: em fases ou de uma só vez: a seleção de uma estratégia de migração é fundamentalmente uma decisão de gerenciamento de riscos.
Migração em fases: essa abordagem envolve a movimentação de dados e cargas de trabalho em segmentos menores e gerenciáveis (por área temática, data mart, unidade de negócios ou aplicativo). É altamente recomendada para manter tempo de inatividade zero ou mínimo, permitindo testes contínuos, aprendizado iterativo e transferência gradual de cargas de trabalho. Essa abordagem facilita execuções paralelas para validação completa.
Migração de uma só vez: essa abordagem envolve a migração de todos os dados e cargas de trabalho de uma só vez, seguida por uma transição imediata. Embora potencialmente mais rápida para sistemas muito simples, ela acarreta um alto risco de problemas imprevistos e geralmente é menos segura para manter tempo de inatividade zero.
Estabeleça uma estrutura robusta de preparação para a migração: o envolvimento precoce e contínuo de todas as partes interessadas é fundamental.
Realize uma avaliação formal de preparação para a migração (MRA): envolva uma equipe multifuncional de especialistas (conversão de código, migração de dados, ingestão de dados, validação de dados, relatórios e análises) e representantes tanto da área comercial quanto da técnica.
Desenvolva um cronograma detalhado do projeto e uma matriz RACI: garanta a clareza das funções e responsabilidades para todas as tarefas de migração.
Consiga adesão explícita:** obtenha a adesão de todas as principais partes interessadas, incluindo a liderança executiva e os usuários empresariais, desde o início. Uma migração tecnicamente perfeita ainda poderá falhar se os usuários empresariais não estiverem adequadamente preparados, treinados ou envolvidos.
Fase 2: Ambiente e segurança¶
Configurar os ambientes e as medidas de segurança necessárias é uma etapa inicial crítica antes de iniciar a migração. O Snowflake opera sob um modelo de segurança compartilhada entre a plataforma e os administradores.
Suas etapas práticas:
Configure os ambientes: decida o número de contas Snowflake necessárias. No mínimo, configure um ambiente de produção e um de desenvolvimento. Com base na sua estratégia, considere ambientes adicionais para diferentes áreas de preparação de testes.
Implemente medidas de segurança:
Comece com políticas de rede para garantir que apenas usuários autorizados dentro da sua VPN possam acessar o sistema Snowflake.
Defina funções com base nas necessidades de negócios, já que o controle de acesso de usuários do Snowflake é baseado em funções.
Crie contas de usuário e aplique autenticação multifator (MFA) e/ou login único (SSO) para todos os usuários.
Configure contas de serviço sem depender da autenticação tradicional com nome de usuário/senha.
Defina funções durante a migração: defina funções específicas para sua equipe de migração. Mesmo em ambientes que não são de produção, em que a equipe pode ter mais liberdade, lembre-se de que você estará lidando com dados reais; portanto, mantenha uma segurança robusta.
Repense seu modelo de acesso: use essa migração para limpar e otimizar sua hierarquia de acesso, garantindo que apenas os usuários necessários tenham acesso a recursos específicos.
Coordene com o departamento financeiro: alinhe-se com sua equipe financeira para acompanhar o uso do Snowflake por departamento, utilizando o modelo de preços baseado no consumo e a marcação de objetos do Snowflake para alocação de custos.
Fase 3: Conversão do código do banco de dados¶
Esta fase se concentra na conversão do código de banco de dados do Databricks (código Spark, DDL, SQL) para o SQL e Snowpark compatíveis com o Snowflake.
Suas etapas práticas:
Mapeie os tipos de dados Spark do Databricks para os tipos de dados do Snowflake:
Identifique e mapeie cuidadosamente os tipos de dados do Databricks (Spark) para os equivalentes Snowflake mais apropriados. Preste muita atenção à precisão, escala e tratamento de fusos horários para tipos complexos (por exemplo, TimestampType para TIMESTAMP_NTZ, TIMESTAMP_LTZ ou TIMESTAMP_TZ).
Lembre-se de que ByteType corresponde a INTEGER do Snowflake e que LongType (64 bits) para INTEGER (32 bits) pode exigir verificações de intervalo para evitar truncamento.
ArrayType e MapType geralmente correspondem ao tipo de dados VARIANT do Snowflake.
** Traduza a linguagem de definição de dados (DDL) para tabelas e exibições:**
Extraia os scripts DDL existentes do seu ambiente Databricks, normalmente de tabelas Delta Lake.
Ajuste o DDL extraído para total compatibilidade com o dialeto SQL do Snowflake, removendo ou reestruturando recursos específicos do Databricks (por exemplo, propriedades de tabelas Delta Lake, esquemas de particionamento específicos além das chaves de clustering).
Considere as oportunidades para reorganização de esquemas, como dividir esquemas grandes em vários bancos de dados ou esquemas do Snowflake para melhor separação lógica e controle de acesso.
Converta código Databricks SQL e Spark para Snowflake SQL e Snowpark:
Databricks SQL para Snowflake SQL: o Snowconvert AI agora oferece suporte à avaliação e tradução do Spark SQL e do Databricks SQL para TABLES e VIEWS.
Código Spark (PySpark/Scala) para Snowpark: converta código PySpark ou Scala de notebooks e trabalhos do Databricks para a API do Snowpark do Snowflake (Python, Java, Scala). O Snowpark DataFrames oferece funcionalidades semelhantes ao Spark DataFrames (filtrar, selecionar, unir, agrupar, agregar), com o objetivo de trazer a lógica de processamento diretamente para os dados dentro do Snowflake.
Funções definidas pelo usuário (UDFs): reimplemente as UDFs do Databricks (Python, Scala) como UDFs do Snowflake (SQL, JavaScript, Python, Java, Scala). UDFs complexas do Spark podem exigir uma reengenharia significativa para aproveitar o Snowflake de modo eficaz.
Lógica de orquestração: reformule e reimplemente a lógica de orquestração de trabalhos, fluxos de trabalho e Delta Live Tables (DLT) do Databricks no Snowflake, usando recursos nativos como Streams e Tasks para transformações incrementais e agendamento. Como alternativa, redirecione orquestradores externos (por exemplo, Airflow) para o Snowflake, reescrevendo qualquer código específico do Databricks incorporado.
Fase 4: Migração de dados¶
A migração de dados é o processo de transferência de conjuntos de dados existentes do ambiente Databricks para o Snowflake. Essa fase normalmente envolve tanto a transferência de dados históricos em massa quanto a ingestão incremental contínua de dados.
Suas etapas práticas:
Extraia dados do Databricks:
Para tabelas do Delta Lake, gere arquivos de manifesto usando o Apache Spark, que apontam para os arquivos de dados Parquet subjacentes que o Snowflake pode ler diretamente.
Para tabelas grandes, particione as exportações de dados para ter um processamento paralelo eficiente.
Utilize o conector Snowflake nativo do Databricks para ler dados diretamente do Databricks e gravá-los no armazenamento em nuvem (por exemplo, AWS S3, Azure Blob Storage) como uma área de preparação para o Snowflake.
Adicione uma coluna de carimbo de data/hora para o horário de ingestão e uma coluna com o nome do sistema de origem para manter a linhagem e o controle no Snowflake.
Carregue dados no Snowflake:
Use o comando COPY INTO do Snowflake para carregar dados em massa de áreas de preparação externas (locais de armazenamento em nuvem) para tabelas do Snowflake.
Para ter o melhor desempenho com arquivos Parquet, use o scanner vetorizado do Snowflake (defina USE_VECTORIZED_SCANNER no comando COPY ou espere que ele seja o padrão no futuro).
Práticas recomendadas para carregamento:
Otimização do tamanho do arquivo: crie arquivos no intervalo de 100-250MB com compressão (por exemplo, Snappy para Parquet) para garantir uma taxa de transferência ideal.
Remoção de arquivos preparados: use PURGE=TRUE no comando COPY para remover arquivos da área de preparação após o carregamento bem-sucedido, otimizando o desempenho e gerenciando os custos de armazenamento.
Tratamento de erros: use ON_ERROR=”CONTINUE” no comando COPY para arquivos grandes com dados potencialmente incorretos, permitindo que os dados corretos sejam carregados enquanto as linhas problemáticas são ignoradas.
Áreas de preparação internas: considere usar áreas de preparação internas do Snowflake para ter um carregamento mais rápido em comparação com áreas de preparação externas, mas compare os custos de armazenamento.
Para carregamento incremental de dados, implemente pipelines de captura de dados de alteração (CDC) para replicar dados novos ou alterados do Databricks para o Snowflake. Ferramentas como Fivetran ou Matillion podem automatizar essas sincronizações.
Fase 5: Ingestão de dados¶
Esta fase se concentra na migração dos processos contínuos de ingestão de dados e pipelines ETL/ELT do Databricks para o Snowflake, garantindo um fluxo contínuo de dados em tempo real.
Suas etapas práticas:
Reestruturar fluxos de trabalho ETL/ELT do Databricks:
Reestruture os fluxos de trabalho ETL/ELT do Databricks (geralmente criados usando PySpark, Scala ou SQL com Delta Live Tables [DLT] ou trabalhos do Databricks) para o Snowflake.
Para ETL/ELT complexos, converta o código Spark para DataFrames e UDFs do Snowpark (conforme discutido na Fase 1). Para transformações baseadas em SQL, considere a dbt (ferramenta de construção de dados) para transformações dentro do Snowflake.
Aproveite os recursos nativos do Snowflake:
Use fluxos para registrar alterações do DML para processamento incremental e tarefas para agendar instruções SQL ou procedimentos armazenados para transformações incrementais e orquestração diretamente no Snowflake.
Snowpipe: para carregamento contínuo e em tempo real de novos dados, use o Snowpipe para fluxos contínuos de dados. Para carregamento em lote, o comando COPY continua sendo uma opção poderosa.
Snowpipe Streaming: ideal para casos de uso de streaming de baixa latência.
Realinhe fontes e destinos de dados:
Redirecione várias fontes de dados de entrada que atualmente chegam ao Databricks para padrões de ingestão do Snowflake, configurando conectores ou processos de ingestão personalizados para apontar diretamente para tabelas ou áreas de preparação do Snowflake.
Desenvolva um plano para redirecionar os sistemas downstream (por exemplo, ferramentas de BI, outros aplicativos) que atualmente leem do Databricks para o Snowflake assim que os pipelines de dados estiverem estabilizados e a validação de dados estiver concluída.
Fase 6: Transição de relatórios e análises¶
Esta fase concentra-se em garantir que as ferramentas de Business Intelligence (BI) e de análise continuem a funcionar corretamente e de maneira otimizada com o Snowflake como a nova fonte de dados.
Suas etapas práticas:
Ajuste ferramentas de BI e consultas personalizadas:
Redirecione ou refatore as ferramentas de relatório existentes (por exemplo, Tableau, Power BI, Looker) e ajuste as consultas personalizadas que eram executadas anteriormente no Databricks.
Ajuste as consultas SQL enviadas ao banco de dados para os requisitos do Snowflake, que podem variar desde simples alterações de nome até diferenças semânticas e de sintaxe mais complexas.
Envolva usuários empresariais e forneça treinamento:
Inclua os usuários empresariais como principais partes interessadas no processo de migração (por exemplo, na matriz RACI durante o planejamento). A aceitação deles é crucial para uma transição completa da plataforma legada.
Treine os usuários empresariais sobre como o Snowflake opera e garanta que eles compreendam claramente as diferenças entre as plataformas. Isso permitirá que eles modifiquem as consultas e os relatórios personalizados conforme necessário.
Considere um programa de treinamento paralelo para usuários empresariais, seguido de um horário de atendimento com especialistas em migração, para ajudar a lidar com as diferenças entre as plataformas e orientar os usuários nos ajustes necessários.
Fase 7: Validação e testes de dados¶
A validação e os testes de dados são etapas muitas vezes subestimadas no processo de planejamento de migração, mas são essenciais para garantir a integridade e a precisão dos dados no novo ambiente Snowflake. O objetivo é ter a maior limpeza de dados possível antes de entrar nesta fase.
Suas etapas práticas:
Conduza estratégias de testes abrangentes: cada organização tem as próprias metodologias e requisitos de teste para mover dados para produção, que devem ser totalmente compreendidos desde o início do projeto.
Testes funcionais: verifique se todos os aplicativos e funcionalidades migrados funcionam conforme o esperado no novo ambiente, garantindo a integridade e a precisão dos dados. Isso inclui verificar se os ETLs e relatórios migrados produzem resultados corretos.
Testes de desempenho: avalie o desempenho das consultas, a velocidade de carregamento de dados e a capacidade de resposta geral do sistema. Isso ajuda a identificar e solucionar os gargalos de desempenho no Snowflake, garantindo que a nova plataforma atenda ou ultrapasse as expectativas de desempenho.
Teste de aceitação do usuário (UAT): envolva os usuários finais no processo de teste para garantir que o sistema migrado atenda aos requisitos de negócios deles e colete feedback para identificar oportunidades de melhoria. Isso é crucial para conseguir a confiança e a adoção dos usuários.
Técnicas de validação de dados: compare contagens de linhas, calcule somas, máximos, mínimos e médias das colunas e gere hashes dos valores das linhas para associação individual entre os sistemas de origem (Databricks) e destino (Snowflake). A execução de sistemas em paralelo por um período permite a comparação em tempo real.
Forneça treinamento e documentação:
Ofereça treinamento completo aos usuários finais sobre os recursos, funcionalidades e melhores práticas do Snowflake, abordando tópicos como acesso a dados, otimização de consultas e segurança.
Crie uma documentação abrangente, incluindo diagramas de arquitetura do sistema, diagramas de fluxo de dados, procedimentos operacionais, guias do usuário, guias de solução de problemas e FAQs para garantir fácil consulta e suporte contínuo.
Fase 8: Implantação \– Entrada em produção¶
Esta etapa envolve considerações críticas antes da promoção final para produção, garantindo uma transição tranquila e coordenada.
Suas etapas práticas:
Planeje a implantação em fases e a estratégia de integração:
O ideal é migrar os aplicativos legados um a um e promovê-los para produção na mesma ordem.
Garanta que uma estratégia de transição esteja em vigor para que os usuários empresariais não precisem consultar o Snowflake e o sistema Databricks legado. A sincronização de dados para aplicativos ainda não migrados deve ocorrer em segundo plano por meio desse mecanismo.
Assegure o alinhamento das partes interessadas e as aprovações formais:
Quando tudo estiver pronto para a migração, assegure-se de que todas as partes interessadas estejam alinhadas e compreendam que o Snowflake será o sistema de registro, e não a plataforma Databricks legada.
Obtenha as aprovações finais e formais de todas as partes interessadas antes de prosseguir.
Enfatize que quaisquer relatórios não migrados agora são de responsabilidade dos usuários empresariais, destacando a importância do envolvimento precoce dos usuários.
Verifique se todas as permissões foram concedidas corretamente no Snowflake, incluindo quaisquer funções baseadas no Active Directory.
Considere os pontos críticos para a migração:
Chaves alternativas: se você utilizar chaves alternativas, esteja ciente de que o ciclo de vida delas pode ser diferente entre os sistemas legados e o Snowflake; essas chaves precisam ser sincronizadas durante a migração.
Cronograma da migração:** considere o cronograma ideal para a migração com base no seu setor para minimizar o impacto nos negócios.
Desativação da plataforma legada:** planeje a desativação do ambiente Databricks legado, incluindo considerações sobre licenciamento da plataforma legada e políticas de retenção de dados.
Fase 9: Otimização e execução \– Melhoria contínua¶
Após a migração para o Snowflake, o sistema entra em modo de manutenção normal. Esta fase, denominada «Otimização e execução», não faz parte da migração em si, mas concentra-se na otimização contínua e na melhoria constante.
Suas etapas práticas:
Foco na otimização contínua e no gerenciamento de custos:
A equipe assume total responsabilidade pelo sistema no Snowflake, com a otimização orientada pelos padrões de uso.
Embora os trabalhos no Snowflake geralmente sejam executados mais rapidamente, se o desempenho não atender às expectativas, otimizações podem ser necessárias para aproveitar ao máximo a arquitetura exclusiva do Snowflake.
Utilize as ferramentas de análise de consultas do Snowflake para identificar gargalos e otimizar partes específicas do fluxo de trabalho.
Aborde apenas os problemas críticos de desempenho durante a migração, tratando a otimização mais ampla como um esforço pós-migração.
Implemente o gerenciamento contínuo de custos:
Defina os tempos limite de suspensão automática para warehouses virtuais em 60 segundos para reduzir significativamente os custos, já que o Snowflake cobra por cada segundo em que um warehouse está em execução, com um mínimo de 60 segundos por retomada.
Reduza os tamanhos dos warehouses virtuais com base nos requisitos de carga de trabalho, pois os recursos computacionais e os custos aumentam exponencialmente com o tamanho do warehouse.
Monitore continuamente os padrões de uso e coordene com o departamento financeiro para rastrear o uso departamental para alocação de custos.
Aprimore a governança e a segurança:
Refine o controle de acesso baseado em funções, implemente políticas de acesso a linhas e mascaramento dinâmico de dados para dados confidenciais e audite regularmente os padrões de acesso.
Repense o modelo de acesso para limpar a hierarquia de usuários e garantir que apenas os usuários necessários tenham acesso a recursos específicos.