Migração do Snowflake para o BigQuery

Neste documento, apresentamos uma base técnica sobre como migrar dados do Snowflake para o BigQuery. Ele aborda as diferenças fundamentais entre o Snowflake e o BigQuery. Ele também fornece orientação para uma migração bem-sucedida, como:

  • Quais alterações no esquema são necessárias;
  • Quais ferramentas e opções de migração estão disponíveis;
  • Como migrar dados (usando um processo de exportação de exemplo);

Também é possível usar tradução de SQL em lote para migrar os scripts SQL em massa ou a tradução de SQL interativo para traduzir consultas ad hoc. O SQL do Snowflake é compatível com as duas ferramentas da prévia.

Terminologia

Neste documento, usamos a terminologia do Snowflake e do BigQuery para descrever a funcionalidade de cada produto. A tabela a seguir correlaciona os termos do Snowflake com termos equivalentes do BigQuery:

Floco de neve BigQuery
Banco de dados Conjunto de dados
Schema Schema
Tabela temporária ou temporária específica da sessão Tabela anônima ou temporária
Ver Ver
Visualizações seguras Visualizações autorizadas
Armazenamento virtual Reserva
Visualização materializada Visualização materializada
Sem equivalente ao particionamento (porque microparticionamento é usado) Particionamento
Cluster Cluster
Funções definidas pelo usuário (UDFs) com segurança avançada UDFs autorizadas

Comparação de arquitetura

Tanto o Snowflake quanto o BigQuery são armazenamentos de dados analíticos, mas têm algumas diferenças de arquitetura importantes.

A arquitetura do Snowflake é um híbrido de arquiteturas de banco de dados tradicionais com discos compartilhados e arquiteturas de banco de dados sem compartilhamento. Assim como nas arquiteturas sem compartilhamento, os dados no Snowflake são gerenciados em um serviço de armazenamento de objetos na nuvem separado. Assim como na arquitetura de disco compartilhado, as consultas no Snowflake usam clusters de computação dedicados. No Snowflake, cada cluster gerencia partes em cache do conjunto de dados inteiro para acelerar o desempenho da consulta. Para mais informações, consulte Arquitetura do Snowflake.

A arquitetura do BigQuery é muito diferente das soluções tradicionais de armazenamento de dados em nuvem baseadas em nó ou de sistemas MPP. Isso desacopla o armazenamento e a computação, o que permite que eles sejam escalonados de maneira independente sob demanda. Para mais informações, consulte Por trás do BigQuery.

Comparação da interface do usuário

A interface da Web do Snowflake espelha a interface de linha de comando (CLI, na sigla em inglês) do Snowflake. Ambas as interfaces permitem:

  • Gerenciar bancos de dados;
  • Gerenciar armazenamentos;
  • Gerenciar consultas e planilhas;
  • Ver consultas históricas.

A interface da Web também permite gerenciar a senha do Snowflake e as preferências do usuário.

O cliente da CLI do Snowflake usa o SnowSQL para se conectar ao Snowflake para executar consultas SQL e outras operações.

A interface do BigQuery é integrada ao Console do Google Cloud e contém uma lista de recursos do BigQuery que podem ser visualizados:

  • A seção BigQuery Studio exibe conjuntos de dados, tabelas, visualizações e outros recursos do BigQuery. Nela, é possível criar e executar consultas, trabalhar com tabelas e visualizações, ver o histórico de jobs do BigQuery e realizar outras tarefas comuns do BigQuery.
  • A seção Transferências de dados abre a página do serviço de transferência de dados do BigQuery.
  • A seção Consultas programadas exibe suas consultas programadas.
  • A seção Gerenciamento de capacidade exibe compromissos de slots, reservas e atribuições de reserva.
  • A seção BI Engine abre a página do BigQuery BI Engine.

O BigQuery também tem uma ferramenta de linha de comando baseada em Python. Para mais informações, consulte Como usar a ferramenta de linha de comando bq.

Segurança

Ao migrar do Snowflake para o BigQuery, considere a maneira como o Google Cloud, em geral, e o BigQuery em particular, gerenciam a segurança de forma diferente do Snowflake.

O Snowflake tem vários recursos relacionados à segurança, como:

  • Acesso à rede e ao local;
  • Autenticação de conta e usuário;
  • Segurança de objetos;
  • Segurança de dados
  • Validações de segurança.

A segurança no Snowflake é baseada nos recursos do provedor de nuvem. Ela fornece controle granular sobre o acesso a objetos, operações de objetos e quem pode criar ou alterar as políticas de controle de acesso.

Os privilégios de controle de acesso do BigQuery ao lado do Snowflake são papéis de gerenciamento de identidade e acesso (IAM, na sigla em inglês) no Google Cloud. Esses privilégios determinam as operações permitidas em um recurso. Os privilégios são aplicados no nível do Google Cloud.

Criptografia

No Snowflake, a segurança no nível da coluna é suportada na edição Enterprise, e as chaves de criptografia gerenciadas pelo cliente são suportadas na edição Business Critical. Essas edições têm preços diferentes. No BigQuery, todos os recursos e medidas de segurança reforçada são oferecidos como recursos padrão sem custo adicional.

O Snowflake fornece criptografia de ponta a ponta em que criptografa todos os dados armazenados automaticamente. O Google Cloud fornece o mesmo recurso criptografando por padrão todos os dados em repouso e em trânsito.

Assim como a edição Business Critical do Snowflake, o BigQuery aceita chaves de criptografia gerenciadas pelo cliente para os usuários que querem controlar e gerenciar chaves de criptografia de chaves no Cloud Key Management Service. O BigQuery também permite criptografia em nível de coluna. Para mais informações sobre criptografia no Google Cloud, consulte Criptografia em repouso no Google Cloud e Criptografia em trânsito no Google Cloud.

Papéis

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

O Snowflake suporta estes dois tipos de papéis:

  • Papéis definidos pelo sistema: esses papéis consistem em privilégios relacionados ao sistema e à segurança. Eles são criados com privilégios relacionados ao gerenciamento da conta.
  • Papéis personalizados: é possível criar esses papéis usando os papéis SECURITYADMIN ou qualquer papel que tenha o privilégio CREATE ROLE. Cada papel personalizado no Snowflake é composto de privilégios.

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 console do Google Cloud, a API de gerenciamento de identidade e acesso ou a gcloud CLI. Em geral, para aumentar a segurança, é recomendável usar papéis específicos do BigQuery para seguir o princípio de privilégio mínimo.
  • 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.

Tanto o Snowflake quanto o BigQuery suportam 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 conceder acesso ao conjunto de dados completo.

O Snowflake também usa segurança no nível da linha e segurança no nível da coluna.

No BigQuery, o IAM fornece controle de acesso no nível da tabela. 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.

Aspectos a serem considerados ao migrar

Há alguns recursos do Snowflake que não podem ser transferidos diretamente para o BigQuery. Por exemplo, o BigQuery não oferece suporte integrado para os cenários a seguir. Nesses cenários, talvez seja necessário usar outros serviços no Google Cloud.

  • 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. O Snowflake permite acessar dados históricos (que foram alterados ou excluídos) a qualquer momento dentro de um período definido. Esse período pode ser definido como qualquer valor entre 0 e 90 dias.

  • 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). No Snowflake, um objeto de stream registra alterações de linguagem de manipulação de dados feitas em tabelas e metadados sobre cada alteração para que seja possível agir com os dados alterados.

  • Tarefas: o BigQuery permite programar consultas e fluxos ou integrar o fluxo em consultas com o Datastream. O Snowflake pode combinar tarefas com fluxos de tabelas para fluxos de trabalho de extração, carga e transferência contínuos para processar linhas de tabela alteradas recentemente.

  • Funções externas: o BigQuery aceita chamadas de função externas pelo Cloud Functions. No entanto, 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 não sejam executadas fora do BigQuery. No Snowflake, uma função externa chama um código executado fora do Snowflake. Por exemplo, as informações enviadas para um serviço remoto geralmente são retransmitidas por um serviço de proxy.

Migrar dados do Snowflake para o BigQuery

Nesta seção, descrevemos como configurar e iniciar a migração do Snowflake para o BigQuery com base no framework descrito em Como migrar armazenamentos de dados para o BigQuery: o que e como migrar.

Arquitetura

Para iniciar a migração, execute o Snowflake e o BigQuery. O diagrama a seguir mostra uma arquitetura que afeta minimamente as operações atuais. Ao transferir dados limpos e controlados por qualidade, é possível reutilizar ferramentas e processos atuais enquanto descarrega cargas de trabalho para o BigQuery. Também é possível validar relatórios e painéis em relação a versões antigas. No entanto, como os dados OLAP são mantidos em locais redundantes, essa operação não é econômica. Isso também estende o tempo de processamento.

  • O ponto 1 mostra os dados sendo movidos do Snowflake para o Cloud Storage.
  • O ponto 2 mostra a persistência dos dados no BigQuery.
  • O ponto 3 mostra como os dados são enviados para o usuário final.

É possível validar relatórios e painéis em relação a iterações antigas. Para mais informações, consulte Como migrar armazenamentos de dados para o BigQuery: verificar e validar.

Uma migração em andamento do Snowflake para o BigQuery.

A arquitetura final da migração do armazenamento de dados tem todos os dados dos sistemas de origem diretamente mantidos no Google Cloud. Dependendo da quantidade e complexidade dos sistemas de origem, a implantação desta arquitetura pode ser subdividida de acordo com a prioridade, as interdependências, os riscos de integração ou outros fatores de negócios.

O diagrama a seguir pressupõe a migração de pipelines de dados e ingestão para o Google Cloud.

  • O ponto 1 mostra os pontos de integração síncrono e assíncrono. A integração síncrona é, por exemplo, entre fontes de dados e o App Engine ao lidar com casos de uso que exigem ações explícitas do usuário como parte do fluxo.
  • O ponto 2 mostra o uso do Pub/Sub para grandes volumes de dados de eventos simultâneos.
  • O ponto 3 mostra a persistência de dados usando um ou mais produtos do Google Cloud, dependendo da natureza dos dados.
  • O ponto 4 mostra o processo de extração, transformação e carregamento de dados (ETL, na sigla em inglês) no BigQuery.

Pós-migração do Snowflake para o BigQuery.

Preparar o ambiente do Cloud Storage

O Google Cloud oferece várias maneiras de transferir dados para o BigQuery usando outras ferramentas de ETL. O padrão é o seguinte:

  1. Extrair os dados da origem: copie os arquivos extraídos da origem para o armazenamento de preparo no ambiente local. Para mais informações, consulte Como migrar armazenamentos de dados para o BigQuery: como extrair os dados de origem.

  2. Transferir dados para um bucket temporário do Cloud Storage: depois de extrair dados da origem, transfira-os para um bucket temporário no Cloud Storage. Dependendo da quantidade de dados a ser transferida e da largura de banda da rede disponível, você tem várias opções.

    É importante garantir que o local do conjunto de dados do BigQuery e sua fonte de dados externa ou seu bucket do Cloud Storage estejam na mesma região. Para mais informações sobre considerações de localização geográfica para carregamento de dados do Cloud Storage, consulte Como carregar dados em lote.

  3. Carregar dados do bucket do Cloud Storage no BigQuery: os dados agora estão em um bucket do Cloud Storage, mais próximo do destino. Há várias opções para fazer o upload dos dados no BigQuery. Essas opções dependem de quanto os dados precisam ser transformados. Outra possibilidade é transformar seus dados no BigQuery seguindo a abordagem de ETL.

    Quando você importa dados em massa de um arquivo JSON, Avro ou CSV, o BigQuery detecta o esquema automaticamente. Portanto, não é necessário predefini-lo. Para uma visão geral detalhada do processo de migração de esquema para cargas de trabalho de EDW, consulte Processo de migração de esquema e dados.

Tipos de dados, propriedades e formatos de arquivo suportados

O Snowflake e o BigQuery suportam 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 a seção Tipos de dados da referência de conversão de SQL do Snowflake. Também é possível usar o tradutor de SQL em lote para tradução. Para mais informações sobre os tipos de dados compatíveis do BigQuery, consulte Tipos de dados do GoogleSQL.

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

Alterações de esquema

Se você estiver planejando alterações de esquema na migração para o BigQuery, recomendamos primeiro migrar o esquema como ele está. O BigQuery suporta uma grande variedade de padrões de design de modelo de dados, como o esquema em estrela ou o esquema do Snowflake. Devido a essa compatibilidade, não é necessário atualizar os pipelines de dados upstream para um novo esquema e é possível usar ferramentas de migração automatizadas para transferir dados e esquema.

Como atualizar um esquema

Depois que os dados estiverem no BigQuery, será possível fazer atualizações no esquema, como adicionar colunas à definição do esquema ou relaxar o modo de uma coluna de REQUIRED para NULLABLE.

Lembre-se de que o BigQuery usa convenções de nomenclatura que diferenciam maiúsculas de minúsculas para o nome da tabela, enquanto o Snowflake usa padrões de nomenclatura que não diferenciam maiúsculas de minúsculas. Essa convenção significa que talvez seja necessário revisitar quaisquer inconsistências nas convenções de nomenclatura de tabelas que possam existir no Snowflake e retificar quaisquer inconsistências que surgirem durante a migração para o BigQuery. Para mais informações sobre modificação de esquemas, consulte Como modificar esquemas de tabelas.

Algumas modificações de esquema não são diretamente suportadas no BigQuery e exigem soluções alternativas manuais, como estas:

  • Como alterar o nome de uma coluna.
  • Alterar o tipo de dados de uma coluna.
  • Mudar o modo de uma coluna (exceto para relaxar as colunas REQUIRED para NULLABLE).

Para instruções específicas sobre como implementar manualmente essas alterações de esquema, consulte Alterar esquemas de tabela manualmente.

Otimização

Após a migração do esquema, é possível testar o desempenho e fazer otimizações com base nos resultados. Por exemplo, é possível introduzir o particionamento para tornar os dados mais eficientes para gerenciar e consultar. Particionamento no BigQuery se refere a uma tabela especial que é dividida em segmentos chamados partições. O particionamento é diferente do microparticionamento do Snowflake, que acontece automaticamente quando os dados são carregados. O particionamento do BigQuery permite melhorar o desempenho da consulta e o controle de custos por particionamento por tempo de ingestão, carimbo de data/hora ou intervalo de números inteiros. Para mais informações, consulte Introdução às tabelas particionadas.

Tabelas em cluster

As tabelas em cluster são outra otimização de esquema. O BigQuery, assim como o Snowflake, permite agrupar tabelas, permitindo que você organize automaticamente os dados da tabela com base no conteúdo de uma ou mais colunas no esquema da tabela. O BigQuery usa as colunas que você especificar para colocar dados relacionados. O clustering melhora o desempenho de determinados tipos de consultas, como as que usam cláusulas de filtro e as que agregam dados. Para mais informações sobre como as tabelas em cluster funcionam no BigQuery, consulte Introdução às tabelas em cluster.

Ferramentas de migração

Na lista a seguir, descrevemos as ferramentas que podem ser usadas para migrar dados do Snowflake para o BigQuery. Essas ferramentas são combinadas na seção Exemplos de migração usando pipelines para agrupar pipelines de migração de ponta a ponta.

  • Comando COPY INTO <location>: use esse comando no Snowflake para descarregar 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 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:

  • Serviço de transferência de dados do BigQuery: execute uma transferência automatizada em lote dos dados do Cloud Storage para o BigQuery com este serviço totalmente gerenciado. Essa ferramenta requer que você exporte os dados do Snowflake para o Cloud Storage.
  • gsutil: 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 esta ferramenta de linha de comando. 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.

Exemplos de migração usando pipelines

As seções a seguir mostram exemplos de como migrar seus dados do Snowflake para o BigQuery usando três técnicas diferentes: extrair e carregar, ETL e ferramentas de parceiros.

Extrair e carregar

A técnica de extração e carregamento oferece dois métodos:

  • Usar um pipeline para descarregar dados a partir do Snowflake
  • Usar um pipeline e um driver JDBC para exportar dados a partir do Snowflake

Usar um pipeline para descarregar dados a partir do Snowflake

Para descarregar dados a partir do Snowflake diretamente no Cloud Storage (recomendado) ou fazer o download dos dados e copiá-los para o Cloud Storage usando gsutil ou as bibliotecas de cliente do Cloud Storage, use a ferramenta snowflake2bq para migrar dados usando o comando COPY INTO <location> do Snowflake.

Em seguida, carregue os dados do Cloud Storage no BigQuery com uma das seguintes ferramentas:

  • Serviço de transferência de dados do BigQuery
  • Ferramenta de linha de comando bq
  • Bibliotecas de cliente da API do BigQuery

Usar um pipeline e um driver JDBC para exportar dados a partir do Snowflake

Use qualquer um dos seguintes produtos para exportar dados do Snowflake com o driver JDBC do Snowflake:

Extrair, transformar e carregar

Se você quiser transformar os dados antes de carregá-los no BigQuery, adicione uma etapa de transformação aos pipelines descritos na seção Extrair e carregar anterior.

Transformar dados do Snowflake

Para transformar os dados antes de carregá-los no BigQuery, descarregue os dados diretamente do Snowflake para o Cloud Storage ou use gsutil para copiar os dados, conforme descrito na seção anterior Extrair e carregar.

Carregar dados do Snowflake

Depois de transformar os dados, carregue-os no BigQuery com um dos seguintes métodos:

Usar um pipeline e um driver JDBC para transformar e exportar dados a partir do Snowflake

Adicione uma etapa de transformação nas opções de pipeline a seguir, conforme descrito na seção anterior Extrair e carregar.

É possível ter um caso de uso de extração, carregamento e transformação para carregar os dados do Snowflake no BigQuery e transformá-los. Para executar essa tarefa, carregue os dados do Snowflake em uma tabela de preparo do BigQuery usando um dos métodos na seção Extrair e carregar anterior. Em seguida, execute consultas SQL na tabela de preparo e grave a saída na tabela de produção final no BigQuery.

Ferramentas de parceiros para migração

Há vários fornecedores especializados no espaço de migração de EDW. Para ver uma lista dos principais parceiros e das soluções que eles oferecem, consulte site do parceiro do BigQuery do Google Cloud.

Exemplos do processo de exportação

As seções a seguir mostram um exemplo de exportação de dados do Snowflake para o BigQuery que usa o comando COPY INTO <location> do Snowflake. Para um processo passo a passo detalhado que inclua exemplos de código, consulte a ferramenta de serviços profissionais do Google Cloud Snowflake para BigQuery.

Preparar para exportação

Para descarregar, use as instruções SQL do Snowflake para criar uma especificação de formato de arquivo nomeada (link em inglês).

Neste tutorial, usamos my_parquet_unload_format para o formato de arquivo, mas é possível usar um nome diferente.

   create or replace file format my_parquet_unload_format
     type = 'PARQUET'
     field_delimiter = '|'

Exportar os dados do Snowflake

Depois de preparar os dados, é necessário migrá-los para o Google Cloud. Você pode fazer isso de duas maneiras:

  1. exportando os dados diretamente do Cloud Storage a partir do Snowflake;
  2. preparando os dados do Snowflake em um bucket do Amazon Simple Storage Service (Amazon S3) ou no Azure Blob Storage.

Para evitar um salto de dados extra, exporte os dados diretamente.

Exportar dados do Snowflake diretamente para o Cloud Storage

As instruções a seguir mostram como usar o comando COPY do Snowflake para descarregar dados do Snowflake para o Cloud Storage:

  1. No Snowflake, configure um objeto de integração de armazenamento para permitir que o Snowflake grave em um bucket do Cloud Storage referenciado em um estágio externo do Cloud Storage.

    Esta etapa envolve várias subetapas.

    1. Crie uma integração com o comando CREATE STORAGE INTEGRATION:

      create storage integration gcs_int
  type = external_stage
  storage_provider = gcs
  enabled = true
  storage_allowed_locations = ('gcs://mybucket/unload/')

    2. Recupere a conta de serviço do Cloud Storage para o Snowflake com o comando DESCRIBE INTEGRATION e conceda permissões à conta de serviço para acessar o bucket do Cloud Storage selecionado como área de preparo:

      desc storage integration gcs_int;

      +-----------------------------+---------------+-----------------------------------------------------------------------------+------------------+
| property                    | property_type | property_value                                                              | property_default |
+-----------------------------+---------------+-----------------------------------------------------------------------------+------------------|
| ENABLED                     | Boolean       | true                                                                        | false            |
| STORAGE_ALLOWED_LOCATIONS   | List          | gcs://mybucket1/path1/,gcs://mybucket2/path2/                               | []               |
| STORAGE_BLOCKED_LOCATIONS   | List          | gcs://mybucket1/path1/sensitivedata/,gcs://mybucket2/path2/sensitivedata/   | []               |
| STORAGE_GCP_SERVICE_ACCOUNT | String        | service-account-id@project1-123456.iam.gserviceaccount.com                  |                  |
+-----------------------------+---------------+---------------------------------------------------------
--------------------+------------------+

    3. Crie um estágio externo do Cloud Storage fazendo referência à integração que você criou com o comando CREATE STAGE:

      create or replace stage my_ext_unload_stage
  url='gcs://mybucket/unload'
  storage_integration = gcs_int
  file_format = my_parquet_unload_format;

  2. Use o comando COPY INTO <location> para copiar dados da tabela do banco de dados do Snowflake para um bucket do Cloud Storage especificando o objeto de estágio externo que você criou na etapa anterior:

    copy into @my_ext_unload_stage/d1
from mytable;

Exportar dados do Snowflake para o Cloud Storage usando o Serviço de transferência do Amazon S3

O exemplo a seguir mostra como descarregar dados de uma tabela do Snowflake em um bucket do Amazon S3 usando o comando COPY:

  1. No Snowflake, configure um objeto de integração de armazenamento para permitir que o Snowflake grave em um bucket do Amazon S3 referenciado em um estágio externo do Cloud Storage.

    Nesta etapa, é necessário configurar permissões de acesso no bucket do Amazon S3, criar o papel do IAM da AWS e criar uma integração de armazenamento no Snowflake com o comando CREATE STORAGE INTEGRATION:

    create storage integration s3_int
  type = external_stage
  storage_provider = s3
  enabled = true
  storage_aws_role_arn = 'arn:aws:iam::001234567890:role/myrole'
  storage_allowed_locations = ('s3://unload/files/')

  2. Recupere o usuário do IAM da AWS com o comando DESCRIBE INTEGRATION:

    desc integration s3_int;

    +---------------------------+---------------+================================================================================+------------------+
| property                  | property_type | property_value                                                                 | property_default |
+---------------------------+---------------+================================================================================+------------------|
| ENABLED                   | Boolean       | true                                                                           | false            |
| STORAGE_ALLOWED_LOCATIONS | List          | s3://mybucket1/mypath1/,s3://mybucket2/mypath2/                                | []               |
| STORAGE_BLOCKED_LOCATIONS | List          | s3://mybucket1/mypath1/sensitivedata/,s3://mybucket2/mypath2/sensitivedata/    | []               |
| STORAGE_AWS_IAM_USER_ARN  | String        | arn:aws:iam::123456789001:user/abc1-b-self1234                                 |                  |
| STORAGE_AWS_ROLE_ARN      | String        | arn:aws:iam::001234567890:role/myrole                                          |                  |
| STORAGE_AWS_EXTERNAL_ID   | String        | MYACCOUNT_SFCRole=                                                   |                  |
+---------------------------+---------------+================================================================================+------------------+

  3. Conceda as permissões de usuário do IAM da AWS para acessar o bucket do Amazon S3 e criar um estágio externo com o comando CREATE STAGE:

      create or replace stage my_ext_unload_stage url='s3://unload/files/'
    storage_integration = s3_int
    file_format = my_parquet_unload_format;

  4. Use o comando COPY INTO <location> para copiar os dados do banco de dados do Snowflake para o bucket do Amazon S3 especificando o objeto de estágio externo que você criou anteriormente:

      copy into @my_ext_unload_stage/d1 from mytable;

  5. Transfira os arquivos exportados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.

Exporte dados do Snowflake para o Cloud Storage usando outros provedores de nuvem:

Armazenamento de blobs do Azure Siga as etapas em Como descarregar no Microsoft Azure. Em seguida, transfira os arquivos exportados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.

Bucket do Amazon S3 Siga as etapas detalhadas em Como descarregar no Amazon S3. Em seguida, transfira os arquivos exportados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.

A seguir