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

Rilevamento e mappatura dello schema per Snowflake

Questa guida mostra come definire lo schema durante il trasferimento dei dati da Snowflake a BigQuery. Puoi utilizzare BigQuery Data Transfer Service per rilevare automaticamente lo schema e il mapping dei tipi di dati oppure puoi utilizzare il motore di traduzione per definire manualmente lo schema e i tipi di dati.

Attiva il rilevamento automatico dello schema predefinito

Il connettore Snowflake può rilevare automaticamente lo schema della tabella Snowflake. Per utilizzare il rilevamento automatico dello schema, puoi lasciare vuoto il campo Percorso GCS di output della traduzione quando configuri un trasferimento Snowflake.

Il seguente elenco mostra come il connettore Snowflake esegue il mapping dei tipi di dati Snowflake in BigQuery:

I seguenti tipi di dati vengono mappati come STRING in BigQuery:
- TIMESTAMP_TZ
- TIMESTAMP_LTZ
- OBJECT
- VARIANT
- ARRAY
I seguenti tipi di dati vengono mappati come TIMESTAMP in BigQuery:
- TIMESTAMP_NTZ

Tutti gli altri tipi di dati Snowflake vengono mappati direttamente ai tipi equivalenti in BigQuery.

Definisci manualmente lo schema utilizzando l'output del motore di traduzione

Il connettore BigQuery Data Transfer Service per Snowflake utilizza il motore di traduzione di BigQuery Migration Service per il mapping dello schema durante la migrazione delle tabelle Snowflake in BigQuery.

Per definire manualmente lo schema (ad esempio, per ignorare determinati attributi dello schema), puoi generare i metadati, quindi eseguire il motore di traduzione.

Limitazioni

I dati vengono estratti da Snowflake nel formato dei dati Parquet prima di essere caricati in BigQuery:
- I seguenti tipi di dati Parquet non sono supportati:
  - TIMESTAMP_TZ, TIMESTAMP_LTZ
  - Per ulteriori informazioni, consulta Valutare i dati Snowflake.
- I seguenti tipi di dati Parquet non sono supportati, ma possono essere convertiti:
  - TIMESTAMP_NTZ
  - OBJECT, VARIANT, ARRAY
  Utilizza il file YAML di configurazione della conversione del tipo globale per ignorare il comportamento predefinito di questi tipi di dati quando esegui il motore di traduzione.
  
  Il file YAML di configurazione potrebbe essere simile al seguente esempio:
```
type: experimental_object_rewriter
global:
  typeConvert:
    datetime: TIMESTAMP
    json: VARCHAR
```

Autorizzazioni account di servizio richieste

In un trasferimento Snowflake, un account di servizio viene utilizzato per leggere i dati dall'output del motore di traduzione nel percorso Cloud Storage specificato. Devi concedere all'account di servizio le autorizzazioni storage.objects.get e storage.objects.list.

Ti consigliamo di utilizzare un account di servizio appartenente allo stesso Google Cloud progetto in cui vengono creati la configurazione del trasferimento e il set di dati di destinazione. Se il account di servizio si trova in un progetto Google Cloud diverso da quello che ha creato il trasferimento dati BigQuery, devi attivare l'autorizzazione del account di servizio tra progetti.

Per saperne di più, consulta Ruoli e autorizzazioni IAM di BigQuery.

Definisci manualmente la mappatura dello schema

Per definire manualmente il mapping dello schema:

Esegui dwh-migration-tool per Snowflake. Per saperne di più, consulta Generare metadati per la traduzione e la valutazione.
Carica il file metadata.zip generato in un bucket Cloud Storage. Il file metadata.zip viene utilizzato come input per il motore di traduzione.

Esegui il servizio di traduzione batch, specificando il campo target_types come metadata. Per saperne di più, consulta Tradurre query SQL con l'API Translation.

Di seguito è riportato un esempio di comando per eseguire una traduzione batch per 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

Puoi controllare lo stato di questo comando nella pagina di traduzione SQL in BigQuery. L'output del job di traduzione batch viene archiviato in gs://translation_target_base_uri/metadata/config/.

File di schema personalizzato

Ti consigliamo di specificare uno schema personalizzato se devi acquisire informazioni importanti su una tabella, come la chiave primaria, che altrimenti andrebbero perse durante la migrazione. Ad esempio, quando esegui un trasferimento incrementale, ti consigliamo di specificare un file di schema personalizzato in modo che i dati dei trasferimenti successivi possano essere partizionati correttamente quando vengono caricati in BigQuery. Senza un file di schema, tutte le informazioni su chiavi primarie e monitoraggio delle modifiche possono essere perse, poiché BigQuery Data Transfer Service applica automaticamente uno schema di tabella utilizzando i dati di origine trasferiti.

Lo schema personalizzato può essere utile anche quando devi modificare i nomi delle colonne o i tipi di dati durante il trasferimento dei dati.

Un file di schema personalizzato è un file JSON che descrive gli oggetti del database. Lo schema contiene un insieme di database, ognuno dei quali contiene un insieme di tabelle, ognuna delle quali contiene un insieme di colonne. Ogni oggetto ha un campo originalName che indica il nome dell'oggetto in Snowflake e un campo name che indica il nome di destinazione dell'oggetto in BigQuery.

Le colonne hanno i seguenti campi:

originalType: indica il tipo di dati della colonna in Snowflake
type: indica il tipo di dati di destinazione per la colonna in BigQuery.
usageType: informazioni sul modo in cui la colonna viene utilizzata dal sistema. Sono supportati i seguenti tipi di utilizzo:
- DEFAULT: puoi annotare più colonne in una tabella di destinazione con questo tipo di utilizzo. Il tipo di utilizzo DEFAULT indica che la colonna non ha un utilizzo speciale nel sistema di origine. Questo è il valore predefinito.
- PRIMARY_KEY: puoi annotare le colonne di ogni tabella di destinazione con questo tipo di utilizzo. Utilizza il tipo di utilizzo PRIMARY_KEY per identificare una sola colonna come chiave primaria oppure, nel caso di una chiave composita, utilizza lo stesso tipo di utilizzo su più colonne per identificare le entità univoche di una tabella. Queste colonne funzionano insieme a COMMIT_TIMESTAMP per estrarre le righe create o aggiornate dall'ultima esecuzione del trasferimento.

L'esempio seguente mostra un file dello schema personalizzato per trasferire una tabella Snowflake denominata orders nel database my_db, per rinominare la colonna O_ORDERKEY in ORDERKEY e per identificare O_ORDERSTATUS come chiave primaria.

{
  "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
            }
          ]
        }
      ]
    }
  ]
}