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 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 comment les données sont chargées dans BigQuery en sélectionnant une préférence d'écriture dans la configuration du 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, prenons 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 au démarrage 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 se termine sans problème et charge 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 de planification habituelle.

Avertissement : Le service de transfert de données BigQuery s'appuie sur la propriété "heure de dernière modification" dans chaque fichier source pour déterminer les fichiers à transférer, comme indiqué dans les exemples de transfert incrémental. La modification de ces propriétés peut entraîner l'ignorance de certains fichiers lors du transfert ou le chargement du même fichier plusieurs fois. Cette propriété peut avoir des noms différents dans chaque système de stockage compatible avec le Service de transfert de données BigQuery. Par exemple, les objets Cloud Storage appellent cette propriété updated.

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 du transfert n'écrase que les données de la partition spécifiée. Une table de destination avec un décorateur de partition se présente 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://.

Remarque : Vous pouvez également exécuter la commande gcloud storage ls pour répertorier des buckets ou des objets.

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 consoleGoogle 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.

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

Tarifs

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

Pour les transferts transrégionaux depuis Cloud Storage, les tarifs sont déterminés par l'emplacement du bucket Cloud Storage et celui de l'ensemble de données BigQuery de destination. Pour en savoir plus, consultez Transfert de données dans Google Cloud.

Pour en savoir plus sur les tarifs, consultez la page Tarifs de BigQuery.

Étapes suivantes

• Découvrez comment configurer un transfert Cloud Storage.
• Découvrez les paramètres d'exécution dans les transferts Cloud Storage.
• Obtenez plus d'informations sur le Service de transfert de données BigQuery.