Guia de migração do Teradata para o Snowflake¶

Fase 1: Planejamento e projeto¶

Esta fase é o primeiro passo crucial para uma migração bem-sucedida para o Snowflake. Ela estabelece as bases para todo o processo de migração, definindo o escopo, os objetivos e os requisitos. Esta fase envolve uma compreensão profunda do ambiente atual e uma visão clara do estado futuro no Snowflake.

Durante esta fase, as organizações identificam os principais impulsionadores comerciais e objetivos técnicos para migrar para o Snowflake executando as seguintes tarefas:

Fase 2: Ambiente e segurança¶

Uma das primeiras etapas que recomendamos é configurar os ambientes e as medidas de segurança necessárias para iniciar a migração. Há muitas partes envolvidas, então vamos começar com a segurança. Como em qualquer plataforma de nuvem, o Snowflake opera sob um modelo de segurança compartilhada entre a plataforma e os administradores.

Fase 3: Conversão do código do banco de dados¶

O SnowConvert AI entende o código-fonte do Teradata e converte a linguagem de definição de dados (DDL), a linguagem de manipulação de dados (DML) e as funções no código-fonte para o SQL correspondente no destino: o Snowflake. O SnowConvert AI pode migrar o código-fonte em qualquer uma destas três extensões: .sql, .dml, .ddl.

Esta fase 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.

Consulte nossos scripts de extração recomendados aqui.

A DDL do Teradata normalmente inclui referências a índices primários, fallback ou particionamento. No Snowflake, essas estruturas não existem da mesma forma:

• Use o SnowConvert AI for Teradata que simplifica significativamente o processo de conversão da linguagem de definição de dados (DDL), especialmente ao lidar com várias tabelas. Ele automatiza a tradução de construções de DDL específicas do Teradata, como definições de índice primário e opções de fallback, em estruturas equivalentes do Snowflake. Essa automação reduz o esforço manual e minimiza o risco de erros, permitindo que as equipes se concentrem em tarefas estratégicas de migração e validação. Além da conversão básica de DDLs, o SnowConvert AI também aborda nuances como mapeamento de tipo de dados e reorganização de esquemas. Ele pode ajustar automaticamente os tipos de dados para se alinharem às ofertas do Snowflake e facilitar as decisões sobre consolidar ou dividir esquemas para obter desempenho e gerenciamento ideais. Essa abordagem abrangente garante que a estrutura do banco de dados migrado não seja apenas funcional, mas também otimizada para a arquitetura do Snowflake.

• Ajuste os tipos de dados conforme necessário ou use o assistente de AI para migrações para corrigir qualquer erro ou aviso (EWI).

• Decida se deseja reorganizar os esquemas (por exemplo, dividindo grandes esquemas monolíticos em vários bancos de dados Snowflake).

Fase 4: Migração de dados¶

Primeiro, é importante diferenciar entre migração histórica de dados e adição de novos dados. A migração histórica de dados refere-se à captura de um instantâneo dos dados em um ponto específico no tempo e a transferência dele para o Snowflake. Nossa recomendação é realizar primeiro uma cópia exata dos dados, sem qualquer transformação, no Snowflake. Essa cópia inicial exigirá processamento da plataforma legada; portanto, é recomendável fazer isso apenas uma vez e armazená-la no Snowflake.

Suas etapas práticas:

• Realize a migração histórica de dados: Tire um instantâneo dos seus dados do Teradata em um ponto específico no tempo e transfira-o para o Snowflake, geralmente como uma transferência inicial em massa. A recomendação é realizar uma cópia exata sem transformação inicialmente.

• Planeje a migração de dados incremental: Após a migração histórica inicial, configure processos para mover dados novos ou alterados do Teradata para o Snowflake de forma contínua para manter seu ambiente Snowflake atualizado.

Fase 5: Ingestão de dados¶

A migração do pipeline para o Snowflake envolve mover ou reescrever a lógica baseada em Teradata, como scripts BTEQ, procedimentos armazenados, macros ou fluxos ETL especializados. Isso inclui uma transição de orquestração, que substitui trabalhos BTEQ ou agendados do Teradata por fluxos e tarefas dentro do Snowflake para transformações incrementais. Ele também requer o realinhamento de origem/destino, que redireciona várias fontes de dados de entrada que chegam ao Teradata para padrões de ingestão do Snowflake (COPY, Snowpipe).

Durante o estágio de conversão e otimização de consultas, o Teradata SQL é convertido para o Snowflake SQL, o que pode incluir a substituição de macros por procedimentos armazenados ou exibições, a reescrita da lógica QUALIFY e o ajuste de procedimentos armazenados e índices de junção. O SnowConvert AI para Teradata pode automatizar grande parte dessa tradução.

Com os próprios dados no Snowflake, você agora passa a migrar ou reescrever a lógica baseada em Teradata (scripts BTEQ, procedimentos armazenados, macros ou fluxos ETL especializados).

Fase 6: Relatórios e análises¶

Agora que temos um banco de dados com dados históricos e pipelines ativos importando continuamente novos dados, o próximo passo é extrair valor desses dados por meio de Business Intelligence (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 diferenças semânticas mais complexas. Todas elas precisam ser identificadas e resolvidas.

Assim como no processo de ingestão, é crucial revisar todo o uso da plataformas legadas e incorporar essas descobertas ao plano de migração. Geralmente, há dois tipos de relatórios a serem considerados: de propriedade da IT e de propriedade da empresa. Normalmente, é mais fácil acompanhar relatórios de propriedade da IT; relatórios de propriedade da empresa e consultas complexas criadas por usuários empresariais exigem uma abordagem diferente.

Os usuários empresariais são partes interessadas fundamentais no processo de migração e devem ser incluídos na matriz RACI durante a fase de planejamento. Eles precisam ser treinados sobre como o Snowflake opera e devem compreender claramente as diferenças entre as plataformas. Isso permitirá que eles modifiquem as consultas e os relatórios personalizados conforme necessário. Normalmente, recomendamos um programa de treinamento paralelo para usuários empresariais, seguido de horário de atendimento com especialistas em migração que podem ajudar a lidar com as diferenças entre as plataformas e orientar os usuários nos ajustes necessários.

Os usuários empresariais são, em última análise, os que «aceitam» a migração. Você pode ter concluído a migração técnica do ponto de vista da IT, mas se os usuários empresariais não estiverem envolvidos, eles ainda poderão depender de milhares de relatórios que são cruciais para a operação da empresa. Se esses relatórios não forem atualizados para funcionar com o Snowflake, a empresa não poderá migrar completamente da plataforma legada.

O Teradata SQL tem algumas estruturas que não estão presentes no Snowflake e vice-versa. As principais diferenças incluem:

• Macros: não são compatíveis com o Snowflake; geralmente são substituídas por procedimentos armazenados ou exibições.

• QUALIFY: o Snowflake não é compatível com QUALIFY diretamente; a lógica é reescrita com o uso de uma subconsulta ou de um SELECT externo.

• Procedimentos armazenados: Teradata SP x Snowflake SP (baseado em SQL ou JavaScript). A linguagem procedural é diferente.

• Índices de junção: não têm equivalente direto; dependem da remoção de micropartições e chaves de clustering.

• COLLECT STATISTICS: o Teradata usa estatísticas explícitas, enquanto o Snowflake faz isso automaticamente.

O SnowConvert AI para Teradata é recomendado para tradução automatizada. Ele consegue lidar com macros, procedimentos armazenados e scripts BTEQ, gerando código compatível com o Snowflake.

Fase 7: Validação e testes de dados¶

Isso nos leva às etapas de validação e testes de dados, muitas vezes subestimadas no processo de planejamento de migração. Obviamente, 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. Quais são algumas estratégias úteis para validação de dados?

• Realize testes abrangentes na migração para o Snowflake: durante o processo de migração para o Snowflake, testes abrangentes devem ser realizados, incluindo:

  1. Testes funcionais: para verificar se todos os aplicativos e funcionalidades migrados funcionam conforme o esperado no novo ambiente, garantindo a integridade e a precisão dos dados.

  2. Testes de desempenho: para avaliar o desempenho das consultas, a velocidade de carregamento de dados e a capacidade de resposta geral do sistema, o que ajuda a identificar e solucionar os gargalos de desempenho.

  3. Testes de aceitação do usuário (UAT): Para envolver os usuários finais no processo de teste, garantindo que o sistema migrado atenda aos seus requisitos e colete feedback para identificar oportunidades de melhoria.

• Fornecer treinamento e documentação para a migração para o Snowflake:

  • Forneça treinamento abrangente 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.

Fase 8: Implantação¶

Quando tudo estiver pronto para a migração, certifique-se de que todas as partes interessadas estejam alinhadas e entendam que, a partir deste ponto, o Snowflake será o sistema de registro, e não a plataforma legada. Você precisará das aprovações finais e formais de todas as partes interessadas antes de prosseguir. Todos os relatórios que não foram migrados agora são de responsabilidade dos usuários empresariais. É por isso que é crucial não envolver os usuários no último minuto: eles devem fazer parte do processo desde o início e devem estar cientes do cronograma de migração.

Além disso, verifique se todas as permissões foram concedidas corretamente. Por exemplo, se você estiver usando funções baseadas no Active Directory, certifique-se de que elas sejam criadas e configuradas no Snowflake.

Alguns cenários adicionais são normalmente deixados para o final, mas não devem ser negligenciados:

• Chaves alternativas: se você estiver usando 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: dependendo do seu setor, pode haver épocas mais ou menos favoráveis durante o ano para realizar a migração. Considere o cronograma com atenção.

• Licenciamento da plataforma legada: não se esqueça de que você pode enfrentar prazos rígidos relacionados ao licenciamento da plataforma legada. Planeje sua migração levando em conta esses prazos.

Fase 9: Otimizar e executar¶

Após a migração para o Snowflake, o sistema entra em modo de manutenção normal. Todos os sistemas de software são organismos vivos que exigem manutenção contínua. Chamamos essa fase após a migração de otimização e execução e enfatizamos que ela não faz parte da migração em si.

A otimização e a melhoria contínua são processos contínuos que ocorrem após a migração. Neste ponto, sua equipe assume total responsabilidade pelo sistema no Snowflake. O sistema continuará evoluindo, e a otimização será orientada pelos padrões de uso.

Em geral, constatamos que os trabalhos no Snowflake tendem a ser executados mais rapidamente do que nas plataformas originais. Se o desempenho não atender às expectativas, talvez seja necessário executar algumas otimizações para aproveitar ao máximo a arquitetura exclusiva do Snowflake. O Snowflake oferece diversas ferramentas de análise de consultas que podem ajudar a identificar gargalos, permitindo que você otimize partes específicas do fluxo de trabalho.

Durante a fase de otimização, pode ser necessário revisar diferentes aspectos do sistema. A vantagem é que você já está se beneficiando dos recursos do Snowflake, e as tarefas de otimização se tornarão parte de sua rotina regular de manutenção.

Como recomendação, se concentre em resolver apenas problemas críticos de desempenho durante a fase de migração. A otimização é melhor tratada como um esforço pós-migração.

Apêndice 1: Bancos de dados do Teradata a serem excluídos na migração para o Snowflake¶

A lista a seguir de bancos de dados é necessária apenas para o Teradata e não deve ser migrada para o Snowflake:

Apêndice 2: Tipos de dados do Teradata para tipos de dados do Snowflake¶