Migração do Snowflake para o BigQuery

Este documento apresenta uma introdução sobre como migrar do Snowflake para o BigQuery. As seções a seguir apresentam as ferramentas de migração para ajudar você a migrar para o BigQuery e descrevem algumas diferenças entre o Snowflake e o BigQuery para ajudar você a planejar sua migração.

Migrar fluxos de trabalho do Snowflake para o BigQuery

Ao planejar uma migração do BigQuery, considere os diferentes fluxos de trabalho que você tem no Snowflake e como migrá-los individualmente. Para minimizar o impacto nas suas operações atuais, recomendamos migrar as consultas SQL para o BigQuery e, em seguida, migrar o esquema e o código.

Migrar consultas SQL

Para migrar suas consultas SQL, o serviço de migração do BigQuery oferece vários recursos de tradução de SQL para automatizar a conversão das consultas SQL do Snowflake para o GoogleSQL, como o tradutor de SQL em lote para traduzir consultas em massa, o tradutor de SQL interativo para traduzir consultas individuais e a API de tradução de SQL. Esses serviços de tradução também incluem funcionalidade aprimorada do Gemini para simplificar ainda mais o processo de migração de consulta SQL.

Ao traduzir suas consultas SQL, revise com cuidado as consultas traduzidas para verificar se os tipos de dados e as estruturas de tabela estão sendo processados corretamente. Para isso, recomendamos criar uma ampla variedade de casos de teste com diferentes cenários e dados. Em seguida, execute esses casos de teste no BigQuery para comparar os resultados com os originais do Snowflake. Se houver diferenças, analise e corrija as consultas convertidas.

Migrar esquema e código

Pré-lançamento

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases de lançamento.

Para migrar esquema e dados do Snowflake, use o conector do Snowflake no serviço de transferência de dados do BigQuery para configurar uma transferência de dados. Ao configurar a transferência de dados, você pode especificar tabelas do Snowflake para incluir e fazer com que o conector detecte automaticamente o esquema da tabela e os tipos de dados durante uma transferência.

Para mais informações sobre como configurar uma transferência de dados do Snowflake, consulte Programar uma transferência do Snowflake.

Recursos de segurança do BigQuery

Ao migrar do Snowflake para o BigQuery, considere como oGoogle Cloud processa a segurança de forma diferente do Snowflake.

A segurança no BigQuery está intrinsecamente ligada ao gerenciamento de identidade e acesso (IAM) no Google Cloud. Os privilégios do IAM definem as operações permitidas em um recurso e são aplicados no nível Google Cloud , oferecendo uma abordagem centralizada e consistente para o gerenciamento de segurança. Confira alguns dos principais recursos de segurança do Google Cloud:

• Segurança integrada: o BigQuery usa os recursos de segurança do Google Cloud. Isso inclui o IAM para controle de acesso granular e integração de segurança robusta e perfeita.
• Segurança no nível do recurso: o IAM se concentra no controle de acesso no nível do recurso, concedendo permissões a usuários e grupos para vários recursos e serviços do BigQuery. Essa abordagem permite o gerenciamento eficaz dos direitos de acesso para que os usuários tenham apenas as permissões necessárias para realizar as tarefas.
• Segurança de rede: o BigQuery se beneficia dos recursos robustos de segurança de rede do Google Cloud, como a nuvem privada virtual e as conexões particulares.

Ao migrar do Snowflake para o BigQuery, considere os seguintes requisitos de migração relacionados à segurança:

• Configuração do IAM: configure papéis e permissões do IAM no BigQuery para corresponder às políticas de controle de acesso do Snowflake. Isso envolve mapear os papéis do Snowflake para os papéis e permissões do IAM do BigQuery adequados.
• Controle de acesso refinado: se você estiver usando segurança no nível da linha ou da coluna no Snowflake, será necessário implementar controles equivalentes no BigQuery usando visualizações autorizadas ou tags de política.
• Migração de visualizações e UDFs: ao migrar visualizações e UDFs, verifique se os controles de segurança associados foram traduzidos corretamente para visualizações autorizadas e UDFs autorizadas no BigQuery.

Criptografia

O BigQuery criptografa seus dados em repouso e em trânsito por padrão. Se você precisar de mais controle sobre as chaves de criptografia, o BigQuery aceita chaves de criptografia gerenciadas pelo cliente no Cloud Key Management Service. Também é possível usar a criptografia no nível da coluna.

Para manter segurança de dados durante e após a migração para o BigQuery, considere o seguinte:

• Gerenciamento de chaves: se você precisar de chaves gerenciadas pelo cliente, estabeleça uma estratégia de gerenciamento de chaves no Cloud Key Management Service e configure o BigQuery para usar essas chaves.
• Mascaramento/tokenização de dados: se dados sensíveis estiverem envolvidos, avalie se o mascaramento ou a tokenização de dados são necessários para protegê-los.
• Segurança no nível da linha: implemente a segurança no nível da linha usando visualizações autorizadas, filtros de segurança no nível da linha ou outros métodos adequados.
• Verificação de vulnerabilidades e teste de penetração: realize verificações de vulnerabilidades e testes de penetração regularmente para verificar a postura de segurança do seu ambiente do BigQuery.

Papéis

Papéis são as entidades às quais privilégios podem ser concedidos e revogados em objetos protegidos.

No IAM, as permissões são agrupadas em papéis. O IAM fornece três tipos de papéis:

• Papéis básicos: eles incluem os papéis de proprietário, editor e visualizador. É possível aplicar esses papéis nos níveis de recurso ou serviço do projeto usando o consoleGoogle Cloud , a API do Identity and Access Management ou a gcloud CLI. Em geral, para aumentar a segurança, recomendamos que você use papéis predefinidos para seguir o princípio de menor privilégio.
• Papéis predefinidos: eles dão acesso mais granular aos recursos de um produto (como o BigQuery) e visam oferecer suporte a casos de uso comuns e padrões de controle de acesso.
• Papéis personalizados: são compostos por permissões especificadas pelo usuário.

Controle de acesso

Com o Snowflake, você pode atribuir outros papéis, criando uma hierarquia de papéis. O IAM não suporta uma hierarquia de papéis, mas implementa uma hierarquia de recursos. A hierarquia do IAM inclui os níveis da organização, da pasta, do projeto e do recurso. É possível definir papéis do IAM em qualquer nível da hierarquia, e os recursos herdam todas as políticas dos recursos pai.

O BigQuery é compatível com o controle de acesso no nível da tabela. As permissões no nível da tabela determinam os usuários, grupos e contas de serviço que podem acessar uma tabela ou visualização. É possível conceder a um usuário acesso a tabelas ou visualizações específicas sem expandir isso ao inteiro conjunto de dados.

Para um acesso mais granular, também é possível usar controle de acesso no nível da coluna ou segurança no nível da linha. Esse tipo de controle fornece acesso refinado a colunas confidenciais usando tags de política ou classificações de dados baseadas em tipo.

Também é possível criar visualizações autorizadas para limitar o acesso a dados para um controle de acesso mais refinado, de modo que usuários especificados possam consultar uma visualização sem ter acesso de leitura às tabelas subjacentes.

Migrar outros recursos do Snowflake

Considere os seguintes recursos do Snowflake ao planejar sua migração para o BigQuery. Em alguns casos, é possível usar outros serviços no Google Cloud para concluir a migração.

• Viagem no tempo: no BigQuery, você pode usar a viagem no tempo para acessar dados de qualquer ponto nos últimos sete dias. Se você precisar acessar dados de mais de sete dias, considere exportar snapshots programados regularmente.

• Fluxos: o BigQuery permite a captura de dados alterados (CDC, na sigla em inglês) com o Datastream. Também é possível usar um software de CDC, como Debezium, para gravar registros no BigQuery com o Dataflow. Para mais informações sobre como projetar manualmente um pipeline de CDC com o BigQuery, consulte Como migrar armazenamentos de dados para o BigQuery: captura de dados alterados (CDC).

• Tarefas:o BigQuery permite programar consultas e fluxos ou integrar o fluxo em consultas com o Datastream.

• Funções externas: o BigQuery aceita chamadas de função externas pelo Cloud Run functions. Também é possível usar funções definidas pelo usuário (UDF, na sigla em inglês), como a UDF de SQL, embora essas funções sejam executadas dentro do BigQuery.

Tipos de dados, propriedades e formatos de arquivo suportados

O Snowflake e o BigQuery são compatíveis com a maioria dos mesmos tipos de dados, embora às vezes usem nomes diferentes. Para uma lista completa dos tipos de dados aceitos no Snowflake e no BigQuery, consulte Tipos de dados. Você também pode usar ferramentas de tradução de SQL, como o tradutor de SQL interativo, a API de tradução de SQL ou o tradutor de SQL em lote, para traduzir diferentes dialetos de SQL para o GoogleSQL.

Para mais informações sobre os tipos de dados compatíveis com o BigQuery, consulte Tipos de dados do GoogleSQL.

O Snowflake pode exportar dados nos seguintes formatos de arquivo. É possível carregar os seguintes formatos diretamente no BigQuery:

• Como carregar dados CSV do Cloud Storage.
• Como carregar dados Parquet do Cloud Storage.
• Como carregar dados JSON do Cloud Storage.
• Consulte dados do Apache Iceberg.

Ferramentas de migração

Na lista a seguir, descrevemos as ferramentas que podem ser usadas para migrar dados do Snowflake para o BigQuery. Para exemplos de como essas ferramentas podem ser usadas juntas em um pipeline de migração do Snowflake, consulte Exemplos de pipeline de migração do Snowflake.

• Comando COPY INTO <location>:use esse comando no Snowflake para extrair dados de uma tabela do Snowflake diretamente para um bucket especificado do Cloud Storage. Para ver um exemplo completo, consulte Snowflake para o BigQuery (snowflake2bq) no GitHub.
• Apache Sqoop: para extrair dados do Snowflake para o HDFS ou o Cloud Storage, envie jobs do Hadoop com o driver JDBC do Sqoop e do Snowflake. O Sqoop é executado em um ambiente Dataproc.
• JDBC do Snowflake: use esse driver com a maioria das ferramentas ou aplicativos cliente que suportam JDBC.

Você pode usar as seguintes ferramentas genéricas para migrar dados do Snowflake para o BigQuery:

• O conector do serviço de transferência de dados do BigQuery para Snowflake (prévia): execute uma transferência automatizada em lote dos dados do Cloud Storage para o BigQuery.
• A CLI do Google Cloud: copie os arquivos do Snowflake transferidos por download para o Cloud Storage com essa ferramenta de linha de comando.
• Ferramenta de linha de comando bq:interaja com o BigQuery usando essa ferramenta. Os casos de uso comuns incluem a criação de esquemas de tabelas do BigQuery, o carregamento de dados do Cloud Storage em tabelas e a execução de consultas.
• Bibliotecas de cliente do Cloud Storage: copie os arquivos do Snowflake transferidos por download para o Cloud Storage com uma ferramenta personalizada que usa as bibliotecas de cliente do Cloud Storage.
• Bibliotecas de cliente do BigQuery: interaja com o BigQuery com uma ferramenta personalizada criada sobre a biblioteca de cliente do BigQuery.
• Programador de consultas do BigQuery:programe consultas SQL recorrentes com esse recurso integrado do BigQuery.
• Cloud Composer: use esse ambiente Apache Airflow totalmente gerenciado para orquestrar transformações e jobs de carregamento do BigQuery.

Para mais informações sobre como carregar dados no BigQuery, consulte Como carregar dados no BigQuery.

Preços

Ao planejar a migração do Snowflake, considere o custo de transferir e armazenar dados e usar serviços no BigQuery. Para mais informações, consulte Preços.

Pode haver custos de saída para mover dados do Snowflake ou da AWS. Também pode haver custos adicionais ao transferir dados entre regiões ou entre diferentes provedores de nuvem.

Primeiros passos

As seções a seguir resumem o processo de migração do Snowflake para o BigQuery:

Executar uma avaliação de migração

Na migração do Snowflake para o BigQuery, recomendamos que você comece executando a ferramenta de avaliação de migração do BigQuery para avaliar a viabilidade e os possíveis benefícios de mover seu data warehouse do Snowflake para o BigQuery. Essa ferramenta oferece uma abordagem estruturada para entender seu ambiente atual do Snowflake e estimar o esforço envolvido em uma migração bem-sucedida.

A execução da ferramenta de avaliação de migração do BigQuery gera um relatório de avaliação com as seguintes seções:

• Relatório do sistema atual: um snapshot do sistema e uso atuais do Snowflake, incluindo o número de bancos de dados, esquemas, tabelas e tamanho total em TB. Ele também lista os esquemas por tamanho e aponta para um possível uso de recursos abaixo do ideal, como tabelas sem gravações ou poucas leituras.
• Sugestões de transformação de estado estável do BigQuery: mostram como o sistema vai ficar no BigQuery após a migração. Ele inclui sugestões para otimizar cargas de trabalho no BigQuery e evitar desperdício.
• Plano de migração: fornece informações sobre o próprio esforço de migração. Por exemplo, ir do sistema atual para o estado estável do BigQuery. Esta seção inclui a contagem de consultas que foram traduzidas automaticamente e o tempo esperado para mover cada tabela para o BigQuery.

Para mais informações sobre os resultados de uma avaliação de migração, consulte Analisar o relatório do Looker Studio.

Validar a migração

Depois de migrar os dados do Snowflake para o BigQuery, execute a Ferramenta de validação de dados (DVT) para realizar uma validação nos dados recém-migrados do BigQuery. A DVT valida várias funções, desde o nível da tabela até o da linha, para verificar se os dados migrados funcionam conforme o esperado.