ETL reverso do Snowflake para o Spanner usando o BQ

1. Criar um pipeline de ETL reverso do Snowflake para o Spanner usando o Google Cloud Storage e o BigQuery

Introdução

Neste codelab, um pipeline de ETL reverso é criado do Snowflake para o Spanner. Tradicionalmente, os pipelines de ETL (extração, transformação e carregamento) movem dados de bancos de dados operacionais para um data warehouse como o Snowflake para análise. Um pipeline de ETL reverso faz o contrário: ele move dados tratados e processados do data warehouse de volta para sistemas operacionais, onde podem alimentar aplicativos, veicular recursos voltados ao usuário ou ser usados para tomada de decisões em tempo real.

O objetivo é mover um conjunto de dados agregados de uma tabela do Snowflake Iceberg para o Spanner, um banco de dados relacional distribuído globalmente ideal para aplicativos de alta disponibilidade.

Para isso, o Google Cloud Storage (GCS) e o BigQuery são usados como etapas intermediárias. Confira um resumo do fluxo de dados e o raciocínio por trás dessa arquitetura:

1. Snowflake para Google Cloud Storage (GCS) no formato Iceberg:

• A primeira etapa é extrair os dados do Snowflake em um formato aberto e bem definido. A tabela é exportada no formato Apache Iceberg. Esse processo grava os dados subjacentes como um conjunto de arquivos Parquet e os metadados da tabela (esquema, partições, locais de arquivos) como arquivos JSON e Avro. Ao armazenar essa estrutura completa de tabela no GCS, os dados ficam portáteis e acessíveis a qualquer sistema que entenda o formato Iceberg.

2. Converter tabelas do Iceberg no GCS em tabelas externas do BigLake no BigQuery:

• Em vez de carregar os dados diretamente do GCS para o Spanner, o BigQuery é usado como um intermediário eficiente. Você vai criar uma tabela externa do BigLake no BigQuery que aponta diretamente para o arquivo de metadados do Iceberg no GCS. Essa abordagem tem várias vantagens:
• Sem duplicação de dados:o BigQuery lê a estrutura da tabela nos metadados e consulta os arquivos de dados do Parquet no local sem ingerir, o que economiza muito tempo e custos de armazenamento.
• Consultas federadas:permite executar consultas SQL complexas em dados do GCS como se fosse uma tabela nativa do BigQuery.

3. BigQuery para Spanner:

• A etapa final é mover os dados do BigQuery para o Spanner. Você vai fazer isso usando um recurso avançado do BigQuery chamado consulta EXPORT DATA, que é a etapa de "ETL reversa".
• Prontidão operacional:o Spanner foi projetado para cargas de trabalho transacionais, oferecendo consistência forte e alta disponibilidade para aplicativos. Ao mover os dados para o Spanner, eles ficam acessíveis a aplicativos voltados ao usuário, APIs e outros sistemas operacionais que exigem pesquisas pontuais de baixa latência.
• Escalonabilidade:esse padrão permite aproveitar o poder analítico do BigQuery para processar grandes conjuntos de dados e veicular os resultados de maneira eficiente pela infraestrutura globalmente escalonável do Spanner.

Serviços e terminologia

• Snowflake: uma plataforma de dados em nuvem que oferece um data warehouse como serviço.
• Spanner: um banco de dados relacional totalmente gerenciado e distribuído globalmente.
• Google Cloud Storage: oferta de armazenamento de blobs do Google Cloud.
• BigQuery: um data warehouse sem servidor totalmente gerenciado para análises.
• Iceberg: um formato de tabela aberta definido pelo Apache que oferece abstração em formatos de arquivo de dados de código aberto comuns.
• Parquet: um formato de arquivo de dados binários colunares de código aberto do Apache.

O que você vai aprender

• Como carregar dados no Snowflake
• Como criar um bucket do GCS
• Como exportar uma tabela do Snowflake para o GCS no formato Iceberg
• Como configurar uma instância do Spanner
• Como carregar tabelas externas do BigLake no BigQuery para o Spanner

2. Configuração, requisitos e limitações

Pré-requisitos

• Uma conta do Snowflake
• É necessário ter uma conta do Google Cloud com uma reserva de nível Enterprise ou superior do BigQuery para exportar do BigQuery para o Spanner.
• Acesso ao console do Google Cloud por um navegador da Web
• Um terminal para executar comandos da Google Cloud CLI
• Se a organização do Google Cloud tiver a política iam.allowedPolicyMemberDomains ativada, um administrador talvez precise conceder uma exceção para permitir contas de serviço de domínios externos. Isso será abordado em uma etapa posterior, quando aplicável.

Limitações

É importante estar ciente de algumas limitações e incompatibilidades de tipo de dados que podem surgir nesse pipeline.

Snowflake para Iceberg

Os tipos de dados de coluna são diferentes entre o Snowflake e o Iceberg. Informações sobre a tradução entre eles estão disponíveis na documentação do Snowflake (em inglês).

Iceberg para o BigQuery

Ao usar o BigQuery para consultar tabelas Iceberg, há algumas limitações. Para uma lista completa, consulte a documentação do BigQuery. No momento, não há suporte para tipos como BIGNUMERIC, INTERVAL, JSON, RANGE ou GEOGRAPHY.

BigQuery para Spanner

O comando EXPORT DATA do BigQuery para o Spanner não é compatível com todos os tipos de dados do BigQuery. A exportação de uma tabela com os seguintes tipos vai resultar em um erro:

• STRUCT
• GEOGRAPHY
• DATETIME
• RANGE
• TIME

Além disso, se o projeto do BigQuery estiver usando o dialeto GoogleSQL, os seguintes tipos numéricos também não serão compatíveis com a exportação para o Spanner:

• BIGNUMERIC

Para uma lista completa e atualizada de limitações, consulte a documentação oficial: Limitações da exportação para o Spanner.

Snowflake

Para este codelab, você pode usar uma conta do Snowflake ou configurar uma conta de teste sem custo financeiro.

Permissões do IAM no Google Cloud Platform

A Conta do Google precisa das seguintes permissões para executar todas as etapas deste codelab.

Contas de serviço
iam.serviceAccountKeys.create	Permite a criação de contas de serviço.
Spanner
spanner.instances.create	Permite criar uma nova instância do Spanner.
spanner.databases.create	Permite executar instruções DDL para criar
spanner.databases.updateDdl	Permite executar instruções DDL para criar tabelas no banco de dados.
Google Cloud Storage
storage.buckets.create	Permite criar um bucket do GCS para armazenar os arquivos Parquet exportados.
storage.objects.create	Permite gravar os arquivos Parquet exportados no bucket do GCS.
storage.objects.get	Permite que o BigQuery leia os arquivos Parquet do bucket do GCS.
storage.objects.list	Permite que o BigQuery liste os arquivos Parquet no bucket do GCS.
Dataflow
Dataflow.workitems.lease	Permite reivindicar itens de trabalho do Dataflow.
Dataflow.workitems.sendMessage	Permite que o worker do Dataflow envie mensagens de volta para o serviço do Dataflow.
Logging.logEntries.create	Permite que os workers do Dataflow gravem entradas de registro no Google Cloud Logging.

Para sua conveniência, é possível usar papéis predefinidos que contêm essas permissões.

roles/resourcemanager.projectIamAdmin

roles/iam.serviceAccountKeyAdmin

roles/spanner.instanceAdmin

roles/spanner.databaseAdmin

roles/storage.admin

roles/dataflow.serviceAgent

roles/dataflow.worker

roles/dataflow.serviceAgent

Configurar propriedades reutilizáveis

Alguns valores serão necessários repetidamente ao longo deste laboratório. Para facilitar, vamos definir esses valores como variáveis de shell para serem usadas mais tarde.

• GCP_REGION: a região específica em que os recursos do GCP vão estar localizados. Confira a lista de regiões aqui.
• GCP_PROJECT: o ID do projeto do GCP a ser usado.
• GCP_BUCKET_NAME: o nome do bucket do GCS a ser criado e onde os arquivos de dados serão armazenados.

Os nomes dos intervalos precisam ser exclusivos globalmente. Um padrão comum é: [organization_name]-[project_id]-[environment]-[purpose].

export GCP_REGION = <GCP REGION HERE> 
export GCP_PROJECT= <GCP PROJECT HERE>
export GCS_BUCKET_NAME = <GCS BUCKET NAME HERE>
export SPANNER_INSTANCE = <SPANNER INSTANCE ID HERE>
export SPANNER_DB = <SPANNER DATABASE ID HERE>

Essas variáveis de ambiente só serão definidas na instância do shell em que forem executadas. Se você executar os comandos deste laboratório em outra instância do shell mais tarde, elas precisarão ser definidas novamente.

Projeto do Google Cloud

Um projeto é uma unidade básica de organização no Google Cloud. Se um administrador tiver fornecido um para uso, essa etapa poderá ser ignorada.

Um projeto pode ser criado usando a CLI desta forma:

gcloud projects create $GCP_PROJECT
gcloud config set project $GCP_PROJECT

Saiba mais sobre como criar e gerenciar projetos aqui.

Configurar o Spanner

Para começar a usar o Spanner, é necessário provisionar uma instância e um banco de dados. Confira detalhes sobre como configurar e criar uma instância do Spanner aqui.

Criar a instância

gcloud spanner instances create $SPANNER_INSTANCE \
--config=regional-$GCP_REGION \
--description="Codelabs Snowflake RETL" \
--processing-units=100 \
--edition=ENTERPRISE

Criar o banco de dados

gcloud spanner databases create $SPANNER_DB \
--instance=$SPANNER_INSTANCE

3. Criar um bucket do Google Cloud Storage.

O Google Cloud Storage (GCS) será usado para armazenar os arquivos de dados Parquet e os metadados do Iceberg gerados pelo Snowflake. Para isso, primeiro crie um bucket para usar como destino do arquivo. Em uma janela de terminal em uma máquina local, siga estas etapas.

Criar o bucket

Use o comando a seguir para criar um bucket de armazenamento em uma região específica (por exemplo, us-central1).

gcloud storage buckets create gs://$GCS_BUCKET_NAME --location=$GCP_REGION

Verificar a criação do bucket

Depois que o comando for executado, confira o resultado listando todos os buckets. O novo bucket vai aparecer na lista resultante. As referências de bucket geralmente aparecem com o prefixo gs:// antes do nome do bucket.

gcloud storage ls | grep gs://$GCS_BUCKET_NAME

Testar permissões de gravação

Essa etapa garante que o ambiente local esteja autenticado corretamente e tenha as permissões necessárias para gravar arquivos no bucket recém-criado.

echo "Hello, GCS" | gcloud storage cp - gs://$GCS_BUCKET_NAME/hello.txt

Verificar o arquivo enviado

Liste os objetos no bucket. O caminho completo do arquivo que acabou de ser enviado por upload vai aparecer.

gcloud storage ls gs://$GCS_BUCKET_NAME

Você verá esta resposta:

gs://$GCS_BUCKET_NAME/hello.txt

Para ver o conteúdo de um objeto em um bucket, use gcloud storage cat.

gcloud storage cat gs://$GCS_BUCKET_NAME/hello.txt

O conteúdo do arquivo precisa estar visível:

Hello, GCS

Limpar o arquivo de teste

O bucket do Cloud Storage está configurado. Agora é possível excluir o arquivo de teste temporário.

gcloud storage rm gs://$GCS_BUCKET_NAME/hello.txt

A saída precisa confirmar a exclusão:

Removing gs://$GCS_BUCKET_NAME/hello.txt...
/ [1 objects]
Operation completed over 1 objects.

4. Exportar do Snowflake para o GCS

Neste laboratório, você vai usar o conjunto de dados TPC-H, que é uma referência padrão do setor para sistemas de suporte a decisões. O esquema dele modela um ambiente de negócios realista com clientes, pedidos, fornecedores e peças, o que o torna perfeito para demonstrar um cenário real de análise e movimentação de dados. Esse conjunto de dados está disponível por padrão em todas as contas do Snowflake.

Em vez de usar as tabelas TPC-H brutas e normalizadas, você vai criar uma nova tabela agregada. Essa nova tabela vai combinar dados das tabelas orders, customer e nation para produzir uma visualização desnormalizada e resumida dos totais de vendas nacionais. Essa etapa de pré-agregação é uma prática comum na análise, já que prepara os dados para um caso de uso específico. Neste cenário, para consumo por um aplicativo operacional.

Permitir que o Snowflake acesse o Google Cloud Storage

Para permitir que o Snowflake grave dados no bucket do GCS, é preciso criar duas coisas: um volume externo e as permissões necessárias.

• Um volume externo é um objeto do Snowflake que fornece um link seguro para um local específico em um bucket do GCS. Ele não armazena dados, mas contém a configuração necessária para que o Snowflake acesse o armazenamento na nuvem.
• Por segurança, os buckets de armazenamento em nuvem são particulares por padrão. Quando um volume externo é criado, o Snowflake gera uma conta de serviço dedicada. Essa conta de serviço precisa ter permissões para ler e gravar no bucket.

Criar um banco de dados

1. No menu à esquerda, em Catálogo do Horizon, passe o cursor sobre Catálogo e clique em Explorador de banco de dados.
2. Na página Bancos de dados, clique no botão + Banco de dados no canto superior direito.
3. Nomeie o novo banco de dados como codelabs_retl_db.

Criar uma planilha

Para executar comandos SQL no banco de dados, são necessárias planilhas.

Para criar uma planilha:

1. No menu à esquerda, em Trabalhar com dados, passe o cursor sobre Projetos e clique em Espaços de trabalho.
2. Na barra lateral Meus espaços de trabalho, clique no botão + Adicionar novo e selecione Arquivo SQL.

Todos os outros comandos SQL para o Snowflake podem ser executados substituindo o conteúdo desse arquivo. Para executar partes de um parágrafo do arquivo, coloque o cursor sobre ele e pressione Ctrl + Enter no teclado.

Criar um volume externo

Execute o comando a seguir em uma planilha do Snowflake para criar o volume.

O Snowflake usa um prefixo gcs:// para caminhos do Google Cloud Storage, não gs://.

Como o código SQL a seguir não será executado como parte da instância do shell com as variáveis de ambiente definidas, substitua os valores do nome do bucket do GCS onde ele aparecer.

CREATE EXTERNAL VOLUME codelabs_retl_ext_vol
STORAGE_LOCATIONS = 
(
  (
    NAME = 'codelabs_retl_ext_vol'
    STORAGE_PROVIDER = 'GCS'
    STORAGE_BASE_URL = 'gcs://<Your bucket name>/snowflake_extvol'
  )
); 

Acessar a conta de serviço do Snowflake

DESC (descreva) o volume externo recém-criado para receber a conta de serviço exclusiva que o Snowflake gerou para ele.

DESC EXTERNAL VOLUME codelabs_retl_ext_vol;

1. No painel de resultados, procure as propriedades JSON e encontre a entrada property_value que contém uma string JSON começando com "NAME":"codelabs_retl_ext_vol".
2. Encontre a propriedade STORAGE_GCP_SERVICE_ACCOUNT no objeto JSON e copie o valor dela (parece um endereço de e-mail). É o identificador da conta de serviço que precisa de acesso ao bucket do GCS.
3. Armazene essa conta de serviço em uma variável de ambiente na sua instância de shell para reutilização posterior.

export GCP_SERVICE_ACCOUNT=<Your service account>

Observação: se a organização do Google Cloud aplicar a restrição iam.allowedPolicyMemberDomains, o administrador de segurança precisará adicionar o domínio dessa conta de serviço (a parte depois do símbolo @) à lista de permissões.

Conceder permissões do GCS ao Snowflake

Agora, a conta de serviço do Snowflake precisa receber permissão para gravar no bucket do GCS.

gcloud storage buckets add-iam-policy-binding gs://$GCS_BUCKET_NAME \
    --member="serviceAccount:$GCP_SERVICE_ACCOUNT" \
    --role="roles/storage.objectAdmin"

gcloud storage buckets add-iam-policy-binding gs://$GCS_BUCKET_NAME \
    --member="serviceAccount:$GCP_SERVICE_ACCOUNT" \
    --role="roles/storage.legacyBucketReader"

Verificar o acesso no Snowflake

De volta à planilha do Snowflake, execute este comando para verificar se o Snowflake agora pode se conectar ao bucket do GCS.

SELECT SYSTEM$VERIFY_EXTERNAL_VOLUME('codelabs_retl_ext_vol');

O resultado precisa ser um objeto JSON contendo "success":true.

Para mais informações sobre volumes externos no Snowflake, consulte a documentação oficial.

Exportar dados de pedidos de amostra

Agora você pode criar uma tabela Iceberg no Snowflake. O comando a seguir instrui o Snowflake a executar uma consulta e armazenar os resultados no GCS usando o formato Iceberg. Os arquivos de dados serão Parquet, e os metadados serão Avro e JSON, todos armazenados no local definido pelo volume externo codelabs_retl_ext_vol.

Criar um banco de dados

1. No menu à esquerda, em Catálogo do Horizon, passe o cursor sobre Catálogo e clique em Explorador de banco de dados.
2. Na página Bancos de dados, clique no botão + Banco de dados no canto superior direito.
3. Nomeie o novo banco de dados como codelabs_retl_db.

USE DATABASE codelabs_retl_db; 

CREATE ICEBERG TABLE REGIONAL_SALES_ICEBERG (
    NATION_NAME STRING,
    MARKET_SEGMENT STRING,
    ORDER_YEAR INTEGER,
    ORDER_PRIORITY STRING,
    TOTAL_ORDER_COUNT INTEGER,
    TOTAL_REVENUE NUMBER(24,2),
    UNIQUE_CUSTOMER_COUNT INTEGER
) 
EXTERNAL_VOLUME = 'codelabs_retl_ext_vol'
CATALOG = 'SNOWFLAKE'
BASE_LOCATION = 'regional_sales_iceberg'
AS (
    SELECT 
        n.n_name AS nation_name,
        c.c_mktsegment AS market_segment,
        YEAR(o.o_orderdate) AS order_year,
        o.o_orderpriority AS order_priority,
        COUNT(o.o_orderkey) AS total_order_count,
        ROUND(SUM(o.o_totalprice), 2) AS total_revenue,
        COUNT(DISTINCT c.c_custkey) AS unique_customer_count
    FROM SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.orders AS o
    INNER JOIN SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.customer AS c 
        ON o.o_custkey = c.c_custkey
    INNER JOIN SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.nation AS n
        ON c.c_nationkey = n.n_nationkey
    GROUP BY 
        n.n_name, 
        c.c_mktsegment, 
        YEAR(o.o_orderdate), 
        o.o_orderpriority
);

Para mais informações sobre como criar e gerenciar tabelas do Iceberg usando o Snowflake, consulte a documentação oficial.

Verificar dados no GCP

Agora verifique o bucket do GCS. Os arquivos criados pelo Snowflake vão aparecer. Isso confirma que a exportação foi bem-sucedida. Os metadados do Iceberg estão na pasta metadata, e os dados reais estão como arquivos Parquet na pasta data.

gcloud storage ls "gs://$GCS_BUCKET_NAME/snowflake_extvol/**"

Os nomes dos arquivos variam, mas a estrutura deve ser assim:

gs://$GCS_BUCKET_NAME/snowflake_extvol/
gs://$GCS_BUCKET_NAME/snowflake_extvol/regional_sales_iceberg.snvrAWuR/data/snow_cbsKIRmdDmo_wLg128fugxg_0_2_009.parquet
...
gs://$GCS_BUCKET_NAME/snowflake_extvol/regional_sales_iceberg.snvrAWuR/metadata/00001-62f831ff-6708-4494-94c5-c891b7ad447f.metadata.json
...

Os dados foram copiados do Snowflake para o Google Cloud Storage no formato Iceberg.

Enquanto temos essa lista, vamos salvar o arquivo metadata.json em uma variável de ambiente, porque vamos precisar dele mais tarde.

export GCS_METADATA_JSON=$(gcloud storage ls "gs://$GCS_BUCKET_NAME/snowflake_extvol/**" | grep .metadata.json)

5. Configurar uma tabela externa do BigQuery

Agora que a tabela do Iceberg está no Google Cloud Storage, a próxima etapa é torná-la acessível ao BigQuery. Isso pode ser feito criando uma tabela externa do BigLake.

O BigLake é um mecanismo de armazenamento que permite criar tabelas no BigQuery que leem dados diretamente de fontes externas, como o Google Cloud Storage. Neste laboratório, essa é a tecnologia principal que permite ao BigQuery entender a tabela do Iceberg recém-exportada sem precisar ingerir os dados.

Para isso, são necessários dois componentes:

1. Uma conexão de recursos do Cloud:um link seguro entre o BigQuery e o GCS. Ele usa uma conta de serviço especial para processar a autenticação, garantindo que o BigQuery tenha as permissões necessárias para ler os arquivos do bucket do GCS.
2. Uma definição de tabela externa:informa ao BigQuery onde encontrar o arquivo de metadados da tabela Iceberg no GCS e como ele deve ser interpretado.

Configurar uma conexão com o Google Cloud Storage

Primeiro, a conexão que permite ao BigQuery acessar o GCS será criada. Esse comando cria um recurso de conexão no BigQuery.

bq mk \
  --connection \
  --project_id=$GCP_PROJECT \
  --location=$GCP_REGION \
  --connection_type=CLOUD_RESOURCE \
  codelabs-retl-connection

O sucesso será parecido com isto:

Connection 12345678.region.codelabs-retl-connection successfully created

Para mais informações sobre as conexões de recursos do Cloud no BigQuery, consulte a documentação do Google Cloud.

Autorizar a conexão do BigQuery a ler dados

A nova conexão do BigQuery tem uma conta de serviço própria que precisa de permissão para ler dados do bucket do Google Cloud Storage.

1. Receber a conta de serviço de conexão

Primeiro, receba o ID da conta de serviço da conexão recém-criada:

bq show \
  --location $GCP_REGION \
  --connection codelabs-retl-connection

Os resultados vão mostrar uma tabela de conexões correspondentes.

Vamos definir serviceAccountId como uma variável de ambiente para uso posterior.

export GCP_BQ_SERVICE_ACCOUNT=<Your service account email>

2. Conceder permissões

Execute o comando a seguir para autorizar a conta de serviço a acessar os dados no bucket do GCS.

gcloud storage buckets add-iam-policy-binding \
  gs://$GCS_BUCKET_NAME \
  --member serviceAccount:$GCP_BQ_SERVICE_ACCOUNT \
  --role roles/storage.objectViewer

Criar a tabela externa

Agora, crie a tabela externa do BigLake no BigQuery. Esse comando não move nenhum dado. Ele apenas cria um ponteiro para os dados atuais no GCS. Você vai precisar do caminho para um dos arquivos .metadata.json criados pelo Snowflake.

Substitua o valor external_table_definition pelo caminho adequado para o arquivo metadata.json no comando a seguir.

Verifique se a tabela foi criada na mesma região da conexão da etapa anterior.

bq mk --dataset --location=$GCP_REGION codelabs_retl

bq mk \
    --table \
    --location=$GCP_REGION \
--external_table_definition=ICEBERG=$GCS_METADATA_JSON@projects/$GCP_PROJECT/locations/$GCP_REGION/connections/codelabs-retl-connection \
    codelabs_retl.regional_sales

Verificar dados no BigQuery

Agora, essa tabela pode ser consultada usando o SQL padrão, assim como qualquer outra tabela do BigQuery. O BigQuery vai usar a conexão para ler os arquivos Parquet do GCS de maneira dinâmica.

bq query \
  --location=$GCP_REGION \
  --nouse_legacy_sql "SELECT * FROM \`$GCP_PROJECT.codelabs_retl.regional_sales\` LIMIT 10;"

6. Importar dados do BigQuery para o Spanner: a etapa final

A parte final e mais importante do pipeline foi alcançada: mover os dados da tabela do BigLake para o Spanner. Esta é a etapa de "ETL reverso", em que os dados, depois de processados e organizados no data warehouse, são carregados em um sistema operacional para uso por aplicativos.

O Spanner é um banco de dados relacional totalmente gerenciado e distribuído globalmente. Ele oferece a consistência transacional de um banco de dados relacional tradicional, mas com a escalonabilidade horizontal de um banco de dados NoSQL. Isso o torna uma opção ideal para criar aplicativos escalonáveis e altamente disponíveis.

O processo será:

1. Crie um esquema de tabela no banco de dados do Spanner que corresponda à estrutura dos dados.
2. Execute uma consulta EXPORT DATA do BigQuery para carregar os dados da tabela do BigLake diretamente na tabela do Spanner.

Criar a tabela do Spanner

Antes de transferir dados do BigQuery, é necessário criar uma tabela de destino no Spanner com um esquema compatível.

gcloud spanner databases ddl update $SPANNER_DB \
  --instance=$SPANNER_INSTANCE \
  --ddl="$(cat <<EOF
CREATE TABLE regional_sales (
    nation_name STRING(MAX),
    market_segment STRING(MAX),
    order_year INT64,
    order_priority STRING(MAX),
    total_order_count INT64,
    total_revenue NUMERIC,
    unique_customer_count INT64
) PRIMARY KEY (nation_name, market_segment, order_year, order_priority);
EOF
)"

Exportar dados do BigQuery

Esta é a etapa final. Com os dados de origem prontos em uma tabela BigLake do BigQuery e a tabela de destino criada no Spanner, a movimentação de dados real é surpreendentemente simples. Uma única consulta SQL do BigQuery será usada: EXPORT DATA.

Essa consulta foi criada especificamente para cenários como esse. Ele exporta dados de uma tabela do BigQuery (incluindo externas, como a tabela do BigLake) para um destino externo de maneira eficiente. Nesse caso, o destino é a tabela do Spanner.

bq query --location=$GCP_REGION --use_legacy_sql=false <<EOF
EXPORT DATA OPTIONS (
uri="https://spanner.googleapis.com/projects/${GCP_PROJECT}/instances/${SPANNER_INSTANCE}/databases/${SPANNER_DB}",
  format='CLOUD_SPANNER',
  spanner_options="""{ 
      "table": "regional_sales", 
      "priority": "HIGH" 
      }"""
) AS 
SELECT * FROM \`${PROJECT_ID}.codelabs_retl.regional_sales\`
EOF

Quando a consulta terminar, o painel "Resultados" vai mostrar "Atualização concluída".

7. Verificar dados no Spanner

Parabéns! Um pipeline completo de ETL reverso foi criado e executado com sucesso. A última etapa é verificar se os dados chegaram ao Spanner conforme o esperado.

gcloud spanner databases execute-sql \
  --instance=$SPANNER_INSTANCE \
  $SPANNER_DB \
  --sql='SELECT * FROM regional_sales LIMIT 10'

Os dados de amostra importados aparecem conforme solicitado:

nation_name  market_segment  order_year  order_priority   total_order_count  total_revenue  unique_customer_count
ALGERIA      AUTOMOBILE      1992        1-URGENT         375                59232423.66    298
ALGERIA      AUTOMOBILE      1992        2-HIGH           328                47371891.08    269
ALGERIA      AUTOMOBILE      1992        3-MEDIUM         346                52823195.87    262
ALGERIA      AUTOMOBILE      1992        4-NOT SPECIFIED  365                52935998.34    288
ALGERIA      AUTOMOBILE      1992        5-LOW            380                54920263.68    293
ALGERIA      AUTOMOBILE      1993        1-URGENT         394                63145618.78    312
ALGERIA      AUTOMOBILE      1993        2-HIGH           340                50737488.4     277
ALGERIA      AUTOMOBILE      1993        3-MEDIUM         383                55871057.46    298
ALGERIA      AUTOMOBILE      1993        4-NOT SPECIFIED  365                56424662.05    291
ALGERIA      AUTOMOBILE      1993        5-LOW            363                54673249.06    283

A distância entre os mundos de dados analíticos e operacionais foi reduzida.

8. Limpeza

Limpar o Spanner

Excluir o banco de dados e a instância do Spanner

gcloud spanner instances delete $SPANNER_INSTANCE

Limpar o GCS

Excluir o bucket do GCS criado para hospedar os dados

gcloud storage rm --recursive gs://$GCS_BUCKET_NAME

Limpar o BigQuery

bq rm -r codelabs_retl
bq rm --connection --location=$GCP_REGION codelabs-retl-connection

Limpar o Snowflake

Remova o banco de dados

1. No menu à esquerda, em Catálogo do Horizon, passe o cursor sobre Catálogo e clique em Explorador de banco de dados.
2. Clique em ... à direita do banco de dados CODELABS_RETL_DB para abrir as opções e selecione Descartar.
3. Na caixa de diálogo de confirmação que aparece, selecione Excluir banco de dados.

Excluir pastas de trabalho

4. No menu à esquerda, em Trabalhar com dados, passe o cursor sobre Projetos e clique em Espaços de trabalho.
5. Na barra lateral Meu espaço de trabalho, passe o cursor sobre os diferentes arquivos do espaço de trabalho usados neste laboratório para mostrar as opções adicionais ... e clique nelas.
6. Selecione Excluir e depois Excluir novamente na caixa de diálogo de confirmação que aparece.
7. Faça isso para todos os arquivos do espaço de trabalho SQL criados para este laboratório.

Excluir volumes externos

8. No menu à esquerda, em Catálogo do Horizon, passe o cursor sobre Catálogo e clique em Dados externos.
9. Clique em à direita de CODELABS_RETL_EXT_VOL, selecione Soltar volume externo e clique novamente em Soltar volume externo na caixa de diálogo de confirmação.

9. Parabéns

Parabéns por concluir o codelab.

O que aprendemos

• Como carregar dados no Snowflake
• Como criar um bucket do GCS
• Como exportar uma tabela do Snowflake para o GCS no formato CSV
• Como configurar uma instância do Spanner
• Como carregar tabelas CSV no Spanner com o Dataflow