Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Detecção e mapeamento de esquema para o Snowflake

Este guia mostra como definir seu esquema ao transferir dados do Snowflake para o BigQuery. É possível usar o serviço de transferência de dados do BigQuery para detectar automaticamente o mapeamento de esquema e tipo de dados ou usar o mecanismo de tradução para definir manualmente o esquema e os tipos de dados.

Ativar a detecção automática de esquema padrão

O conector do Snowflake pode detectar automaticamente o esquema da tabela do Snowflake. Para usar a detecção automática de esquema, deixe o campo Caminho do GCS de saída da tradução em branco ao configurar uma transferência do Snowflake.

A lista a seguir mostra como o conector do Snowflake mapeia seus tipos de dados do Snowflake para o BigQuery:

Os seguintes tipos de dados são mapeados como STRING no BigQuery:
- TIMESTAMP_TZ
- TIMESTAMP_LTZ
- OBJECT
- VARIANT
- ARRAY
Os seguintes tipos de dados são mapeados como TIMESTAMP no BigQuery:
- TIMESTAMP_NTZ

Todos os outros tipos de dados do Snowflake são mapeados diretamente para os tipos equivalentes no BigQuery.

Definir manualmente o esquema usando a saída do mecanismo de tradução

O conector do serviço de transferência de dados do BigQuery para Snowflake usa o mecanismo de tradução do serviço de migração do BigQuery para mapeamento de esquema ao migrar tabelas do Snowflake para o BigQuery.

Para definir seu esquema manualmente (por exemplo, para substituir determinados atributos de esquema), gere os metadados e execute o mecanismo de tradução.

Limitações

Os dados são extraídos do Snowflake no formato de dados Parquet antes de serem carregados no BigQuery:
- Os seguintes tipos de dados do Parquet não são aceitos:
  - TIMESTAMP_TZ, TIMESTAMP_LTZ
  - Para mais informações, consulte Avaliar dados do Snowflake.
- Os seguintes tipos de dados Parquet não são compatíveis, mas podem ser convertidos:
  - TIMESTAMP_NTZ
  - OBJECT, VARIANT, ARRAY
  Use o YAML de configuração de conversão de tipo global para substituir o comportamento padrão desses tipos de dados ao executar o mecanismo de tradução.
  
  A configuração YAML pode ser semelhante ao exemplo a seguir:
```
type: experimental_object_rewriter
global:
  typeConvert:
    datetime: TIMESTAMP
    json: VARCHAR
```

Permissões necessárias da conta de serviço

Em uma transferência do Snowflake, uma conta de serviço é usada para ler dados da saída do mecanismo de tradução no caminho especificado do Cloud Storage. Você precisa conceder à conta de serviço as permissões storage.objects.get e storage.objects.list.

Recomendamos que a conta de serviço pertença ao mesmo projeto Google Cloud em que a configuração de transferência e o conjunto de dados de destino são criados. Se a conta de serviço estiver em um projeto Google Cloud diferente do projeto que criou a transferência de dados do BigQuery, será necessário ativar a autorização de conta de serviço entre projetos.

Para mais informações, consulte Papéis e permissões do BigQuery IAM.

Definir manualmente o mapeamento de esquema

Para definir manualmente o mapeamento de esquema, siga estas etapas:

Execute o dwh-migration-tool para o Snowflake. Para mais informações, consulte Gerar metadados para tradução e avaliação.
Faça upload do arquivo metadata.zip gerado para um bucket do Cloud Storage. O arquivo metadata.zip é usado como entrada para o mecanismo de tradução.

Execute o serviço de tradução em lote, especificando o campo target_types como metadata. Para mais informações, consulte Traduzir consultas SQL com a API Translation.

Confira um exemplo de comando para executar uma tradução em lote para o Snowflake:

  curl -d "{
  \"name\": \"sf_2_bq_translation\",
  \"displayName\": \"Snowflake to BigQuery Translation\",
  \"tasks\": {
      string: {
        \"type\": \"Snowflake2BigQuery_Translation\",
        \"translation_details\": {
            \"target_base_uri\": \"gs://sf_test_translation/output\",
            \"source_target_mapping\": {
              \"source_spec\": {
                  \"base_uri\": \"gs://sf_test_translation/input\"
              }
            },
            \"target_types\": \"metadata\",
        }
      }
  },
  }" \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/project_id/locations/location/workflows

É possível verificar o status desse comando na página de tradução de SQL no BigQuery. A saída do job de tradução em lote é armazenada em gs://translation_target_base_uri/metadata/config/.

Arquivo de esquema personalizado

Recomendamos especificar um esquema personalizado se você precisar capturar informações importantes sobre uma tabela, como a chave primária, que seriam perdidas na migração. Por exemplo, ao fazer uma transferência incremental, recomendamos especificar um arquivo de esquema personalizado para que os dados das transferências subsequentes possam ser particionados corretamente quando carregados no BigQuery. Sem um arquivo de esquema, todas as informações sobre chaves primárias e controle de alterações podem ser perdidas, já que o serviço de transferência de dados do BigQuery aplica automaticamente um esquema de tabela usando os dados de origem transferidos.

O esquema personalizado também pode ser útil quando você precisa mudar os nomes das colunas ou os tipos de dados durante a transferência de dados.

O arquivo de esquema personalizado é JSON e descreve os objetos do banco de dados. O esquema inclui um conjunto de bancos de dados, cada um com um conjunto de tabelas, cada uma com um conjunto de colunas. Cada objeto tem um campo originalName, que indica o nome do objeto no Snowflake, e um campo name , que indica o nome de destino do objeto no BigQuery.

As colunas têm os seguintes campos:

originalType: indica o tipo de dados da coluna no Snowflake
type: indica o tipo de dados de destino da coluna no BigQuery.
usageType: informações sobre como a coluna é usada pelo sistema. Os seguintes tipos de uso são suportados:
- DEFAULT: é possível anotar várias colunas em uma tabela com esse tipo de uso. O tipo de uso DEFAULT indica que a coluna não tem uso especial no sistema de origem. Esse é o valor padrão.
- PRIMARY_KEY: você pode anotar as colunas em cada tabela de destino com esse tipo de uso. Use o tipo de uso PRIMARY_KEY para identificar apenas uma coluna como a chave primária ou, no caso de uma chave composta, use o mesmo tipo de uso em várias colunas para identificar as entidades únicas de uma tabela. Essas colunas trabalham com COMMIT_TIMESTAMP para extrair linhas criadas ou atualizadas desde a última execução da transferência.

O exemplo a seguir mostra um arquivo de esquema personalizado para transferir uma tabela do Snowflake chamada orders no banco de dados my_db, renomear a coluna O_ORDERKEY para ORDERKEY e identificar O_ORDERSTATUS como a chave primária.

{
  "databases": [
    {
      "name": "my_db",
      "originalName": "my_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "ORDERKEY",
              "originalName": "O_ORDERKEY",
              "type": "INT64",
              "originalType": "NUMERIC",
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERSTATUS",
              "originalName": "O_ORDERSTATUS",
              "type": "STRING",
              "originalType": "VARCHAR",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 1
            }
          ]
        }
      ]
    }
  ]
}