Détection et mappage de schémas pour Snowflake

Ce guide vous explique comment définir votre schéma lorsque vous transférez des données de Snowflake vers BigQuery. Vous pouvez utiliser le service de transfert de données BigQuery pour détecter automatiquement le schéma et le mappage des types de données, ou utiliser le moteur de traduction pour définir manuellement votre schéma et vos types de données.

Activer la détection automatique du schéma par défaut

Le connecteur Snowflake peut détecter automatiquement le schéma de votre table Snowflake. Pour utiliser la détection automatique de schéma, vous pouvez laisser le champ Chemin d'accès GCS de sortie de la traduction vide lorsque vous configurez un transfert Snowflake.

La liste suivante montre comment le connecteur Snowflake mappe vos types de données Snowflake dans BigQuery :

  • Les types de données suivants sont mappés en tant que STRING dans BigQuery :
    • TIMESTAMP_TZ
    • TIMESTAMP_LTZ
    • OBJECT
    • VARIANT
    • ARRAY
  • Les types de données suivants sont mappés en tant que TIMESTAMP dans BigQuery :
    • TIMESTAMP_NTZ

Tous les autres types de données Snowflake sont mappés directement avec leurs types équivalents dans BigQuery.

Définir manuellement le schéma à l'aide de la sortie du moteur de traduction

Le connecteur du service de transfert de données BigQuery pour Snowflake utilise le moteur de traduction du service de migration BigQuery pour le mappage de schéma lors de la migration de tables Snowflake vers BigQuery.

Pour définir votre schéma manuellement (par exemple, pour remplacer certains attributs de schéma), vous pouvez générer vos métadonnées, puis exécuter le moteur de traduction.

Limites

  • Les données sont extraites de Snowflake au format de données Parquet avant d'être chargées dans BigQuery :

    • Les types de données Parquet suivants ne sont pas compatibles :
    • Les types de données Parquet suivants ne sont pas compatibles, mais peuvent être convertis :

      • TIMESTAMP_NTZ
      • OBJECT, VARIANT, ARRAY

      Utilisez le fichier YAML de configuration de conversion de type global pour remplacer le comportement par défaut de ces types de données lorsque vous exécutez le moteur de traduction.

      Le fichier YAML de configuration peut ressembler à l'exemple suivant :

      type: experimental_object_rewriter
      global:
        typeConvert:
          datetime: TIMESTAMP
          json: VARCHAR
      

Autorisations de compte de service requises

Dans un transfert Snowflake, un compte de service est utilisé pour lire les données de la sortie du moteur de traduction dans le chemin d'accès Cloud Storage spécifié. Vous devez accorder au compte de service les autorisations storage.objects.get et storage.objects.list.

Nous vous recommandons d'utiliser un compte de service appartenant au même projet Google Cloud que celui où la configuration de transfert et l'ensemble de données de destination sont créés. Si le compte de service se trouve dans un projet Google Cloud différent de celui qui a créé le transfert de données BigQuery, vous devez activer l'autorisation de compte de service inter-projets.

Pour en savoir plus, consultez Rôles et autorisations IAM BigQuery.

Définir manuellement le mappage de schéma

Pour définir manuellement votre mappage de schéma, procédez comme suit :

  1. Exécutez le dwh-migration-tool pour Snowflake. Pour en savoir plus, consultez la page Générer des métadonnées pour la traduction et l'évaluation.
  2. Importez le fichier metadata.zip généré dans un bucket Cloud Storage. Le fichier metadata.zip est utilisé comme entrée pour le moteur de traduction.
  3. Exécutez le service de traduction par lot en spécifiant le champ target_types sur metadata. Pour en savoir plus, consultez Traduire des requêtes SQL avec l'API Translation.

    • Voici un exemple de commande permettant d'exécuter une traduction par lot pour 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
    
    • Vous pouvez vérifier l'état de cette commande sur la page de traduction SQL dans BigQuery. Le résultat du job de traduction par lot est stocké dans gs://translation_target_base_uri/metadata/config/.

Fichier de schéma personnalisé

Nous vous recommandons de spécifier un schéma personnalisé si vous devez capturer des informations importantes sur une table, comme la clé primaire, qui seraient sinon perdues lors de la migration. Par exemple, lorsque vous effectuez un transfert incrémentiel, nous vous recommandons de spécifier un fichier de schéma personnalisé afin que les données des transferts ultérieurs puissent être correctement partitionnées lors de leur chargement dans BigQuery. Sans fichier de schéma, toutes les informations sur les clés primaires et le suivi des modifications peuvent être perdues, car le service de transfert de données BigQuery applique automatiquement un schéma de table en utilisant les données sources en cours de transfert.

Un schéma personnalisé peut également être utile lorsque vous devez modifier les noms des colonnes ou les types de données lors du transfert de données.

Un fichier de schéma personnalisé est un fichier JSON qui décrit des objets de base de données. Le schéma contient un ensemble de bases de données, chacune contenant un ensemble de tables, lesquelles contiennent chacune un ensemble de colonnes. Chaque objet comporte un champ originalName qui indique le nom d'objet dans Snowflake, et un champ name qui indique le nom cible de l'objet dans BigQuery.

Les colonnes comportent les champs suivants :

  • originalType : indique le type de données de la colonne dans Snowflake.
  • type : indique le type de données cible pour la colonne dans BigQuery.
  • usageType : informations sur la manière dont la colonne est utilisée par le système. Les types d'utilisation suivants sont pris en charge :

    • DEFAULT : vous pouvez annoter plusieurs colonnes dans une table cible avec ce type d'utilisation. Le type d'utilisation DEFAULT indique que la colonne n'a pas d'utilisation particulière dans le système source. Il s'agit de la valeur par défaut.
    • PRIMARY_KEY : vous pouvez annoter les colonnes de chaque table cible avec ce type d'utilisation. Utilisez le type d'utilisation PRIMARY_KEY pour identifier une seule colonne comme clé primaire ou, dans le cas d'une clé composite, utilisez le même type d'utilisation sur plusieurs colonnes pour identifier les entités uniques d'une table. Ces colonnes fonctionnent avec COMMIT_TIMESTAMP pour extraire les lignes créées ou mises à jour depuis la dernière exécution de transfert.

L'exemple suivant montre un fichier de schéma personnalisé permettant de transférer une table Snowflake appelée orders dans la base de données my_db, de renommer la colonne O_ORDERKEY en ORDERKEY et d'identifier O_ORDERSTATUS comme clé primaire.

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