O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Detecção e mapeamento de esquemas para o Snowflake

Neste guia, mostramos como definir o 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 esquemas e tipos de dados ou usar o mecanismo de tradução para definir manualmente os esquemas e 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 os tipos de dados do Snowflake no 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 o esquema manualmente 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 esquemas ao migrar tabelas do Snowflake para o BigQuery.

Para definir o 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 compatíveis:
  - TIMESTAMP_TZ, TIMESTAMP_LTZ
  - Para mais informações, consulte Avaliar dados do Snowflake.
- Os seguintes tipos de dados do 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.
  
  O YAML de configuração pode ser semelhante ao seguinte exemplo:
```
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 do 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 do Google Cloud diferente daquele que criou a transferência de dados do BigQuery, será necessário ativar a autorização da conta de serviço entre projetos.

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

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 de tradução.

Veja a seguir 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/v2/projects/project_id/locations/location/workflows

Verifique o status desse comando na página de tradução do 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 sejam particionados corretamente quando carregados no BigQuery. Sem um arquivo de esquema, todas as informações sobre chaves primárias e rastreamento 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 deles tem um conjunto de tabelas com um grupo de colunas. Cada objeto tem um campo originalName, que indica o nome do objeto no Snowflake, e um campo name, que indica o nome do 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 como 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
            }
          ]
        }
      ]
    }
  ]
}