Guia de migração do Oracle para o Snowflake

Estrutura de migração do Snowflake

Uma migração típica do Oracle 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 de uma arquitetura de banco de dados tradicional 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. Migrar do Oracle envolve mudanças de arquitetura significativas, e um plano completo é essencial para alinhar as partes interessadas, definir o escopo e evitar estouros de orçamento e atrasos.

Suas etapas práticas:

  • Faça uma avaliação completa de seu ambiente Oracle:

    • Inventário e análise: catalogue todos os objetos do banco de dados, incluindo esquemas, tabelas, exibições, exibições materializadas, índices, pacotes, procedimentos, funções e gatilhos. Use as exibições do dicionário de dados do Oracle (DBA_OBJECTS, DBA_SOURCE, DBA_TABLES, etc.) para coletar esses metadados.

    • Analise cargas de trabalho: use os relatórios do Repositório automático de cargas de trabalho da Oracle (AWR) e as exibições de desempenho dinâmicas (V$SQL, V$SQLAREA) para identificar padrões de consulta, simultaneidade de usuários, gargalos de desempenho e utilização de recursos. Esses dados são cruciais para o planejamento da sua estratégia de data warehouse virtual do Snowflake.

    • Identifique dependências: mapeie todas as fontes de dados upstream (trabalhos ETL/ELT, fluxos de dados) e os consumidores downstream (ferramentas de BI, aplicativos e serviços de relatórios). Preste atenção especial aos aplicativos que dependem muito de pacotes PL/SQL.

  • 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 (por exemplo, um data mart específico) para demonstrar valor e ganhar impulso.

    • ** Escolha uma abordagem de migração:** decida entre uma abordagem «lift and shift» para uma migração mais rápida ou uma abordagem de reestruturação para modernizar e otimizar modelos de dados, pipelines ETL/ELT e lógica procedural.

  • Desenvolva o plano do projeto:

    • Forme uma equipe: crie uma equipe de migração com funções claras (gerente de projeto, engenheiro de dados, DBA Oracle, arquiteto Snowflake, 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 KPIs claros para medir o sucesso, como redução de custos, melhoria no desempenho de consultas, aumento da simultaneidade e satisfação dos usuários.

Fase 2: Ambiente e segurança

Com um plano sólido, o próximo passo é preparar o ambiente Snowflake e traduzir o modelo de segurança da Oracle. Isso envolve a configuração de contas, redes e uma nova estrutura de controle de acesso baseado em funções (RBAC).

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 aos seus requisitos de segurança e recursos. Escolha um provedor de nuvem (AWS, Azure ou GCP) e uma região que estejam alinhados com sua estratégia de nuvem e minimizem a latência para seus usuários e outros serviços de nuvem.

    • 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:

    • Mapear usuários/funções do Oracle para funções do Snowflake: traduza o modelo de usuários, funções e privilégios do Oracle para o modelo RBAC hierárquico do Snowflake. Essa é uma mudança significativa, pois os privilégios granulares em nível de sistema e de objeto do Oracle não são mapeados diretamente. Crie uma hierarquia de funções funcionais (SYSADMIN, SECURITYADMIN) e funções de acesso (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 (por exemplo, sua rede corporativa ou VPN). Configure métodos de autenticação, como autenticação federada (SSO) com 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 da extensa base de código PL/SQL do Oracle para que sejam compatíveis com o Snowflake. Esta é geralmente a fase mais complexa e demorada da migração.

Suas etapas práticas:

  • Converta DDL (linguagem de definição de dados):

    • Tabelas e exibições: extraia as instruções CREATE, TABLE, CREATE e VIEW do Oracle. Converta os tipos de dados específicos do Oracle em seus equivalentes no Snowflake (consulte o Apêndice 2).

    • Remova cláusulas específicas do Oracle: elimine as cláusulas de armazenamento físico específicas do Oracle, como TABLESPACE, PCTFREE, INITRANS, STORAGE, e esquemas complexos de particionamento/indexação. O Snowflake gerencia o armazenamento e o layout dos dados automaticamente.

    • Reimplemente restrições: o Snowflake aplica apenas as restrições NOT e NULL. As restrições PRIMARY, KEY e UNIQUE podem ser definidas, mas não são aplicadas; elas servem principalmente como metadados para otimizadores e ferramentas de BI. Restrições FOREIGN e KEY não são compatíveis. Toda a lógica de integridade de dados deve ser movida para seus processos ETL/ELT.

  • Converta DML (linguagem de manipulação de dados) e código procedural:

    • Reescreva PL/SQL: os PL/SQL (pacotes, procedimentos, funções, gatilhos) do Oracle devem ser completamente reescritos. Destinos comuns incluem o Snowflake Scripting (SQL), JavaScript UDFs/UDTFs/Procs ou a externalização da lógica para uma ferramenta de transformação como dbt ou um serviço de orquestração como o Airflow.

    • Traduza funções SQL:** mapeie as funções específicas do Oracle para suas contrapartes no Snowflake (por exemplo, SYSDATE torna-se CURRENT_TIMESTAMP(), NVL torna-se IFNULL, VARCHAR2 torna-se VARCHAR). Consulte o Apêndice 3 para ver os mapeamentos comuns.

    • Substitua sequências:** recrie as sequências do Oracle usando o objeto SEQUENCE do Snowflake.

    • Manipule instruções MERGE:** revise e teste as instruções MERGE com cuidado, pois a sintaxe e o comportamento podem diferir ligeiramente entre o Oracle e o Snowflake.

Fase 4: Migração de dados

Esta fase concentra-se na movimentação física de dados históricos do seu banco de dados Oracle para as tabelas do Snowflake. A abordagem mais comum envolve a extração de dados para arquivos e o carregamento desses dados por meio de uma área de preparação de armazenamento em nuvem.

Suas etapas práticas:

  • Extraia dados do Oracle para arquivos:

    • Utilize métodos como Oracle Data Pump, spooling do SQL*Plus ou UTL_FILE para extrair dados da tabela para um formato de arquivo estruturado (por exemplo, Parquet, CSV compactado).

    • Para bancos de dados muito grandes, considere o uso de ferramentas de integração de dados de terceiros (por exemplo, Fivetran, Matillion, Talend, Informatica) que podem extrair dados do Oracle com eficiência.

  • Carregue dados para uma área de preparação de armazenamento em nuvem:

    • Transfira os arquivos extraídos para uma localização de armazenamento em nuvem (Amazon S3, Azure Blob Storage ou Google Cloud Storage) que servirá como área de preparação externa para o Snowflake.

  • Carregue os dados de uma área de preparação para o Snowflake:

    • Crie áreas de preparação externas: no Snowflake, crie um objeto de área de preparação externa que aponte para a localização de armazenamento em nuvem que contém seus arquivos de dados.

    • Use o comando COPY INTO:** use o comando COPY INTO <table> do Snowflake para carregar os dados da área de preparação 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 em andamento para alimentar os dados diretamente no Snowflake.

Suas etapas práticas:

  • Migre trabalhos ETL/ELT em lote:

    • Atualize os trabalhos ETL existentes (em ferramentas como Oracle Data Integrator, Informatica ou Talend) para direcionar o Snowflake como destino. Isso envolve alterar os detalhes da conexão e reescrever as substituições SQL específicas do Oracle para usar o dialeto do Snowflake.

  • Implemente a ingestão contínua:

    • Para carregamento contínuo de dados, configure o Snowpipe para ingerir arquivos automaticamente à medida que eles chegam à sua área de preparação de armazenamento em nuvem. Esta é uma substituição ideal para trabalhos em microlotes.

  • Use o ecossistema Snowflake:

    • Explore os conectores nativos do Snowflake para plataformas como Kafka e Spark ou aproveite as ferramentas de parceiros para simplificar o streaming direto de dados e a captura de dados de alteração (CDC) do Oracle.

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 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, Oracle Analytics Server).

  • Redirecione relatórios e painéis:

    • Em suas ferramentas de BI, altere a conexão da fonte de dados do Oracle para o Snowflake.

    • Teste todos os relatórios e painéis críticos para garantir que funcionem corretamente.

  • Revise e otimize consultas:

    • Muitos painéis contêm SQL personalizado com dicas ou funções específicas do Oracle. Revise e refatore essas consultas para usar SQL padrão e aproveitar os recursos de desempenho do Snowflake. 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 Oracle 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 (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 Oracle 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 Oracle 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 a transição. Isso inclui interromper trabalhos de ETL que apontam para o Oracle, 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 Oracle para o Snowflake.

    • Mantenha o ambiente Oracle em estado somente leitura por um curto período como medida de segurança antes de desativá-lo.

  • Desative o Oracle:

    • Assim que o ambiente Snowflake estiver estável e validado em produção, você poderá desativar seus servidores de banco de dados Oracle para interromper os custos de licença e manutenção.

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 e Oracle em comparação

Recurso

Oracle

Snowflake

Arquitetura

Monolítica ou de disco compartilhado (RAC). Computação e armazenamento fortemente acoplados.

Computação, armazenamento e serviços de nuvem desacoplados (multicluster, dados compartilhados).

Armazenamento

Gerenciado pelo banco de dados em discos locais, SAN ou NAS (sistemas de arquivos/ASM).

Armazenamento de objetos centralizado (S3, Blob, GCS) com microparticionamento automático.

Computação

Recursos de servidor fixos (CPU, memória, E/S).

Warehouses virtuais elásticos e sob demanda (clusters de computação).

Simultaneidade

Limitada pelo hardware do servidor e pela sessão/processo.

Alta simultaneidade por meio de warehouses multicluster que são inicializados automaticamente.

Dimensionamento

Vertical (servidor mais potente) ou horizontal (nós RAC). Muitas vezes requer tempo de inatividade e esforço significativo.

Dimensiona instantaneamente a capacidade computacional para cima/para baixo/para fora (em segundos); o armazenamento é dimensionado automaticamente.

Manutenção

Requer DBAs para executar tarefas como reconstrução de índices, coleção de estatísticas e gerenciamento de espaços de tabela.

Totalmente gerenciada; as tarefas de manutenção são automatizadas e executadas em segundo plano.

Apêndice 2: Mapeamentos de tipos de dados

Oracle

Snowflake

Notas

NUMBER(P,S)

NUMBER(P,S)

Mapeamento direto.

NUMBER

NUMBER(38,0)

NUMBER do Oracle não especificado mapeia para o número inteiro de precisão máxima do Snowflake.

FLOAT, BINARY_FLOAT, BINARY_DOUBLE

FLOAT

VARCHAR2(n)

VARCHAR(n)

VARCHAR2 e VARCHAR são funcionalmente equivalentes.

CHAR(n)

CHAR(n)

NVARCHAR2(n), NCHAR(n)

VARCHAR(n), CHAR(n)

O conjunto de caracteres padrão do Snowflake é UTF-8, tornando desnecessários tipos de caracteres nacionais especiais.

CLOB, NCLOB

VARCHAR / STRING

VARCHAR do Snowflake pode armazenar até 16MB.

BLOB

BINARY

BINARY do Snowflake pode armazenar até 8MB. Considere armazenar objetos maiores em áreas de preparação externas.

RAW(n)

BINARY(n)

DATE

TIMESTAMP_NTZ

DATE do Oracle armazena data e hora. TIMESTAMP_NTZ é o equivalente mais próximo.

TIMESTAMP(p)

TIMESTAMP_NTZ(p)

TIMESTAMP(p) WITH TIME ZONE

TIMESTAMP_TZ(p)

TIMESTAMP(p) WITH LOCAL TIME ZONE

TIMESTAMP_LTZ(p)

INTERVAL YEAR TO MONTH / DAY TO SECOND

VARCHAR ou reescreva a lógica

O Snowflake não tem um tipo de dados INTERVAL. Use funções de data/hora para cálculos.

XMLTYPE

VARIANT

Carregue dados XML em uma coluna VARIANT para consultas semiestruturadas.

Apêndice 3: Diferenças entre SQL e funções

Oracle

Snowflake

Notas

SYSDATE

CURRENT_TIMESTAMP()

CURRENT_DATE() e CURRENT_TIME() também estão disponíveis.

Tabela DUAL

Nenhum

Não obrigatório. SELECT 1; é uma sintaxe válida no Snowflake.

NVL(expr1, expr2)

IFNULL(expr1, expr2) ou NVL(expr1, expr2)

Ambas são compatíveis com o Snowflake. COALESCE é o ANSI padrão.

DECODE(expr, search, result…)

DECODE(expr, search, result…) ou CASE

As instruções CASE são mais padronizadas e flexíveis.

ROWNUM

Função de janela ROW_NUMBER()

ROWNUM é aplicado antes de ORDER BY. ROW_NUMBER() é mais explícito e padronizado.

LISTAGG(expr, delim)

LISTAGG(expr, delim)

A sintaxe é semelhante.

Junção externa (+)

LEFT/RIGHT/FULL OUTER JOIN

O Snowflake requer a sintaxe de junção ANSI padrão.

Operador MINUS

MINUS / EXCEPT

Ambos são compatíveis com o Snowflake.

Linguagem procedural

PL/SQL (pacotes, procedimentos, acionadores)

Snowflake Scripting, JavaScript, Java, Python

Sequências

CREATE SEQUENCE

CREATE SEQUENCE

Transações

COMMIT, ROLLBACK

COMMIT, ROLLBACK

Dicas

/*+ … */

Nenhum