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 la mappatura dello schema e dei tipi di dati oppure puoi utilizzare il motore di traduzione per definire manualmente lo schema e i tipi di dati.

Abilita 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 in che modo il connettore Snowflake mappa i 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 la mappatura dello schema durante la migrazione delle tabelle Snowflake in BigQuery.

Per definire lo schema manualmente (ad esempio, per eseguire l'override di determinati attributi dello schema), puoi generare i metadati e poi 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:

    • I seguenti tipi di dati Parquet non sono supportati, ma possono essere convertiti:

      • TIMESTAMP_NTZ
      • OBJECT, VARIANT, ARRAY

      Utilizza il YAML di configurazione della conversione dei tipi globali per eseguire l'override del 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 del account di servizio richieste

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

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

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

Definisci manualmente la mappatura dello schema

Puoi definire manualmente la mappatura dello schema seguendo questi passaggi:

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

  3. Esegui il servizio di traduzione batch, specificando il campo target_types come metadata. Per saperne di più, consulta Traduci le 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 Traduzione SQL in BigQuery. L'output del job di traduzione batch è 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 sulle chiavi primarie e sul monitoraggio delle modifiche possono andare 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 contengono 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: con questo tipo di utilizzo puoi annotare più colonne in una tabella di destinazione. 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 in ogni tabella di destinazione con questo tipo di utilizzo. Utilizza il tipo di utilizzo PRIMARY_KEY per identificare una sola colonna come chiave primaria o, 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 interagiscono con COMMIT_TIMESTAMP per estrarre le righe create o aggiornate dall'ultima esecuzione del trasferimento.

L'esempio seguente mostra un file di 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
            }
          ]
        }
      ]
    }
  ]
}