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 |