Guia de migração do Amazon RedShift para o Snowflake¶
Estrutura de migração do Snowflake¶
Uma migração típica do Amazon Redshift para o Snowflake pode ser dividida em nove fases principais. Este guia fornece uma estrutura abrangente para lidar com os desafios técnicos e estratégicos envolvidos, garantindo uma transição tranquila para a plataforma de dados em nuvem do Snowflake.
Fases da migração¶
Fase 1: Planejamento e projeto¶
Esta fase inicial é crucial para estabelecer a base de uma migração bem-sucedida. A pressa nesta etapa geralmente leva a aumento do escopo, estouros de orçamento e prazos perdidos. Um planejamento completo garante que todas as partes interessadas estejam alinhadas e que os objetivos do projeto estejam claramente definidos.
Suas etapas práticas:
Realize uma avaliação completa do seu ambiente Redshift:
Inventário e análise: catalogue todos os bancos de dados, esquemas, tabelas, exibições, procedimentos armazenados e funções definidas pelo usuário (UDFs) em seu cluster Redshift. Use as tabelas de sistema do Redshift (SVV_TABLE_INFO, PG_PROC, etc.) para coletar metadados.
Analise as cargas de trabalho: use as exibições STL_QUERY e SVL_QUERY_SUMMARY do Redshift para identificar padrões de consulta, simultaneidade de usuários e gargalos de desempenho. Esses dados são cruciais para o planejamento da sua estratégia de data warehouse virtual do Snowflake.
Identifique as dependências: mapeie todas as fontes de dados upstream (trabalhos ETL/ELT) e os consumidores downstream (ferramentas de BI, aplicativos, notebooks de ciência de dados).
Defina o escopo e a estratégia de migração:
Priorize cargas de trabalho: classifique as cargas de trabalho por impacto nos negócios e complexidade técnica. Comece com uma carga de trabalho de alto impacto e baixa complexidade para obter resultados rápidos e ganhar impulso.
Escolha uma abordagem de migração:** decida entre uma abordagem de migração direta («lift and shift») para uma migração mais rápida ou uma abordagem de reestruturação para modernizar e otimizar pipelines e modelos de dados.
Desenvolva o plano do projeto:
Forme uma equipe: crie uma equipe de migração com funções e responsabilidades claras (por exemplo, gerente de projeto, engenheiro de dados, DBA, administrador de segurança, analista de negócios).
Crie um cronograma: defina cronogramas e marcos realistas para cada uma das nove fases.
Defina métricas de sucesso:** estabeleça métricas de KPIs claras para medir o sucesso da migração, como redução de custos, melhoria no desempenho de consultas e satisfação dos usuários.
Fase 2: Ambiente e segurança¶
Com um plano sólido em vigor, o próximo passo é preparar o ambiente Snowflake e replicar sua postura de segurança. Uma das principais vantagens de migrar do Redshift é que ambas as plataformas geralmente são executadas no mesmo provedor de nuvem (AWS), o que simplifica a transferência de dados.
Suas etapas práticas:
Configure sua conta Snowflake:
Escolha a edição e o provedor de nuvem: selecione a edição do Snowflake (por exemplo, Standard, Enterprise, Business Critical) que atenda às suas necessidades. Escolha a AWS como provedor de nuvem e selecione a mesma região dos seus buckets S3 atuais para minimizar os custos de transferência de dados e a latência.
Projete uma estratégia de warehouse: com base na análise de carga de trabalho da Fase 1, crie um conjunto inicial de warehouses virtuais. Isole cargas de trabalho diferentes (por exemplo, WH_LOADING, WH_TRANSFORM, WH_BI_ANALYTICS) para evitar disputa por recursos. Comece com tamanhos de camiseta (por exemplo, PP, P) e planeje redimensioná-los com base em testes de desempenho.
Implemente o modelo de segurança:
Mapeie usuários/grupos do Redshift para funções do Snowflake: traduza as permissões de usuário e grupo do Redshift para o modelo de controle de acesso baseado em funções (RBAC) do Snowflake. Crie uma hierarquia de funções (por exemplo, SYSADMIN, SECURITYADMIN) e funções de acesso (por exemplo, BI_READ_ONLY, ETL_READ_WRITE).
Configure políticas de rede e autenticação: configure políticas de rede para restringir o acesso a endereços IP confiáveis. Configure métodos de autenticação, como autenticação federada (SSO), usando um provedor de identidade como Okta ou Azure AD.
Fase 3: Conversão do código do banco de dados¶
Esta fase envolve a conversão do código DDL, DML e procedural do Redshift para que seja compatível com o Snowflake. Ferramentas de automação podem acelerar esse processo, mas a revisão e o ajuste manuais são essenciais devido às diferenças nos dialetos SQL e na arquitetura da plataforma.
Suas etapas práticas:
Converta DDL (linguagem de definição de dados):
Tabelas e exibições: extraia as instruções CREATE, TABLE e CREATE e VIEW do Redshift. Converta os tipos de dados específicos do Redshift para seus equivalentes no Snowflake (consulte o Apêndice 2).
Remova cláusulas específicas do Redshift: elimine as cláusulas de design físico específicas do Redshift, como DISTSTYLE, DISTKEY e SORTKEY. A arquitetura do Snowflake lida com a distribuição e o clustering de dados automaticamente ou por meio de chaves de clustering lógico em tabelas muito grandes.
Converta DML (linguagem de manipulação de dados) e código procedural:
Reescreva procedimentos armazenados: o Redshift usa PL/pgSQL para procedimentos armazenados. Eles devem ser reescritos manualmente em uma linguagem compatível com o Snowflake, como Snowflake Scripting (SQL), JavaScript, Python ou Java. Essa é geralmente a parte mais demorada do processo de conversão de código.
Traduza funções SQL:** mapeie funções específicas do Redshift para suas contrapartes no Snowflake. Por exemplo, GETDATE(), do Redshift, torna-se CURRENT_TIMESTAMP() no Snowflake. Consulte o Apêndice 3 para ver os mapeamentos de funções comuns.
Substitua comandos de manutenção: scripts que contêm comandos específicos do Redshift, como VACUUM, ANALYZE e REINDEX, devem ser removidos, pois o Snowflake lida com essas tarefas de manutenção automaticamente.
Fase 4: Migração de dados¶
Esta fase concentra-se na movimentação física de dados históricos do seu cluster do Redshift para as tabelas do Snowflake. O método mais eficiente utiliza o Amazon S3 como área de preparação intermediária.
Suas etapas práticas:
Descarregue dados do RedShift para S3:
Use o comando UNLOAD do Redshift para exportar dados das tabelas para um bucket S3 designado. Este processo é muito paralelizado e significativamente mais rápido do que uma consulta SELECT por meio de uma ferramenta cliente.
Formate os dados como Parquet ou CSV compactado para conseguir o melhor desempenho de carregamento no Snowflake. Use a opção PARALLEL ON para gravar vários arquivos.
Carregue dados do S3 para o Snowflake:
Crie áreas de preparação externas: no Snowflake, crie um objeto de área de preparação externa que aponte para o bucket S3 que contém seus dados descarregados.
Use o comando COPY INTO: use o comando COPY INTO <table> do Snowflake para carregar os dados da área de preparação S3 para as tabelas de destino do Snowflake. Esse comando é altamente eficiente e escalonável.
Aproveite um warehouse de tamanho maior: use um warehouse virtual dedicado e maior para o carregamento inicial de dados para acelerar o processo e, em seguida, reduza a escala ou suspenda-o posteriormente para gerenciar custos.
Fase 5: Ingestão de dados¶
Após a migração dos dados históricos, você deve reestruturar seus pipelines de ingestão de dados contínuos para alimentar os dados diretamente no Snowflake em vez de no Redshift.
Suas etapas práticas:
Migre trabalhos ETL/ELT em lote:
Atualize os trabalhos ETL existentes (em ferramentas como AWS Glue, Talend ou Informatica) para direcionar o Snowflake como destino. Isso geralmente envolve a alteração dos detalhes de conexão e a atualização de quaisquer substituições SQL para usar o dialeto do Snowflake.
Implemente a ingestão contínua com o Snowpipe:
Para fluxos contínuos de dados (por exemplo, do Kinesis ou logs de aplicativos que chegam ao S3), configure o Snowpipe. O Snowpipe carrega automaticamente e com eficiência novos arquivos de dados do S3 para as tabelas do Snowflake à medida que eles chegam, fornecendo uma solução de ingestão quase em tempo real.
Use o ecossistema Snowflake:
Explore os conectores nativos do Snowflake para plataformas como Kafka e Spark para simplificar o streaming direto de dados.
Fase 6: Relatórios e análises¶
Esta fase envolve o redirecionamento de todos os aplicativos downstream, particularmente ferramentas de relatório e BI, para consultar dados do Snowflake.
Suas etapas práticas:
Atualize os drivers de conexão: instale e configure os drivers ODBC/JDBC do Snowflake nos servidores que hospedam suas ferramentas de BI (por exemplo, Tableau Server, Power BI Gateway).
Redirecione relatórios e painéis:
Em suas ferramentas de BI, altere a conexão da fonte de dados do Redshift para o Snowflake.
Teste todos os relatórios e painéis críticos para garantir que funcionem corretamente.
Revise e otimize consultas:
Alguns painéis podem conter funções personalizadas SQL ou específicas do banco de dados. Revise e refatore essas consultas para usar o dialeto SQL do Snowflake e aproveitar os recursos de desempenho. Use a ferramenta Query Profile no Snowflake para analisar e otimizar relatórios com execução lenta.
Fase 7: Validação e testes de dados¶
Testes rigorosos são essenciais para gerar confiança na nova plataforma e garantir que a integridade e o desempenho dos dados atendam às expectativas.
Suas etapas práticas:
Execute uma validação de dados:
Contagem de linhas: compare a contagem de linhas entre as tabelas de origem no Redshift e as tabelas de destino no Snowflake.
Validação em nível de célula: para tabelas críticas, realize uma validação mais aprofundada comparando valores agregados (por exemplo, SUM(), AVG(), MIN(), MAX()) ou usando checksums em colunas-chave.
Realize testes de desempenho e consultas:
Consultas de referência: execute um conjunto representativo de consultas tanto no Redshift quanto no Snowflake e compare os resultados e o desempenho.
Desempenho da ferramenta de BI: teste os tempos de carregamento e a interatividade dos principais painéis conectados ao Snowflake.
Teste de aceitação do usuário (UAT):
Envolva os usuários empresariais para validar os relatórios e executar as tarefas diárias deles usando o novo ambiente Snowflake. Reúna feedback e resolva os problemas que aparecerem.
Fase 8: Implantação¶
A implantação é a transição final do Redshift para o Snowflake. Esse processo deve ser gerenciado com cuidado para minimizar a interrupção das operações comerciais.
Suas etapas práticas:
Desenvolva um plano de transição:
Defina a sequência de eventos para o fim de semana ou a noite da transição. Isso inclui interromper os trabalhos de ETL que apontam para o Redshift, realizar uma sincronização final de dados, redirecionar todas as conexões e validar a integridade do sistema.
Execute a sincronização final dos dados:
Realize um último carregamento incremental de dados para capturar todas as alterações de dados que ocorreram durante a fase de testes.
Entre em produção:
Transfira todos os pipelines de dados de produção e conexões de usuários do Redshift para o Snowflake.
Mantenha o ambiente Redshift em estado somente leitura por um curto período como medida de segurança antes de desativá-lo.
Desative o RedShift:
Assim que o ambiente Snowflake estiver estável e validado em produção, você poderá desativar seu cluster do Redshift para interromper os custos.
Fase 9: Otimizar e executar¶
Esta fase final é um processo contínuo de gerenciamento de desempenho, custo e governança em seu novo ambiente Snowflake. O objetivo é refinar continuamente sua configuração para maximizar o valor dela.
Suas etapas práticas:
Implemente a otimização de desempenho e custos:
Dimensione os warehouses corretamente: monitore continuamente o desempenho da carga de trabalho e ajuste os tamanhos dos warehouses virtuais para cima ou para baixo para atender aosSLAs com o menor custo possível.
Defina políticas agressivas de suspensão automática: defina o tempo limite de suspensão automática para todos os warehouses em 60 segundos para evitar o pagamento por tempo ocioso de computação.
Use chaves de clustering: para tabelas muito grandes (multiterabytes), analise os padrões de consulta e defina chaves de clustering para melhorar o desempenho de consultas altamente filtradas.
Estabeleça governança e FinOps de longo prazo:**
Monitore os custos: use os monitores de esquema e recursos ACCOUNT_USAGE do Snowflake para acompanhar o consumo de crédito e evitar estouros de orçamento.
Aprimore a segurança: audite regularmente as funções e permissões para garantir que o princípio do menor privilégio seja mantido. Implemente recursos avançados de segurança, como mascaramento dinâmico de dados e políticas de acesso a linhas para dados confidenciais.
Apêndice¶
Apêndice 1: Arquiteturas Snowflake Arquitetura do RedShift¶
Recurso |
Amazon Redshift |
Snowflake |
|---|---|---|
Arquitetura |
Computação e armazenamento fortemente integrados (MPP) |
Computação, armazenamento e serviços de nuvem desacoplados (multicluster, dados compartilhados) |
Armazenamento |
Armazenamento colunar gerenciado em SSDs locais conectados aos nós |
Armazenamento de objetos centralizado (por exemplo, S3) com microparticionamento automático |
Computação |
Cluster de nós de tamanho fixo (líder + nós de computação) |
Warehouses virtuais elásticos e sob demanda (clusters de computação) |
Simultaneidade |
Limitada pelo tamanho do cluster; as consultas podem ser enfileiradas |
Alta simultaneidade por meio de warehouses multicluster que são inicializados automaticamente |
Dimensionamento |
Dimensiona adicionando nós (leva de minutos a horas, envolve redistribuição de dados) |
Dimensiona instantaneamente a capacidade computacional para cima/para baixo/para fora (em segundos); o armazenamento é dimensionado automaticamente |
Manutenção |
Requer comandos VACUUM e ANALYZE manuais |
Totalmente gerenciada; as tarefas de manutenção são automatizadas e executadas em segundo plano |
Apêndice 2: Mapeamentos de tipos de dados¶
Amazon Redshift |
Snowflake |
Notas |
|---|---|---|
SMALLINT |
SMALLINT / NUMBER(5,0) |
|
INTEGER |
INTEGER / NUMBER(10,0) |
|
BIGINT |
BIGINT / NUMBER(19,0) |
|
DECIMAL(p,s) / NUMERIC(p,s) |
NUMBER(P,S) |
|
REAL / FLOAT4 |
FLOAT |
|
DOUBLE PRECISION / FLOAT8 |
FLOAT |
|
BOOLEAN |
BOOLEAN |
|
CHAR(n) |
CHAR(n) / VARCHAR(n) |
O Snowflake preenche CHAR com espaços; VARCHAR é muitas vezes preferido. |
VARCHAR(n) |
VARCHAR(n) |
O comprimento máximo no Snowflake é 16MB. |
DATE |
DATE |
|
TIMESTAMP |
TIMESTAMP_NTZ |
O Snowflake separa carimbos de data/hora com e sem fusos horários. |
TIMESTAMPTZ |
TIMESTAMP_TZ |
|
GEOMETRY |
GEOGRAPHY / GEOMETRY |
O Snowflake tem suporte nativo para dados geoespaciais. |
SUPER |
VARIANT |
Para dados semiestruturados (JSON). |
Apêndice 3: Diferenças entre SQL e funções¶
Amazon Redshift |
Snowflake |
Notas |
|---|---|---|
GETDATE() |
CURRENT_TIMESTAMP() |
O Snowflake tem diversas funções para data/hora atual. |
SYSDATE |
CURRENT_TIMESTAMP() |
SYSDATE é um alias para GETDATE no Redshift. |
LISTAGG(expr, delim) |
LISTAGG(expr, delim) |
A sintaxe é semelhante, mas o comportamento de ordenação pode ser diferente. |
NVL(expr1, expr2) |
NVL(expr1, expr2) / IFNULL(expr1, expr2) |
A funcionalidade é idêntica. |
DECODE(expr, search, result…) |
DECODE(expr, search, result…) |
Compatível em ambas. As instruções CASE são mais padronizadas. |
DATEDIFF(part, start, end) |
DATEDIFF(part, start, end) |
Compatível, mas as partes de data/hora podem ter nomes diferentes (por exemplo, yr em vez de year). |
DATEADD(part, num, date) |
DATEADD(part, num, date) |
Compatível, mas as partes de data/hora podem ter nomes diferentes. |
Procedimentos armazenados |
PL/pgSQL |
Snowflake Scripting (SQL), JavaScript, Python, Java |
Cláusulas DDL |
DISTKEY, SORTKEY, ENCODE |
Nenhum. Substituídas por microparticionamento automático e chaves de clustering opcionais. |
Manutenção |
VACUUM, ANALYZE |
Nenhum. Serviços automatizados em segundo plano cuidam da manutenção. |
Carregamento de dados |
UNLOAD, COPY |
COPY INTO, Snowpipe |