Présentation des transferts Cloud Storage

Le Service de transfert de données BigQuery pour Cloud Storage vous permet de programmer des chargements de données récurrents depuis des buckets Cloud Storage vers BigQuery. Le chemin d'accès aux données stockées dans Cloud Storage et à la table de destination peut être paramétré, ce qui vous permet de charger des données à partir de buckets Cloud Storage organisés par date.

Formats de fichiers acceptés

Le service de transfert de données BigQuery est actuellement compatible avec le chargement de données depuis Cloud Storage dans l'un des formats suivants :

  • CSV (Comma-Separated Values)
  • JSON (délimité par un retour à la ligne)
  • Avro
  • Parquet
  • ORC

Types de compression acceptés

Le service de transfert de données BigQuery pour Cloud Storage accepte le chargement de données compressées. Les types de compression acceptés par le service de transfert de données BigQuery sont identiques aux types de compression acceptés par les tâches de chargement BigQuery. Pour en savoir plus, consultez la section Charger des données compressées et non compressées.

Ingestion de données pour les transferts Cloud Storage

Vous pouvez spécifier le mode de chargement des données dans BigQuery en sélectionnant une préférence d'écriture dans la configuration de transfert lorsque vous configurez un transfert Cloud Storage.

Il existe deux types de préférences d'écriture : les transferts incrémentiels et les transferts tronqués.

Transferts incrémentiels

Une configuration de transfert avec une préférence d'écriture APPEND ou WRITE_APPEND, également appelée transfert incrémentiel, ajoute de nouvelles données depuis le dernier transfert réussi vers une table de destination BigQuery. Lorsqu'une configuration de transfert s'exécute avec une préférence d'écriture APPEND, le Service de transfert de données BigQuery filtre les fichiers modifiés depuis la dernière exécution de transfert réussie. Pour déterminer le moment où un fichier est modifié, le Service de transfert de données BigQuery recherche une propriété "dernière modification" dans les métadonnées du fichier. Par exemple, le Service de transfert de données BigQuery examine la propriété d'horodatage updated dans un fichier Cloud Storage. Si le Service de transfert de données BigQuery trouve des fichiers dont l'heure de la dernière modification a eu lieu après l'horodatage du dernier transfert réussi, le service transfère ces fichiers dans un transfert incrémentiel.

Pour illustrer le fonctionnement des transferts incrémentiels, considérons l'exemple de transfert Cloud Storage suivant. Un utilisateur crée un fichier dans un bucket Cloud Storage à la date 2023-07-01T00:00Z nomméfile_1. L'horodatage updated pour file_1 correspond à l'heure à laquelle le fichier a été créé. L'utilisateur crée ensuite un transfert incrémentiel à partir du bucket Cloud Storage, dont l'exécution est programmée une fois par jour à 03:00Z, à partir du 2023-07-01T03:00Z.

  • À la date 2023-07-01T03:00Z, la première exécution du transfert commence. Comme il s'agit de la première exécution de transfert pour cette configuration, le Service de transfert de données BigQuery tente de charger tous les fichiers correspondant à l'URI source dans la table BigQuery de destination. L'exécution du transfert aboutit et le service de transfert de données BigQuery charge correctement file_1 dans la table BigQuery de destination.
  • La prochaine exécution de transfert, à 2023-07-02T03:00Z, ne détecte aucun fichier dont la propriété d'horodatage updated est supérieure à la dernière exécution de transfert réussie (2023-07-01T03:00Z). L'exécution du transfert aboutit sans charger de données supplémentaires dans la table BigQuery de destination.

L'exemple précédent montre comment le service de transfert de données BigQuery examine la propriété d'horodatage updated du fichier source pour déterminer si des modifications ont été apportées aux fichiers sources, et pour transférer ces modifications le cas échéant.

Après ce même exemple, supposons que l'utilisateur crée ensuite un autre fichier dans le bucket Cloud Storage, à la date 2023-07-03T00:00Z, nommé file_2. L'horodatage updated pour file_2 correspond à l'heure à laquelle le fichier a été créé.

  • La prochaine exécution de transfert, à 2023-07-03T03:00Z, détecte que file_2 possède un horodatage updated supérieur à la dernière exécution de transfert réussie (2023-07-01T03:00Z). Supposons que l'exécution du transfert échoue en raison d'une erreur temporaire. Dans ce scénario, file_2 n'est pas chargé dans la table BigQuery de destination. Le dernier horodatage d'exécution de transfert réussi reste 2023-07-01T03:00Z.
  • La prochaine exécution de transfert, à 2023-07-04T03:00Z, détecte que file_2 possède un horodatage updated supérieur à la dernière exécution de transfert réussie (2023-07-01T03:00Z). Cette fois, l'exécution du transfert s'effectue sans problème. Elle charge donc correctement file_2 dans la table BigQuery de destination.
  • La prochaine exécution de transfert, à 2023-07-05T03:00Z, ne détecte aucun fichier dont l'horodatage updated est supérieur à la dernière exécution de transfert réussie (2023-07-04T03:00Z). L'exécution du transfert réussit sans charger de données supplémentaires dans la table BigQuery de destination.

L'exemple précédent montre que lorsqu'un transfert échoue, aucun fichier n'est transféré vers la table de destination BigQuery. Toutes les modifications de fichiers sont transférées lors de la prochaine exécution de transfert réussie. Un transfert réussi après un transfert ayant échoué n'entraîne pas de données en double. En cas d'échec d'un transfert, vous pouvez également choisir de déclencher manuellement un transfert en dehors de son heure programmée.

Transferts tronqués

Une configuration de transfert avec une préférence d'écriture MIRROR ou WRITE_TRUNCATE, également appelée transfert tronqué, écrase des données dans la table de destination BigQuery à chaque exécution de transfert avec les données de tous les fichiers correspondant à l'URI source. MIRROR écrase une nouvelle copie des données de la table de destination. Si la table de destination utilise un décorateur de partition, l'exécution de transfert n'écrase que les données de la partition spécifiée. Une table de destination dotée d'un décorateur de partition est au format my_table${run_date} (par exemple, my_table$20230809).

Répéter les mêmes transferts incrémentiels ou tronqués une journée n'entraîne pas de données en double. Toutefois, si vous exécutez plusieurs configurations de transfert différentes qui affectent la même table de destination BigQuery, le Service de transfert de données BigQuery peut dupliquer les données.

Chemin d'accès à la ressource Cloud Storage

Pour charger des données à partir d'une source de données Cloud Storage, vous devez fournir le chemin d'accès aux données.

Le chemin d'accès à la ressource Cloud Storage contient le nom du bucket et l'objet (nom de fichier). Par exemple, si le bucket Cloud Storage est nommé mybucket et que le fichier de données s'appelle myfile.csv, le chemin d'accès à la ressource sera gs://mybucket/myfile.csv.

BigQuery n'accepte pas les chemins de ressource Cloud Storage qui incluent plusieurs barres obliques consécutives après la double barre oblique initiale. Le nom des objets Cloud Storage peut contenir plusieurs barres obliques ("/") consécutives. Toutefois, BigQuery convertit les barres obliques consécutives en une seule. Par exemple, le chemin d'accès à la ressource suivant, bien qu'il soit valide dans Cloud Storage, ne fonctionne pas dans BigQuery : gs://bucket/my//object//name.

Pour récupérer le chemin d'accès à la ressource Cloud Storage, procédez comme suit :

  1. Ouvrez la console Cloud Storage.

    Console Cloud Storage

  2. Accédez à l'emplacement de l'objet (fichier) contenant les données source.

  3. Cliquez sur le nom de l'objet souhaité.

    La page Détails de l'objet s'affiche.

  4. Copiez la valeur fournie dans le champ gsutil URI, qui commence par gs://.

Gestion des caractères génériques dans les chemins de ressources Cloud Storage

Si vos données Cloud Storage sont réparties dans plusieurs fichiers partageant un même nom de base, vous pouvez utiliser un caractère générique dans le chemin d'accès de la ressource lors du chargement des données.

Pour insérer un caractère générique dans le chemin d'accès à la ressource Cloud Storage, il vous suffit d'ajouter un astérisque (*) au nom de base. Par exemple, si vous utilisez deux fichiers nommés fed-sample000001.csv et fed-sample000002.csv, le chemin d'accès à la ressource sera gs://mybucket/fed-sample*. Ce caractère générique peut ensuite être utilisé dans la console Google Cloud ou Google Cloud CLI.

Vous pouvez utiliser plusieurs caractères génériques pour les objets (noms de fichiers) contenus dans les buckets. Le caractère générique peut apparaître n'importe où dans le nom de l'objet.

Le développement des caractères génériques ne s'étend pas aux répertoires dans un gs://bucket/. Par exemple, gs://bucket/dir/* trouve les fichiers situés dans le répertoire dir, mais ne trouve pas les fichiers figurant dans le sous-répertoire gs://bucket/dir/subdir/.

Vous ne pouvez pas non plus identifier des fichiers par leur préfixe sans utiliser les caractères génériques. Par exemple, gs://bucket/dir ne trouvera pas de correspondance avec gs://bucket/dir/file.csv, ni avec gs://bucket/file.csv

Cependant, vous pouvez utiliser plusieurs caractères génériques pour les noms de fichiers dans les buckets. Par exemple, gs://bucket/dir/*/*.csv trouve une correspondance avec gs://bucket/dir/subdir/file.csv.

Pour obtenir des exemples de gestion des caractères génériques conjointement avec des noms de table paramétrés, reportez-vous à la page Paramètres d'exécution dans les transferts.

Considérations relatives aux emplacements

Votre bucket Cloud Storage doit se trouver dans une région ou un emplacement multirégional compatible avec la région ou l'emplacement multirégional de l'ensemble de données de destination dans BigQuery.

  • Si votre ensemble de données BigQuery se trouve dans une zone multirégionale, le bucket Cloud Storage contenant les données que vous transférez doit se trouver dans la même zone multirégionale ou dans un emplacement inclus dans la zone multirégionale. Par exemple, si votre ensemble de données BigQuery se trouve dans la zone multirégionale "EU", le bucket Cloud Storage peut être situé dans la région de Belgique "europe-west1", qui se trouve dans l'Union européenne.
  • Si votre ensemble de données se trouve dans une région, votre bucket Cloud Storage doit se situer dans la même région. Par exemple, si votre ensemble de données se trouve dans la région "asia-northeast1" à Tokyo, le bucket Cloud Storage ne peut pas se situer dans la zone multirégionale "ASIA".

Pour plus d'informations sur les transferts et les régions, consultez la page Emplacement des données et transferts.

Pour en savoir plus sur les emplacements Cloud Storage, consultez la section Emplacements des buckets dans la documentation de Cloud Storage.

Tarifs

  • Les quotas et limites standards de BigQuery liés aux tâches de chargement s'appliquent.

  • Une fois les données transférées vers BigQuery, les tarifs standards du stockage et des requêtes BigQuery s'appliquent.

  • Les données ne sont pas automatiquement supprimées de votre bucket Cloud Storage après leur importation dans BigQuery, sauf si vous demandez leur suppression lorsque vous configurez le transfert. Consultez l'article Configurer un transfert Cloud Storage.

  • Consultez la page Tarifs concernant les transferts pour plus de détails.

Quotas et limites

Le service de transfert de données BigQuery utilise des tâches de chargement pour charger des données Cloud Storage dans BigQuery.

Tous les quotas et limites BigQuery associés aux tâches de chargement s'appliquent aux tâches de chargement Cloud Storage récurrentes, avec les considérations supplémentaires suivantes :

Valeur Limite
Taille maximale par exécution de transfert de tâche de chargement 15 To
Nombre maximal de fichiers par exécution de transfert 10 000 fichiers

Étapes suivantes