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